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.

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.

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 :)

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 :).