Today was MSP430 timer day. I spent an hour or two programming the MSP430. I first got timer B running off the watch crystal. Worked fine.
Then it became apparent that this would only allow the MSP430 to be asleep for 8 seconds at a time. If I want to be really low power this wasn’t a good thing. So I thought for a moment and then realised that, using the timer peripheral’s insane output module, I could get Timer A to generate a 0.5Hz (or lower) clock that I could then use to clock Timer B. The net result of this is that the MSP430 can stay asleep for about 97 days without waking up to increment the timestamp :-) I got this setup working, so now it can sleep for extraordinary amounts of time!
Thought about I2C for a short period as well, and came to the following conclusions:
- The gumstix will be the bus master when talking to the gumsense. This way, the MSP430’s lack of known-frequency instruction clock isn’t a problem because the gumstix will be doing all the clocking.
- The MSP430 may need to communicate with some I2C devices to take samples. This would mean that the MSP430 would have to switch to being the bus master whilst the gumstix is asleep. However, this could prove problematic for the “take a sample” now command that the gumstix can issue to the gumsense. Perhaps the solution is to have an extra IO line between the MSP430 and gumstix that states when it’s OK for the gumstix to use the I2C. That way, the “take a sample” now command would actually be a “start taking a sample now” and then there would be another command for reading the results of that sample.
I’ll work on the I2C code next I think. I’ll need to have a bus master for it to communicate with, so I’ll set up the gumstix to communicate with it. In order to make sure that I know what I’m doing when it comes to I2C and linux I’ll plug in a PCF8574 IO expander onto the bus first.
Things that have happened since yesterday:
- I powered up the MSP430 with a watch crystal attached to it. Sticking a scope on the crystal showed that it was oscillating.
- Built a small board for adapting between the TI parallel port JTAG tool (not quite sure what it’s called – possibly a Parallel port FET tool?) and a breadboard
- Bought a power supply.
- Discovered that there’s some problem with the gdbproxy tool that comes in the cdk4msp rpms, which means that it works with only some MSP430s – it worked with the MSP430 development board that I’ve got (MSP430F436), but not the MSP430F169 that I’m using. The binaries from the mspgcc project worked correctly.
- Wrote a (very) small test program. Probably could be considered as the “hello world” of microcontroller programmers – toggled an output pin’s status continuously.
- Danced.
Haven’t written much over the last few weeks (been busy with train usage and other things). Last wednesday I made a pcb for adapting between a 64 pin LQFP and DIP. On sunday I destroyed it by being incompetent. Today I remade it (in about 1 hour 15 minutes) and soldered an MSP430F169 onto it with no problems. Here’s the result:
Next stage: connect it up. That’ll happen tomorrow.
Over the past few days I’ve been working on a yum plugin that will pick-up local yum repository mirrors using avahi. It wouldn’t have taken that long to sort out if I hadn’t failed to read the bit of the dbus tutorial I was reading that said I’d need “import dbus.glib” to make callbacks work.
I spent many hours trying to work out what was going on. Steve found the problem with me not importing dbus.glib. Thanks Mr Steve.
I’ve put the code up here. It’s a git repository. Grab it using:
git clone http://www.ecs.soton.ac.uk/~rds204/yum-avahi/.git
There are two python files: repos_announce.py and repos_listen.py
repos_announce.py: This is to be run on the server. It uses avahi to tell the rest of the network that a yum repository is available locally. It points to the http server that it runs which servers the “conf” file, which contains the configuration for the various yum repositories.
repos_listen.py: This is the yum plugin. Stick it in the yum plugins directory (defaults to /usr/lib/yum-plugins). The yum plugin also requires a configuration file called “repos_listen.conf” which sits in the yum plugin config directory (/etc/yum/pluginconf.d), and this needs to contain:
[main]
enabled = 1
Currently it will only attempt to grab repositories that you already have configured.
I reckon it’s a relatively safe thing to have enabled even in potentially unfriendly networks, as long as you have gpgkey checking enabled.
Comments welcome.
I wanted some RPMs containing the work from mspgcc. I came across CDK4MSP. Downloaded the RPMs. Installed. Appears to work.
Site by Rob Gilton. © 2008 - 2019