- Handed in my project progress report today! I’m glad it’s finally in! Now I can get on with doing some actual work… after writing a management essay…. and doing some exams of course.
- Started some musing about using GStreamer to simulate error correction codes and using them over lossy transmission lines. Mind debating whether the addition of GStreamer is really necessary. It would be kind of cool to put some video/audio over the error corrected lossy line.
- Got slightly more annoyed that I can’t set my default GNOME editor to be emacs (without setting it for everyone on the system)
- Need something to supercede Latex as a document editing system. Compiling the document to see a small change is too slow.
- Been learning how to get my bluetooth headset to work with my laptop. The bluetooth-alsa stuff looks like it has been in a state of flux for quite a while. It seems to be homing in on something good though. My headset almost works with the latest stuff. Apparently I need to use the latest (i.e. git) Linux bluetooth stuff along with the latest (bitkeeper i think) bluez stuff to get it working. At the moment, when I attempt to play something to the headset it successfully creates a connection (indicated by the headset’s magic beep) but then the software gives up complaining about some function returning zero (this was with a very very slightly patched 2.6.19.2). Anyway, looks promising :-) Should be fantastic when mixed with telepathy and gossip.
- My LPC2418 development module was shipped the other day. Now I’ve got to wait around a month until I get it.
Interesting links du jour:
- KVM Gets paravirtualisation – Moderately exciting. Makes me want to run rawhide even more in KVM.
- EU Commission Study Finds You’ll Save Money Switching to FOSS – Yay.
I phoned the Texas Instruments European Product Information Centre (that’s what I think EPIC stands for). I told them that I couldn’t find the specification of the MSP430 debugging interface on their website. I asked them where I could find it. The woman I spoke to passed my query onto the EPIC MSP430 guy, who, after trying to sell me a USB programming/debugging tool (which would not have solved my problem), understood what my question was. His answer can be summarised quite succinctly: “no, TI will not give you any information about the MSP430 debugging interface”.
Great.
So reverse engineering it is. I think (and hope) this shouldn’t be too challenging. I think running strace on the available binary blob will provide lots of interesting and useful information. I’ll look into the legality of reverse engineering things and making the findings public first…
Why do I want to go to such lengths? At the moment, the binary blob debugger/programmer loads data into the MSP430 at a blinding speed of ~100 bits per second. Yes, you read that correctly. I think that the largest MSP430 flash that’s available is 60Kb. That means it would take around 80 minutes to program the device if one used all of the flash. Of course, that’s if the debugger doesn’t randomly “lose control” of the MSP430 in the process! Ah yes, and during that process the machine it’s running on gets hammered because the software uses almost all CPU.
Site by Rob Gilton. © 2008 - 2019