I have not made any progress with the MusicPal since Christmas, but someone else has been busy and made a good start on some alternative software to run on it, which he has published here http://musicpal.v3v.de/.
Well done Marco - you have got much further than I have!
Giles also made progress with sound output and left his code in a comment to one of my earlier posts here.
Maybe it would be worth starting a project on Google Code or somewhere so other people can help develop it?
Showing posts with label musicpal. Show all posts
Showing posts with label musicpal. Show all posts
Tuesday, 7 July 2009
Re-Programming MusicPal
I have not made any progress with the MusicPal since Christmas, but someone else has been busy and made a good start on some alternative software to run on it, which he has published here http://musicpal.v3v.de/.
Well done Marco - you have got much further than I have!
Giles also made progress with sound output and left his code in a comment to one of my earlier posts here.
Maybe it would be worth starting a project on Google Code or somewhere so other people can help develop it?
Well done Marco - you have got much further than I have!
Giles also made progress with sound output and left his code in a comment to one of my earlier posts here.
Maybe it would be worth starting a project on Google Code or somewhere so other people can help develop it?
Sunday, 25 January 2009
MusicPal USB Socket
Other people have reported that it is easy to add a USB socket to the MusicPal. As its internal memory is very limited I think this will be useful for software development, so decided to give it a try.
Sure enough, you can open the case easily by removing three screws and pulling the knobs off the front panel. There are clips on the right hand side of the front panel, so you have to start to open the case from the left (speaker) side and pull the front panel to the left a bit to release the clips. I think it would have been possible to remove the front panel without removing the warranty seal on the screws behind the speaker - just removing the middle screw is probably enough to get the front panel off.
I bought a USB socket from RS Components and it soldered easily onto the circuit board, then just had to cut the back panel blank out and it went together nicely. Now if you plug a USB memory stick into it, an extra menu item appears on the Freecom Nashville application menu, and you can play music off it. I haven't tried to disable writing to the memory stick as they did here because I think I will want to write to it from the musicpal. We'll see....
Haven't tried running software off it yet though.
Sure enough, you can open the case easily by removing three screws and pulling the knobs off the front panel. There are clips on the right hand side of the front panel, so you have to start to open the case from the left (speaker) side and pull the front panel to the left a bit to release the clips. I think it would have been possible to remove the front panel without removing the warranty seal on the screws behind the speaker - just removing the middle screw is probably enough to get the front panel off.
I bought a USB socket from RS Components and it soldered easily onto the circuit board, then just had to cut the back panel blank out and it went together nicely. Now if you plug a USB memory stick into it, an extra menu item appears on the Freecom Nashville application menu, and you can play music off it. I haven't tried to disable writing to the memory stick as they did here because I think I will want to write to it from the musicpal. We'll see....
Haven't tried running software off it yet though.
MusicPal USB Socket
Other people have reported that it is easy to add a USB socket to the MusicPal. As its internal memory is very limited I think this will be useful for software development, so decided to give it a try.
Sure enough, you can open the case easily by removing three screws and pulling the knobs off the front panel. There are clips on the right hand side of the front panel, so you have to start to open the case from the left (speaker) side and pull the front panel to the left a bit to release the clips. I think it would have been possible to remove the front panel without removing the warranty seal on the screws behind the speaker - just removing the middle screw is probably enough to get the front panel off.
I bought a USB socket from RS Components and it soldered easily onto the circuit board, then just had to cut the back panel blank out and it went together nicely. Now if you plug a USB memory stick into it, an extra menu item appears on the Freecom Nashville application menu, and you can play music off it. I haven't tried to disable writing to the memory stick as they did here because I think I will want to write to it from the musicpal. We'll see....
Haven't tried running software off it yet though.
Sure enough, you can open the case easily by removing three screws and pulling the knobs off the front panel. There are clips on the right hand side of the front panel, so you have to start to open the case from the left (speaker) side and pull the front panel to the left a bit to release the clips. I think it would have been possible to remove the front panel without removing the warranty seal on the screws behind the speaker - just removing the middle screw is probably enough to get the front panel off.
I bought a USB socket from RS Components and it soldered easily onto the circuit board, then just had to cut the back panel blank out and it went together nicely. Now if you plug a USB memory stick into it, an extra menu item appears on the Freecom Nashville application menu, and you can play music off it. I haven't tried to disable writing to the memory stick as they did here because I think I will want to write to it from the musicpal. We'll see....
Haven't tried running software off it yet though.
Monday, 19 January 2009
Nearly Broke It
I'm trying to get back into fiddling with the MusicPal internet radio after I got distracted by a few other things instead over Christmas.
The first thing I noticed was that I had broken the manufacturers' software - it appeared to boot up ok, and I could play files of my server, but internet radio didn't work, and neither did the clock on the device.
I tried fiddling around with the settings via the MusicPal's menu, but couldn't find anything wrong.
It turned out that I had filled up the filesystem on the device, so it did not have enough storage space to create /etc/resolve.conf or similar, so the internet DNS resolution did not work. Once I deleted my experimental files, it all started to work again....
This got me thinking that to do any serious development on this, I will need more storage space - deleting the manufacturers' software altogether is a bit of a big step given the rate I work on these things. The simplest would be to persuade it to boot over the network, just like the MediaMVP - this means I can easily change the root filesystem image, and if it doesn't work it is trivial to put hte original back. The trouble with this is that I will have to update the uboot configuration - this would be easy if I had a serial console for the device, but I don't. I think there is a real possibility of turning it into a brick if I get this wrong.....
The less intrusive alternative would be to compile a kernel with NFS support and have it nfs mount a filesystem with my software on it. This is less drastic, but I will have to make sure I can do the emergency re-flash of the firmware in case I mess it up. A job for later.
The simplest would be to put my files on a USB memory stick and use that - people seem to have added USB support to the musicpal quite easily, so I had a look inside. Sure enough, there is space for a solder connection USB socket, and a punch out panel in the back of the case. I think I will get a USB socket and try this first to see how it goes - I can't find one in anything I can dismantle at the moment, so will have to buy one.
The first thing I noticed was that I had broken the manufacturers' software - it appeared to boot up ok, and I could play files of my server, but internet radio didn't work, and neither did the clock on the device.
I tried fiddling around with the settings via the MusicPal's menu, but couldn't find anything wrong.
It turned out that I had filled up the filesystem on the device, so it did not have enough storage space to create /etc/resolve.conf or similar, so the internet DNS resolution did not work. Once I deleted my experimental files, it all started to work again....
This got me thinking that to do any serious development on this, I will need more storage space - deleting the manufacturers' software altogether is a bit of a big step given the rate I work on these things. The simplest would be to persuade it to boot over the network, just like the MediaMVP - this means I can easily change the root filesystem image, and if it doesn't work it is trivial to put hte original back. The trouble with this is that I will have to update the uboot configuration - this would be easy if I had a serial console for the device, but I don't. I think there is a real possibility of turning it into a brick if I get this wrong.....
The less intrusive alternative would be to compile a kernel with NFS support and have it nfs mount a filesystem with my software on it. This is less drastic, but I will have to make sure I can do the emergency re-flash of the firmware in case I mess it up. A job for later.
The simplest would be to put my files on a USB memory stick and use that - people seem to have added USB support to the musicpal quite easily, so I had a look inside. Sure enough, there is space for a solder connection USB socket, and a punch out panel in the back of the case. I think I will get a USB socket and try this first to see how it goes - I can't find one in anything I can dismantle at the moment, so will have to buy one.
Nearly Broke It
I'm trying to get back into fiddling with the MusicPal internet radio after I got distracted by a few other things instead over Christmas.
The first thing I noticed was that I had broken the manufacturers' software - it appeared to boot up ok, and I could play files of my server, but internet radio didn't work, and neither did the clock on the device.
I tried fiddling around with the settings via the MusicPal's menu, but couldn't find anything wrong.
It turned out that I had filled up the filesystem on the device, so it did not have enough storage space to create /etc/resolve.conf or similar, so the internet DNS resolution did not work. Once I deleted my experimental files, it all started to work again....
This got me thinking that to do any serious development on this, I will need more storage space - deleting the manufacturers' software altogether is a bit of a big step given the rate I work on these things. The simplest would be to persuade it to boot over the network, just like the MediaMVP - this means I can easily change the root filesystem image, and if it doesn't work it is trivial to put hte original back. The trouble with this is that I will have to update the uboot configuration - this would be easy if I had a serial console for the device, but I don't. I think there is a real possibility of turning it into a brick if I get this wrong.....
The less intrusive alternative would be to compile a kernel with NFS support and have it nfs mount a filesystem with my software on it. This is less drastic, but I will have to make sure I can do the emergency re-flash of the firmware in case I mess it up. A job for later.
The simplest would be to put my files on a USB memory stick and use that - people seem to have added USB support to the musicpal quite easily, so I had a look inside. Sure enough, there is space for a solder connection USB socket, and a punch out panel in the back of the case. I think I will get a USB socket and try this first to see how it goes - I can't find one in anything I can dismantle at the moment, so will have to buy one.
The first thing I noticed was that I had broken the manufacturers' software - it appeared to boot up ok, and I could play files of my server, but internet radio didn't work, and neither did the clock on the device.
I tried fiddling around with the settings via the MusicPal's menu, but couldn't find anything wrong.
It turned out that I had filled up the filesystem on the device, so it did not have enough storage space to create /etc/resolve.conf or similar, so the internet DNS resolution did not work. Once I deleted my experimental files, it all started to work again....
This got me thinking that to do any serious development on this, I will need more storage space - deleting the manufacturers' software altogether is a bit of a big step given the rate I work on these things. The simplest would be to persuade it to boot over the network, just like the MediaMVP - this means I can easily change the root filesystem image, and if it doesn't work it is trivial to put hte original back. The trouble with this is that I will have to update the uboot configuration - this would be easy if I had a serial console for the device, but I don't. I think there is a real possibility of turning it into a brick if I get this wrong.....
The less intrusive alternative would be to compile a kernel with NFS support and have it nfs mount a filesystem with my software on it. This is less drastic, but I will have to make sure I can do the emergency re-flash of the firmware in case I mess it up. A job for later.
The simplest would be to put my files on a USB memory stick and use that - people seem to have added USB support to the musicpal quite easily, so I had a look inside. Sure enough, there is space for a solder connection USB socket, and a punch out panel in the back of the case. I think I will get a USB socket and try this first to see how it goes - I can't find one in anything I can dismantle at the moment, so will have to buy one.
Friday, 28 November 2008
autoconf / automake / aclocal
I am trying to build Music Player Daemon for the FreeCom MusicPal. I have written an output plugin that I think will drive the hardware, but now I am having trouble compiling this into the MPD source code. I have never really understood the GNU configure scripts (./configure and all that), so I have probably messed something up.
I have added new bits to configure.ac, Makefile.in etc. But now what do I do?
As far as I can tell from the simplest tutorial I can find suggests that I should just be able to edit configure.ac and Makefile.am then run autoconf, but it complains that the files are designed for automake version 1.6, and I have 1.10. The error suggests running aclocal, but this just leads to more errors....
I have added new bits to configure.ac, Makefile.in etc. But now what do I do?
As far as I can tell from the simplest tutorial I can find suggests that I should just be able to edit configure.ac and Makefile.am then run autoconf, but it complains that the files are designed for automake version 1.6, and I have 1.10. The error suggests running aclocal, but this just leads to more errors....
autoconf / automake / aclocal
I am trying to build Music Player Daemon for the FreeCom MusicPal. I have written an output plugin that I think will drive the hardware, but now I am having trouble compiling this into the MPD source code. I have never really understood the GNU configure scripts (./configure and all that), so I have probably messed something up.
I have added new bits to configure.ac, Makefile.in etc. But now what do I do?
As far as I can tell from the simplest tutorial I can find suggests that I should just be able to edit configure.ac and Makefile.am then run autoconf, but it complains that the files are designed for automake version 1.6, and I have 1.10. The error suggests running aclocal, but this just leads to more errors....
I have added new bits to configure.ac, Makefile.in etc. But now what do I do?
As far as I can tell from the simplest tutorial I can find suggests that I should just be able to edit configure.ac and Makefile.am then run autoconf, but it complains that the files are designed for automake version 1.6, and I have 1.10. The error suggests running aclocal, but this just leads to more errors....
Sunday, 23 November 2008
Progress with MusicPal Sound Programming
After a couple of hours of using strace to try to understand what Nashville was doing, and looking at the "base_audio" directory in the MusicPal kernel source directory, I have finally got it to make a noise.
Basically you have to use /dev/audio and send some ioctl's to initialise the hardware, and set up the graphic equaliser. You can then write raw data to /dev/audio just like you would with OSS. In fact, I used the OSS sinegen.c example program as the basis and just altered the ioctls. http://www.musicpal.webhop.net/audiotest.c is my sample program (it needs audio.h from the MusicPal kernel source code to compile) - it makes a continuous tone come out of the MusicPal speaker, which is progress! There are some comments in the code to show what it is doing (as far as I can work out anyway!).
Basically you have to use /dev/audio and send some ioctl's to initialise the hardware, and set up the graphic equaliser. You can then write raw data to /dev/audio just like you would with OSS. In fact, I used the OSS sinegen.c example program as the basis and just altered the ioctls. http://www.musicpal.webhop.net/audiotest.c is my sample program (it needs audio.h from the MusicPal kernel source code to compile) - it makes a continuous tone come out of the MusicPal speaker, which is progress! There are some comments in the code to show what it is doing (as far as I can work out anyway!).
Progress with MusicPal Sound Programming
After a couple of hours of using strace to try to understand what Nashville was doing, and looking at the "base_audio" directory in the MusicPal kernel source directory, I have finally got it to make a noise.
Basically you have to use /dev/audio and send some ioctl's to initialise the hardware, and set up the graphic equaliser. You can then write raw data to /dev/audio just like you would with OSS. In fact, I used the OSS sinegen.c example program as the basis and just altered the ioctls. http://www.musicpal.webhop.net/audiotest.c is my sample program (it needs audio.h from the MusicPal kernel source code to compile) - it makes a continuous tone come out of the MusicPal speaker, which is progress! There are some comments in the code to show what it is doing (as far as I can work out anyway!).
Basically you have to use /dev/audio and send some ioctl's to initialise the hardware, and set up the graphic equaliser. You can then write raw data to /dev/audio just like you would with OSS. In fact, I used the OSS sinegen.c example program as the basis and just altered the ioctls. http://www.musicpal.webhop.net/audiotest.c is my sample program (it needs audio.h from the MusicPal kernel source code to compile) - it makes a continuous tone come out of the MusicPal speaker, which is progress! There are some comments in the code to show what it is doing (as far as I can work out anyway!).
MusicPal Debug Tools
I am trying to get sound playback working in my own code on the MusicPal. I have been advised to use a utility called 'strace' which allows you to monitor what system calls an application is executing - this should allow me to see how nashville initialises and uses the sound system on the MusicPal (http://forum.freecompromo.com/viewtopic.php?p=22633#22633).
I downloaded the source code for strace from sourceforge. It uses the standard gnu ./compile system to configure and compile it.
I got it to compile for the MusicPal using:
It compiled ok, and won't run on my PC, which is a good indication that it has cross compiled.
The problem is that I can not transfer it to the MusicPal because the executable is about 290kB, and there is only 176kB free on the MusicPal /home directory.
Oh Dear....I think the MusicPal has quite a lot of RAM - I'll see if I can make a RAM disk - either that or I have to get NFS working on the MusicPal so I can mount a decent sized directory, or even more drastic, pull the MusicPal appart and put a USB socket in it to use a USB disk - easier in the long run, but this is supposed to be a present for my wife, so I'd better not.
Silly me - there is already a ram disk mounted as /tmp....
I downloaded the source code for strace from sourceforge. It uses the standard gnu ./compile system to configure and compile it.
I got it to compile for the MusicPal using:
source ~/alinux/setvars; CFLAGS=-I~/alinux/linux/include ./configure --host=arm-linux
make
It compiled ok, and won't run on my PC, which is a good indication that it has cross compiled.
The problem is that I can not transfer it to the MusicPal because the executable is about 290kB, and there is only 176kB free on the MusicPal /home directory.
Oh Dear....I think the MusicPal has quite a lot of RAM - I'll see if I can make a RAM disk - either that or I have to get NFS working on the MusicPal so I can mount a decent sized directory, or even more drastic, pull the MusicPal appart and put a USB socket in it to use a USB disk - easier in the long run, but this is supposed to be a present for my wife, so I'd better not.
Silly me - there is already a ram disk mounted as /tmp....
MusicPal Debug Tools
I am trying to get sound playback working in my own code on the MusicPal. I have been advised to use a utility called 'strace' which allows you to monitor what system calls an application is executing - this should allow me to see how nashville initialises and uses the sound system on the MusicPal (http://forum.freecompromo.com/viewtopic.php?p=22633#22633).
I downloaded the source code for strace from sourceforge. It uses the standard gnu ./compile system to configure and compile it.
I got it to compile for the MusicPal using:
It compiled ok, and won't run on my PC, which is a good indication that it has cross compiled.
The problem is that I can not transfer it to the MusicPal because the executable is about 290kB, and there is only 176kB free on the MusicPal /home directory.
Oh Dear....I think the MusicPal has quite a lot of RAM - I'll see if I can make a RAM disk - either that or I have to get NFS working on the MusicPal so I can mount a decent sized directory, or even more drastic, pull the MusicPal appart and put a USB socket in it to use a USB disk - easier in the long run, but this is supposed to be a present for my wife, so I'd better not.
Silly me - there is already a ram disk mounted as /tmp....
I downloaded the source code for strace from sourceforge. It uses the standard gnu ./compile system to configure and compile it.
I got it to compile for the MusicPal using:
source ~/alinux/setvars; CFLAGS=-I~/alinux/linux/include ./configure --host=arm-linux
make
It compiled ok, and won't run on my PC, which is a good indication that it has cross compiled.
The problem is that I can not transfer it to the MusicPal because the executable is about 290kB, and there is only 176kB free on the MusicPal /home directory.
Oh Dear....I think the MusicPal has quite a lot of RAM - I'll see if I can make a RAM disk - either that or I have to get NFS working on the MusicPal so I can mount a decent sized directory, or even more drastic, pull the MusicPal appart and put a USB socket in it to use a USB disk - easier in the long run, but this is supposed to be a present for my wife, so I'd better not.
Silly me - there is already a ram disk mounted as /tmp....
Saturday, 22 November 2008
MusicPal Sound Programming
The MusicPal has a few devices that look like they are to do with sound:
A couple of hours later and I might be getting somewhere. I tried doing fuser /dev/dsp and fuser /dev/audio. These both returned nothing with the main application (nashville) sutdown. Re-starting it with /etc/init.d/mainapp start, then repeating showed that /dev/dsp was still not used, but /dev/audio was used by the 12 running versions of /bin/nashville. This has persuaded me that Freecom use /dev/audio, not /dev/dsp.
So, what is /dev/audio, and how do I use it?
The source code provided by freecom contains a directory .arch/arm/mach-mv88w8xx8/base_audio. This might be a clue. It even contains a file called audio_api.h - is this a modified version of OSS, or something unique?
Tried doing cat file.au > /dev/audio and cat file.mp3 > /dev/audio - no sound at all if the machine had just been re-booted and nashville stopped, and had to CTRL-C to get back to the shell.
Re-started nashville, played a tune, put nashville into sleep mode, then stopped it. Repeated the cat xxx process - no sound, but dmesg showed "audio released irq disabled" messages, which come from audio.c in the base_audio directory.
Re-started nashville, and now this does not make any sound either - I'm definitely doing something to its sound driver....
Re-Booted. Set nashville playing, then stopped it with /etc/init.d/mainapp stop. Then did cat /usr/share/wakeup.mp3 > /dev/audio - got awful noise out of the speaker!
This is progress - I must have to do some initialisation to get it working, then send it data in the right format - just a matter of finding out how and what now - looks like audio.c might have some answers though...
- /dev/dsp
- /dev/mixer
- /dev/audio
A couple of hours later and I might be getting somewhere. I tried doing fuser /dev/dsp and fuser /dev/audio. These both returned nothing with the main application (nashville) sutdown. Re-starting it with /etc/init.d/mainapp start, then repeating showed that /dev/dsp was still not used, but /dev/audio was used by the 12 running versions of /bin/nashville. This has persuaded me that Freecom use /dev/audio, not /dev/dsp.
So, what is /dev/audio, and how do I use it?
The source code provided by freecom contains a directory .arch/arm/mach-mv88w8xx8/base_audio. This might be a clue. It even contains a file called audio_api.h - is this a modified version of OSS, or something unique?
Tried doing cat file.au > /dev/audio and cat file.mp3 > /dev/audio - no sound at all if the machine had just been re-booted and nashville stopped, and had to CTRL-C to get back to the shell.
Re-started nashville, played a tune, put nashville into sleep mode, then stopped it. Repeated the cat xxx process - no sound, but dmesg showed "audio released irq disabled" messages, which come from audio.c in the base_audio directory.
Re-started nashville, and now this does not make any sound either - I'm definitely doing something to its sound driver....
Re-Booted. Set nashville playing, then stopped it with /etc/init.d/mainapp stop. Then did cat /usr/share/wakeup.mp3 > /dev/audio - got awful noise out of the speaker!
This is progress - I must have to do some initialisation to get it working, then send it data in the right format - just a matter of finding out how and what now - looks like audio.c might have some answers though...
MusicPal Sound Programming
The MusicPal has a few devices that look like they are to do with sound:
A couple of hours later and I might be getting somewhere. I tried doing fuser /dev/dsp and fuser /dev/audio. These both returned nothing with the main application (nashville) sutdown. Re-starting it with /etc/init.d/mainapp start, then repeating showed that /dev/dsp was still not used, but /dev/audio was used by the 12 running versions of /bin/nashville. This has persuaded me that Freecom use /dev/audio, not /dev/dsp.
So, what is /dev/audio, and how do I use it?
The source code provided by freecom contains a directory .arch/arm/mach-mv88w8xx8/base_audio. This might be a clue. It even contains a file called audio_api.h - is this a modified version of OSS, or something unique?
Tried doing cat file.au > /dev/audio and cat file.mp3 > /dev/audio - no sound at all if the machine had just been re-booted and nashville stopped, and had to CTRL-C to get back to the shell.
Re-started nashville, played a tune, put nashville into sleep mode, then stopped it. Repeated the cat xxx process - no sound, but dmesg showed "audio released irq disabled" messages, which come from audio.c in the base_audio directory.
Re-started nashville, and now this does not make any sound either - I'm definitely doing something to its sound driver....
Re-Booted. Set nashville playing, then stopped it with /etc/init.d/mainapp stop. Then did cat /usr/share/wakeup.mp3 > /dev/audio - got awful noise out of the speaker!
This is progress - I must have to do some initialisation to get it working, then send it data in the right format - just a matter of finding out how and what now - looks like audio.c might have some answers though...
- /dev/dsp
- /dev/mixer
- /dev/audio
A couple of hours later and I might be getting somewhere. I tried doing fuser /dev/dsp and fuser /dev/audio. These both returned nothing with the main application (nashville) sutdown. Re-starting it with /etc/init.d/mainapp start, then repeating showed that /dev/dsp was still not used, but /dev/audio was used by the 12 running versions of /bin/nashville. This has persuaded me that Freecom use /dev/audio, not /dev/dsp.
So, what is /dev/audio, and how do I use it?
The source code provided by freecom contains a directory .arch/arm/mach-mv88w8xx8/base_audio. This might be a clue. It even contains a file called audio_api.h - is this a modified version of OSS, or something unique?
Tried doing cat file.au > /dev/audio and cat file.mp3 > /dev/audio - no sound at all if the machine had just been re-booted and nashville stopped, and had to CTRL-C to get back to the shell.
Re-started nashville, played a tune, put nashville into sleep mode, then stopped it. Repeated the cat xxx process - no sound, but dmesg showed "audio released irq disabled" messages, which come from audio.c in the base_audio directory.
Re-started nashville, and now this does not make any sound either - I'm definitely doing something to its sound driver....
Re-Booted. Set nashville playing, then stopped it with /etc/init.d/mainapp stop. Then did cat /usr/share/wakeup.mp3 > /dev/audio - got awful noise out of the speaker!
This is progress - I must have to do some initialisation to get it working, then send it data in the right format - just a matter of finding out how and what now - looks like audio.c might have some answers though...
Friday, 21 November 2008
More on Writing to MusicPal Display
I've made some progress on writing to the MusicPal display now.
This is all written in C - haven't got as far as trying to make Python work yet.
I downloaded the Embedded Linux Development Kit and the MusicPal Linux source code from the FreeCom web site by clicking on the 'Legal Notice' link.
The source code included a directory .../alinux/linux-2.6.16.16/arch/arm/mach-mv88w8xx8/lcd_framebuffer which appears to be the framebuffer driver source code for the MusicPal LCD Display.
It included an example file "mvlcd_test.c" which did not work, but I managed to comment out the errors to get it to compile and run on the MusicPal - I transferred the executable to the MusicPal using wget on the MusicPal to download it from my web server. Most of the options to do with filling in the screen did not work, but the 'Write String' one did once I realised that you have to do 'manually refresh display' afterwards to see what you have done. It is also best to kill the MusicPal main application with:
Otherwise it overwrites the things you have written.
I have got a simple example running which shows text in three different fonts. The example program is:
This in turn relies on a simple library that I have started - glcd.c and glcd.h:
glcd.h
glcd.c
This doesn't do much, but I can now display text on the MusicPal display, so I am progressing towards a replacement firmware for it - just a little way to go still!
NT
This is all written in C - haven't got as far as trying to make Python work yet.
I downloaded the Embedded Linux Development Kit and the MusicPal Linux source code from the FreeCom web site by clicking on the 'Legal Notice' link.
The source code included a directory .../alinux/linux-2.6.16.16/arch/arm/mach-mv88w8xx8/lcd_framebuffer which appears to be the framebuffer driver source code for the MusicPal LCD Display.
It included an example file "mvlcd_test.c" which did not work, but I managed to comment out the errors to get it to compile and run on the MusicPal - I transferred the executable to the MusicPal using wget on the MusicPal to download it from my web server. Most of the options to do with filling in the screen did not work, but the 'Write String' one did once I realised that you have to do 'manually refresh display' afterwards to see what you have done. It is also best to kill the MusicPal main application with:
/etc/init.d/watching stop
/etc/init.d/mainapp stop
Otherwise it overwrites the things you have written.
I have got a simple example running which shows text in three different fonts. The example program is:
#include
#include "glcd.h"
main() {
lcd_clear_screen();
lcd_set_font(0);
lcd_write_string("font0",0,0);
lcd_set_font(1);
lcd_write_string("font1",0,10);
lcd_set_font(2);
lcd_write_string("22:00",0,20);
lcd_redraw_screen();
}
This in turn relies on a simple library that I have started - glcd.c and glcd.h:
glcd.h
/*
* glcd.h
* Desc: Graham's simple interface to display text on the MusicPal LCD
* Display.
* HIST: 21nov2008 GJ ORIGINAL VERSIO
*/
extern int lcd_font_number; /* Default font - 0,1 or 2 */
int lcd_set_font(int);
int lcd_write_string(char *str,int x,int y);
int lcd_clear_screen(void);
int lcd_redraw_screen(void);
int lcd_poll_buttons(void);
glcd.c
#include
#include
#include "lcdwrite.h"
#include "glcd.h"
int lcd_font = 0;
int lcd_write_string(char *str, int x, int y) {
int fbfd = 0;
int retval = 0;
struct disp_string_lcd disp_lcd;
strcpy(disp_lcd.str,str);
disp_lcd.x = x;
disp_lcd.y = y;
switch (lcd_font) {
case 0:
disp_lcd.flags = STR_FLAG_FONT_6X8;
break;
case 1:
disp_lcd.flags = STR_FLAG_FONT_8X8;
break;
case 2:
disp_lcd.flags = STR_FLAG_FONT_24X24;
break;
default:
disp_lcd.flags = STR_FLAG_FONT_6X8;
}
printf("write_string: str=%s, x=%d, y=%d, flags=%d\n",
disp_lcd.str, disp_lcd.x, disp_lcd.y, disp_lcd.flags);
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_DISP_STRING, &disp_lcd)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return 0;
}
int lcd_clear_screen() {
int fbfd = 0;
int retval = 0;
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_CLEAR_SCREEN, 0)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return 0;
}
int lcd_redraw_screen() {
int fbfd = 0;
int retval = 0;
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_REFRESH, 0)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return 0;
}
int poll_buttons() {
int fbfd = 0;
int retval = 0;
int buttons;
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_POLL_BUTTONS, &buttons)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return buttons;
}
int lcd_set_font(int font) {
if (font<0>2) {
fprintf(stderr,"WARNING: Font Number %d is an odd number - this might not work\n", font);
}
lcd_font = font;
}
This doesn't do much, but I can now display text on the MusicPal display, so I am progressing towards a replacement firmware for it - just a little way to go still!
NT
More on Writing to MusicPal Display
I've made some progress on writing to the MusicPal display now.
This is all written in C - haven't got as far as trying to make Python work yet.
I downloaded the Embedded Linux Development Kit and the MusicPal Linux source code from the FreeCom web site by clicking on the 'Legal Notice' link.
The source code included a directory .../alinux/linux-2.6.16.16/arch/arm/mach-mv88w8xx8/lcd_framebuffer which appears to be the framebuffer driver source code for the MusicPal LCD Display.
It included an example file "mvlcd_test.c" which did not work, but I managed to comment out the errors to get it to compile and run on the MusicPal - I transferred the executable to the MusicPal using wget on the MusicPal to download it from my web server. Most of the options to do with filling in the screen did not work, but the 'Write String' one did once I realised that you have to do 'manually refresh display' afterwards to see what you have done. It is also best to kill the MusicPal main application with:
Otherwise it overwrites the things you have written.
I have got a simple example running which shows text in three different fonts. The example program is:
This in turn relies on a simple library that I have started - glcd.c and glcd.h:
glcd.h
glcd.c
This doesn't do much, but I can now display text on the MusicPal display, so I am progressing towards a replacement firmware for it - just a little way to go still!
NT
This is all written in C - haven't got as far as trying to make Python work yet.
I downloaded the Embedded Linux Development Kit and the MusicPal Linux source code from the FreeCom web site by clicking on the 'Legal Notice' link.
The source code included a directory .../alinux/linux-2.6.16.16/arch/arm/mach-mv88w8xx8/lcd_framebuffer which appears to be the framebuffer driver source code for the MusicPal LCD Display.
It included an example file "mvlcd_test.c" which did not work, but I managed to comment out the errors to get it to compile and run on the MusicPal - I transferred the executable to the MusicPal using wget on the MusicPal to download it from my web server. Most of the options to do with filling in the screen did not work, but the 'Write String' one did once I realised that you have to do 'manually refresh display' afterwards to see what you have done. It is also best to kill the MusicPal main application with:
/etc/init.d/watching stop
/etc/init.d/mainapp stop
Otherwise it overwrites the things you have written.
I have got a simple example running which shows text in three different fonts. The example program is:
#include
#include "glcd.h"
main() {
lcd_clear_screen();
lcd_set_font(0);
lcd_write_string("font0",0,0);
lcd_set_font(1);
lcd_write_string("font1",0,10);
lcd_set_font(2);
lcd_write_string("22:00",0,20);
lcd_redraw_screen();
}
This in turn relies on a simple library that I have started - glcd.c and glcd.h:
glcd.h
/*
* glcd.h
* Desc: Graham's simple interface to display text on the MusicPal LCD
* Display.
* HIST: 21nov2008 GJ ORIGINAL VERSIO
*/
extern int lcd_font_number; /* Default font - 0,1 or 2 */
int lcd_set_font(int);
int lcd_write_string(char *str,int x,int y);
int lcd_clear_screen(void);
int lcd_redraw_screen(void);
int lcd_poll_buttons(void);
glcd.c
#include
#include
#include "lcdwrite.h"
#include "glcd.h"
int lcd_font = 0;
int lcd_write_string(char *str, int x, int y) {
int fbfd = 0;
int retval = 0;
struct disp_string_lcd disp_lcd;
strcpy(disp_lcd.str,str);
disp_lcd.x = x;
disp_lcd.y = y;
switch (lcd_font) {
case 0:
disp_lcd.flags = STR_FLAG_FONT_6X8;
break;
case 1:
disp_lcd.flags = STR_FLAG_FONT_8X8;
break;
case 2:
disp_lcd.flags = STR_FLAG_FONT_24X24;
break;
default:
disp_lcd.flags = STR_FLAG_FONT_6X8;
}
printf("write_string: str=%s, x=%d, y=%d, flags=%d\n",
disp_lcd.str, disp_lcd.x, disp_lcd.y, disp_lcd.flags);
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_DISP_STRING, &disp_lcd)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return 0;
}
int lcd_clear_screen() {
int fbfd = 0;
int retval = 0;
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_CLEAR_SCREEN, 0)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return 0;
}
int lcd_redraw_screen() {
int fbfd = 0;
int retval = 0;
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_REFRESH, 0)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return 0;
}
int poll_buttons() {
int fbfd = 0;
int retval = 0;
int buttons;
// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
retval = -1;
} else {
if (ioctl(fbfd, MVLCD_POLL_BUTTONS, &buttons)) {
printf("Error refreshing.\n");
return 1;
}
}
close(fbfd);
return buttons;
}
int lcd_set_font(int font) {
if (font<0>2) {
fprintf(stderr,"WARNING: Font Number %d is an odd number - this might not work\n", font);
}
lcd_font = font;
}
This doesn't do much, but I can now display text on the MusicPal display, so I am progressing towards a replacement firmware for it - just a little way to go still!
NT
Wednesday, 19 November 2008
Writing to the MusicPal Display
Made a bit of progress with writing to the MusicPal display.
There is a device /dev/lcd which looked promising, but I didn't know what to do with it, but then I noticed that /dev/fb0 links to it. /dev/fb0 should be a linux framebuffer interface to the graphics hardware. Unfortunately most of the guides I could find on the internet were not about how to program the framebuffer, but how to set it up. I thought I was going to have to resort to reading /usr/include/linux/fb.h to try to understand it. I was pleased to find that someone (lesky?) has done that and published a bit of code to work with the framebuffer here.
He provided some example code to open the framebuffer device and extract information about it from the hardware as shown below:
There is a device /dev/lcd which looked promising, but I didn't know what to do with it, but then I noticed that /dev/fb0 links to it. /dev/fb0 should be a linux framebuffer interface to the graphics hardware. Unfortunately most of the guides I could find on the internet were not about how to program the framebuffer, but how to set it up. I thought I was going to have to resort to reading /usr/include/linux/fb.h to try to understand it. I was pleased to find that someone (lesky?) has done that and published a bit of code to work with the framebuffer here.
He provided some example code to open the framebuffer device and extract information about it from the hardware as shown below:
#include
#include
#include
#include
#include
int main()
{
int fbfd = 0;
struct fb_var_screeninfo vinfo;
struct fb_fix_screeninfo finfo;
long int screensize = 0;
char *fbp = 0;
int x = 0, y = 0;
long int location = 0;
/* Open the file for reading and writing */
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
exit(1);
}
printf("The framebuffer device was opened successfully.\n");
/* Get fixed screen information */
if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) {
printf("Error reading fixed information.\n");
exit(2);
}
/* Get variable screen information */
if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
printf("Error reading variable information.\n");
exit(3);
}
/* Figure out the size of the screen in bytes */
screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
printf("xres=%d, yres=%d, bits_per_pixel=%d\n",
vinfo.xres, vinfo.yres, vinfo.bits_per_pixel);
/* Map the device to memory */
fbp = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED,
fbfd, 0);
if ((int)fbp == -1) {
printf("Error: failed to map framebuffer device to memory.\n");
exit(4);
}
printf("The framebuffer device was mapped to memory successfully.\n");
x = 100; y = 100; /* Where we are going to put the pixel */
/* Figure out where in memory to put the pixel */
location = (x+vinfo.xoffset) * (vinfo.bits_per_pixel/8) +
(y+vinfo.yoffset) * finfo.line_length;
*(fbp + location) = 100; /* Some blue */
*(fbp + location + 1) = 15; /* A little green */
*(fbp + location + 2) = 200; /* A lot of red */
*(fbp + location + 3) = 0; /* No transparency */
munmap(fbp, screensize);
close(fbfd);
return 0;
}
Writing to the MusicPal Display
Made a bit of progress with writing to the MusicPal display.
There is a device /dev/lcd which looked promising, but I didn't know what to do with it, but then I noticed that /dev/fb0 links to it. /dev/fb0 should be a linux framebuffer interface to the graphics hardware. Unfortunately most of the guides I could find on the internet were not about how to program the framebuffer, but how to set it up. I thought I was going to have to resort to reading /usr/include/linux/fb.h to try to understand it. I was pleased to find that someone (lesky?) has done that and published a bit of code to work with the framebuffer here.
He provided some example code to open the framebuffer device and extract information about it from the hardware as shown below:
There is a device /dev/lcd which looked promising, but I didn't know what to do with it, but then I noticed that /dev/fb0 links to it. /dev/fb0 should be a linux framebuffer interface to the graphics hardware. Unfortunately most of the guides I could find on the internet were not about how to program the framebuffer, but how to set it up. I thought I was going to have to resort to reading /usr/include/linux/fb.h to try to understand it. I was pleased to find that someone (lesky?) has done that and published a bit of code to work with the framebuffer here.
He provided some example code to open the framebuffer device and extract information about it from the hardware as shown below:
#include
#include
#include
#include
#include
int main()
{
int fbfd = 0;
struct fb_var_screeninfo vinfo;
struct fb_fix_screeninfo finfo;
long int screensize = 0;
char *fbp = 0;
int x = 0, y = 0;
long int location = 0;
/* Open the file for reading and writing */
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
exit(1);
}
printf("The framebuffer device was opened successfully.\n");
/* Get fixed screen information */
if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) {
printf("Error reading fixed information.\n");
exit(2);
}
/* Get variable screen information */
if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
printf("Error reading variable information.\n");
exit(3);
}
/* Figure out the size of the screen in bytes */
screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
printf("xres=%d, yres=%d, bits_per_pixel=%d\n",
vinfo.xres, vinfo.yres, vinfo.bits_per_pixel);
/* Map the device to memory */
fbp = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED,
fbfd, 0);
if ((int)fbp == -1) {
printf("Error: failed to map framebuffer device to memory.\n");
exit(4);
}
printf("The framebuffer device was mapped to memory successfully.\n");
x = 100; y = 100; /* Where we are going to put the pixel */
/* Figure out where in memory to put the pixel */
location = (x+vinfo.xoffset) * (vinfo.bits_per_pixel/8) +
(y+vinfo.yoffset) * finfo.line_length;
*(fbp + location) = 100; /* Some blue */
*(fbp + location + 1) = 15; /* A little green */
*(fbp + location + 2) = 200; /* A lot of red */
*(fbp + location + 3) = 0; /* No transparency */
munmap(fbp, screensize);
close(fbfd);
return 0;
}
Subscribe to:
Posts (Atom)