Report for the week 09-8-10 to 16-8-10
I was busy this week with some urgent college work, so could not put in as much time.
Status
* Improved the documentation on the elinux wiki page.
* Made a patch and submitted it to the linux-omap mailing list for review. I sent in the patch this morning so am still waiting for some opinions about it. I am hoping I have got the basics right.
Plans
* I will try and put some more time into testing the pwm speaker driver.
Monday, August 16, 2010
Monday, August 9, 2010
Week 11 report
Report for the week 02-8-10 to 09-8-10
Status
* I misunderstood the ioctl() interface thinking that I could issue these calls from the kernel space as well. But later discovered that these can only be used from the userspace. This was causing the compile errors I mentioned in the last week's report. With this out of the way I can now build the pwm speaker driver.
* The pwm driver can now be used even in the kernel space with the addition of some EXPORT_SYMBOL() commands. Not all of the features are available through this right now but I will look into this.
Plans
* I have been testing the pwm speaker driver with not a lot of success but hopefully it will get fixed this week.
* Improve the documentation on the wiki as well as the repo.
Status
* I misunderstood the ioctl() interface thinking that I could issue these calls from the kernel space as well. But later discovered that these can only be used from the userspace. This was causing the compile errors I mentioned in the last week's report. With this out of the way I can now build the pwm speaker driver.
* The pwm driver can now be used even in the kernel space with the addition of some EXPORT_SYMBOL() commands. Not all of the features are available through this right now but I will look into this.
Plans
* I have been testing the pwm speaker driver with not a lot of success but hopefully it will get fixed this week.
* Improve the documentation on the wiki as well as the repo.
Monday, August 2, 2010
Week 10 report
Report for the week 26-7-10 to 02-8-10
Status
* I managed to modify the pcsp driver (/usr/src/linux/drivers/pcsp). It works through two files pcsp.c and pcsp_lib.c. The first one mainly initialises the alsa device and does more or less book keeping work. The second file accesses pcm data from the dma region and sets up pwm signal correspondingly as Hunyue pointed before. There is also a lot of stuff for accessing the hardware timers which I have stripped out.
I am having some compiling problems right now using this makefile ( http://pastebin.com/EnFjfNZa ) and, these files pwmsp.c(http://pastebin.com/0XS7sNxA) and pwmsp_lib.c ( http://pastebin.com/JRFfcMcU ). It gives me these errors http://pastebin.com/Byhkz4rT .
Plans
* After fixing these compiling errors, I will test this driver and make a demo for this.
Status
* I managed to modify the pcsp driver (/usr/src/linux/drivers/pcsp). It works through two files pcsp.c and pcsp_lib.c. The first one mainly initialises the alsa device and does more or less book keeping work. The second file accesses pcm data from the dma region and sets up pwm signal correspondingly as Hunyue pointed before. There is also a lot of stuff for accessing the hardware timers which I have stripped out.
I am having some compiling problems right now using this makefile ( http://pastebin.com/EnFjfNZa ) and, these files pwmsp.c(http://pastebin.com/0XS7sNxA) and pwmsp_lib.c ( http://pastebin.com/JRFfcMcU ). It gives me these errors http://pastebin.com/Byhkz4rT .
Plans
* After fixing these compiling errors, I will test this driver and make a demo for this.
Monday, July 26, 2010
Week 9 report
Report for the week 19-7-10 to 26-7-10
Much of this week was spent trying to read up on ALSA. But the documentation is not that good.
Status
* Added prescaling via another ioctl() call. This will now allow us to obtain really slow PWM signals. Prescaling allows division of the input clock by powers of 2 i.e. from 2 to 256. This seems like a very neat feature.
* The PWM10/11 can be optionally controlled using an FCLK of 13K Hz. This gives more granularity. This has also been setup as an ioctl() call.
Plans
* I was hoping to have something working wrt ALSA by now but haven't been able to come up with anything. I am still looking for some sample plugin which I could use as the base and build forward from that. There is not much in the way of documentation when it comes to writing external plugins. I am going to need some help with this.
Much of this week was spent trying to read up on ALSA. But the documentation is not that good.
Status
* Added prescaling via another ioctl() call. This will now allow us to obtain really slow PWM signals. Prescaling allows division of the input clock by powers of 2 i.e. from 2 to 256. This seems like a very neat feature.
* The PWM10/11 can be optionally controlled using an FCLK of 13K Hz. This gives more granularity. This has also been setup as an ioctl() call.
Plans
* I was hoping to have something working wrt ALSA by now but haven't been able to come up with anything. I am still looking for some sample plugin which I could use as the base and build forward from that. There is not much in the way of documentation when it comes to writing external plugins. I am going to need some help with this.
Monday, July 19, 2010
Week 8 report
Report for the week 12-7-10 to 19-7-10
Status
* Added more ioctl() calls to query the status of the PWM.
* Added some sample code to make using the driver easier.
* Still reading up on ALSA. I now think that I will have to write an ALSA driver to access the PCM data being sent out to the soundcard and convert it over to PWM to output sound on the beagle's PWM pins. Should have something up next week
Plans
* A simple ALSA module should be working by next week.
Status
* Added more ioctl() calls to query the status of the PWM.
* Added some sample code to make using the driver easier.
* Still reading up on ALSA. I now think that I will have to write an ALSA driver to access the PCM data being sent out to the soundcard and convert it over to PWM to output sound on the beagle's PWM pins. Should have something up next week
Plans
* A simple ALSA module should be working by next week.
Monday, July 12, 2010
Week 7 report
Report for the week 5-7-10 to 12-7-10
Status
* Completed making both the circuits.
Here are the demonstrations for both of these
Motor Control circuit : http://www.youtube.com/watch?v=Ro5mdYn98xo
Speaker Control Circuit : http://www.youtube.com/watch?v=O0eAHEV4o28
These are the circuit diagrams http://bit.ly/cyvzyB
* Have read a bit about making a glue layer for ALSA. It is not vey clear to me right now. If anyone has some suggestions on how to go about how to access the data being sent via the ALSA to the soundcard please let me know.
Plans
* Will add some examples to the repo.
Risks
* Now that the hardware is almost working not many risks left.
Status
* Completed making both the circuits.
Here are the demonstrations for both of these
Motor Control circuit : http://www.youtube.com/watch?v=Ro5mdYn98xo
Speaker Control Circuit : http://www.youtube.com/watch?v=O0eAHEV4o28
These are the circuit diagrams http://bit.ly/cyvzyB
* Have read a bit about making a glue layer for ALSA. It is not vey clear to me right now. If anyone has some suggestions on how to go about how to access the data being sent via the ALSA to the soundcard please let me know.
Plans
* Will add some examples to the repo.
Risks
* Now that the hardware is almost working not many risks left.
Monday, July 5, 2010
Week 6 report
Report for the week 28-6-10 to 5-7-10
Status
* The driver can now be used to switch the SCPWM bit (GPTi.TCLR[7]). This allows specifying a positive (SCPWM=1) or negative pulse (SCPWM=0). This has been added as a call to the ioctl() interface.
* Started work on the circuits but nothing to show yet.
* Added more instructions and fixed some indentation issues.
Plans
* Will add some examples to the repo.
* A working circuit would be present by the next week.
Risks
* Same as last week.
Status
* The driver can now be used to switch the SCPWM bit (GPTi.TCLR[7]). This allows specifying a positive (SCPWM=1) or negative pulse (SCPWM=0). This has been added as a call to the ioctl() interface.
* Started work on the circuits but nothing to show yet.
* Added more instructions and fixed some indentation issues.
Plans
* Will add some examples to the repo.
* A working circuit would be present by the next week.
Risks
* Same as last week.
Monday, June 28, 2010
Week 5 report
Report for the week 21-6-10 to 28-6-10
A couple of major things got done.
Status
*The driver now allows simultaneous access of all the PWMs (9/10/11). This is done by making multiple instances of the same driver and using a load time module parameter to specify which PWM signals have to be activated.
*The ioctl() calls have been setup properly and frequency/duty cycle changing can now be done via the these calls. This is a more consistent interface as compared to using echo on /dev/pwm* entries. Also the ioctl () calls make it very easy to add new functionalities. Also now each of the pwm (9/10/11) can have a unique frequency value which was not possible earlier.
*Made the lightning talk. It can be accessed at http://www.youtube.com/watch?v=d_vYMTuSGrM .
*Added more instructions for using the driver.
Plans
* A bug is causing the /dev/pwm* nodes to not be deleted on unloading the module. A mock driver using the same code unloads properly on my linux PC. I have not yet been able to point what is causing this behaviour.This has to be fixed.
*Start making the motor control circuit.
Risks
*The going is smooth as of now, mainly due to support on the #beagle irc channel. Not much risk on the coding side.
*My circuits are mostly quick and dirty type, which just barely work. So the circuit making part will be a bit tough.
A couple of major things got done.
Status
*The driver now allows simultaneous access of all the PWMs (9/10/11). This is done by making multiple instances of the same driver and using a load time module parameter to specify which PWM signals have to be activated.
*The ioctl() calls have been setup properly and frequency/duty cycle changing can now be done via the these calls. This is a more consistent interface as compared to using echo on /dev/pwm* entries. Also the ioctl () calls make it very easy to add new functionalities. Also now each of the pwm (9/10/11) can have a unique frequency value which was not possible earlier.
*Made the lightning talk. It can be accessed at http://www.youtube.com/watch?v=d_vYMTuSGrM .
*Added more instructions for using the driver.
Plans
* A bug is causing the /dev/pwm* nodes to not be deleted on unloading the module. A mock driver using the same code unloads properly on my linux PC. I have not yet been able to point what is causing this behaviour.This has to be fixed.
*Start making the motor control circuit.
Risks
*The going is smooth as of now, mainly due to support on the #beagle irc channel. Not much risk on the coding side.
*My circuits are mostly quick and dirty type, which just barely work. So the circuit making part will be a bit tough.
Monday, June 21, 2010
Week 4 report
Report for the week 14-6-10 to 21-6-10
Have been able to implement a couple of things this week.
Status
*Previously the driver had to be reloaded in order to change the frequency of the PWM signal. Managed to fix this. Frequency is a module parameter and a sysfs entry is generated for it under
/sys/module/pwm/parameters/frequency
This allows changing frequency. In order to do this it just required changing permissions for the parameter (from S_IRUGO to S_IWUSR) and some polling to note the frequency changes.
This is still a bit dirty and I have been told to implement this as a ioctl call. But currently this hack works.
*A big modification is to try and modify the existing driver to allow for multiple PWMs i.e PWM9,PWM10 or PWM11. I am trying to initiate these as instances of the same driver and this has popped up a few bugs in the code. These should get fixed in a day or so.
*Did some code cleanup and also added more instructions for using and building the driver.
Plans
* Implement building the driver during kernel compilation making it a statically loadable module.
* Support switching PWM10 and 11 to use the 13MHz clock as FCLK instead of the default 32kHz clock if the user chooses. This gives more granularity for duty-cycle adjustments.
Risks
* Last week's risks still linger on.
Have been able to implement a couple of things this week.
Status
*Previously the driver had to be reloaded in order to change the frequency of the PWM signal. Managed to fix this. Frequency is a module parameter and a sysfs entry is generated for it under
/sys/module/pwm/parameters/frequency
This allows changing frequency. In order to do this it just required changing permissions for the parameter (from S_IRUGO to S_IWUSR) and some polling to note the frequency changes.
This is still a bit dirty and I have been told to implement this as a ioctl call. But currently this hack works.
*A big modification is to try and modify the existing driver to allow for multiple PWMs i.e PWM9,PWM10 or PWM11. I am trying to initiate these as instances of the same driver and this has popped up a few bugs in the code. These should get fixed in a day or so.
*Did some code cleanup and also added more instructions for using and building the driver.
Plans
* Implement building the driver during kernel compilation making it a statically loadable module.
* Support switching PWM10 and 11 to use the 13MHz clock as FCLK instead of the default 32kHz clock if the user chooses. This gives more granularity for duty-cycle adjustments.
Risks
* Last week's risks still linger on.
Monday, June 14, 2010
Week 3 report
Report for the week 7-6-10 to 14-6-10
This week was a bit slow due to some college project presentations, vivas, etc.
Status
*Got the OE as well as the Code Sourcery toolchain setup.
*Got to test existing existing code . Instructions from the README for patching the defconfig did not work out for me so instead just manually edited the defconfig and all went fine. Two things have to be changed to make the existing code work out for a Beagleboard.
-Enable clock reset (CONFIG_OMAP_RESET_CLOCKS=y)
-Set the CONFIG_OMAP_MBOX_FWK=m
*My fork of the above repo can be found here.
Plans
*Currently the module has to be reloaded to change the frequency of PWM.This is because it is being passed as a kernel parameter at load time. Will try and fix this.
*Only one PWM pin can be activated currently (PWM on pin 10). This will be fixed by making the PWM pin as a load time parameter.
*Make final tasks list for mid term evaluation and get working on it.
Risks
*Still very new to kernel programming, so will take longer for simple tasks.
*Too much world cup watching :)
This week was a bit slow due to some college project presentations, vivas, etc.
Status
*Got the OE as well as the Code Sourcery toolchain setup.
*Got to test existing existing code . Instructions from the README for patching the defconfig did not work out for me so instead just manually edited the defconfig and all went fine. Two things have to be changed to make the existing code work out for a Beagleboard.
-Enable clock reset (CONFIG_OMAP_RESET_CLOCKS=y)
-Set the CONFIG_OMAP_MBOX_FWK=m
*My fork of the above repo can be found here.
Plans
*Currently the module has to be reloaded to change the frequency of PWM.This is because it is being passed as a kernel parameter at load time. Will try and fix this.
*Only one PWM pin can be activated currently (PWM on pin 10). This will be fixed by making the PWM pin as a load time parameter.
*Make final tasks list for mid term evaluation and get working on it.
Risks
*Still very new to kernel programming, so will take longer for simple tasks.
*Too much world cup watching :)
Monday, June 7, 2010
Week 2 report
Report for the week 31-5-10 to 7-6-10
Status
*Most of this week was spent trying to configure a development environment and building a kernel. I have tried the normal OE route with bitbake i.e
./oebb.sh bitbake -c build linux-omap
but this ended up in failure due to some dependencies being ignored. Simultaneously I am trying to do it manually as per the steps detailed here. My cross compiler is not setup properly and this is running into trouble.
For the last day
./oebb.sh bitbake console-image
has been running and hopefully it will fetch all the dependencies allowing me to only build the kernel from the next time on. I am really new to this stuff so this will take some time.
*Meanwhile here are the circuits
1) Motor control
2) Speaker Control
These are still in draft stage and would love to hear what everyone has to say about them.
I designed these with eagle . Nice tool.
*Learnt a few important things about kernel development through irc. Most of the stuff that i posted as threats last week, i.e connecting a mouse or a display screen to the beagleboard, are not really required for my project. The serial interface is all that is needed.
*Found out about this project . We have decided to build on top of it. This will also be the repository for my project.
Plans
* The dev environment should be setup and I would start fiddling around with the existing code.
* I will have a go at breadboarding these circuits.
Risks
*Although a bit unlikely but I might still be stuck trying to build the kernel and setting up the dev environment.
*Breadboarding may not go smoothly, which according to Murphy's laws will be so :).
Status
*Most of this week was spent trying to configure a development environment and building a kernel. I have tried the normal OE route with bitbake i.e
./oebb.sh bitbake -c build linux-omap
but this ended up in failure due to some dependencies being ignored. Simultaneously I am trying to do it manually as per the steps detailed here. My cross compiler is not setup properly and this is running into trouble.
For the last day
./oebb.sh bitbake console-image
has been running and hopefully it will fetch all the dependencies allowing me to only build the kernel from the next time on. I am really new to this stuff so this will take some time.
*Meanwhile here are the circuits
1) Motor control
These are still in draft stage and would love to hear what everyone has to say about them.
I designed these with eagle . Nice tool.
*Learnt a few important things about kernel development through irc. Most of the stuff that i posted as threats last week, i.e connecting a mouse or a display screen to the beagleboard, are not really required for my project. The serial interface is all that is needed.
*Found out about this project . We have decided to build on top of it. This will also be the repository for my project.
Plans
* The dev environment should be setup and I would start fiddling around with the existing code.
* I will have a go at breadboarding these circuits.
Risks
*Although a bit unlikely but I might still be stuck trying to build the kernel and setting up the dev environment.
*Breadboarding may not go smoothly, which according to Murphy's laws will be so :).
Monday, May 31, 2010
Week 1 report
Report for the week (24-5-10 to 31-5-10)
Status
*Downloaded the Angstrom demo image and logged into the uboot shell
*Partitioned SD card and setup angstrom image on it
*Booted Angstrom demo image on the Beagleboard
*Made the final draft for circuits to be used for motor control and speaker control
*Got the blog upto speed
Plans
*Control Beagleboard through VNC.
*Study other such drivers and start working on the architecture.
*Start breadboarding the circuits
Risks
*Output is not showing on the TV screen through S video
*Mouse not working through the usb port
Status
*Downloaded the Angstrom demo image and logged into the uboot shell
*Partitioned SD card and setup angstrom image on it
*Booted Angstrom demo image on the Beagleboard
*Made the final draft for circuits to be used for motor control and speaker control
*Got the blog upto speed
Plans
*Control Beagleboard through VNC.
*Study other such drivers and start working on the architecture.
*Start breadboarding the circuits
Risks
*Output is not showing on the TV screen through S video
*Mouse not working through the usb port
Wednesday, May 26, 2010
Born to Run : Out of the box experience
I had been waiting with bated breath for couple of weeks to receive my BeagleBoard but was a bit sad when I learned that my shipment had been lost in transit.
A new shipment was created, through Digikey this time, and to my pleasant surprise the package arrived on time.
It was Fedex this time as compared to DHL the last time around.
Thanks Cathy for making the new shipment !!
I opened up the package and wow! I had not expected the Beagleboard to be this small and light!!.
My father could not believe this was a SBC.
I then powered it up and hooked it to my television with a S video cable and the vertical colour bars appeared.
But all was not well !!My plans of world domination were cut short by the BeagleBoard not giving out any data on the serial port. After a bit of discussion on IRC (#beagle) and using the hack suggested by drinkcat , a fellow Beagleboard GSOC participant, the problem was fixed.
It turns out that nothing was wrong with the beagleboard or the usb to serial converter which I was using. The IDC10-DB9 cable was wired the wrong way and a simple rewiring job was all that was needed.
Now I am serially controlling the beagleboard shell.
Onto setting up the development environment, building Angstrom, booting the BB from a memory card.
And not to forget world domination!!
TO DO: Post Pictures
A new shipment was created, through Digikey this time, and to my pleasant surprise the package arrived on time.
It was Fedex this time as compared to DHL the last time around.
Thanks Cathy for making the new shipment !!
I opened up the package and wow! I had not expected the Beagleboard to be this small and light!!.
My father could not believe this was a SBC.
I then powered it up and hooked it to my television with a S video cable and the vertical colour bars appeared.
But all was not well !!My plans of world domination were cut short by the BeagleBoard not giving out any data on the serial port. After a bit of discussion on IRC (#beagle) and using the hack suggested by drinkcat , a fellow Beagleboard GSOC participant, the problem was fixed.
It turns out that nothing was wrong with the beagleboard or the usb to serial converter which I was using. The IDC10-DB9 cable was wired the wrong way and a simple rewiring job was all that was needed.
Now I am serially controlling the beagleboard shell.
Onto setting up the development environment, building Angstrom, booting the BB from a memory card.
And not to forget world domination!!
TO DO: Post Pictures
Sparks : An Introduction
A warm welcome to everyone reading this blog.
This blog is meant to document my trials and tribulations, little victories and successes as a student participating in the Google Summer of Code 2010.
After much hardwork , discussion (irc chats) and a couple of sleepless nights I submitted my application to the Beagleboard.org on 7th April. The application underwent a rigorous review and I was informed on the 26th of April that my application had made the cut. It is the best birthday gift I have ever received :D.
The idea involves building a driver to exploit the latent Pulse Width Modulation capabilities of the Beagleboard , developing a couple of demo applications of the driver and document them in an easy to follow manner.
This blog is meant to document my trials and tribulations, little victories and successes as a student participating in the Google Summer of Code 2010.
After much hardwork , discussion (irc chats) and a couple of sleepless nights I submitted my application to the Beagleboard.org on 7th April. The application underwent a rigorous review and I was informed on the 26th of April that my application had made the cut. It is the best birthday gift I have ever received :D.
The idea involves building a driver to exploit the latent Pulse Width Modulation capabilities of the Beagleboard , developing a couple of demo applications of the driver and document them in an easy to follow manner.
Subscribe to:
Posts (Atom)
