- 0830: Received a text from Tom containing a highly compressed set of questions relating to the power board. Set about answering them when I got up.
- Processed some paperwork.
- Worked on Farnell screen scraping – progressing nicely. Some nasty problems involving Unicode strings getting munged about though.
- Read about John’s escapades.
- Had some xbee related conversations with Phil. Sadly massively diverged into setting up his ssh config.
- The random period of immense internet laggyness started early today. Around 7pm I guess. Moaned profusely.
- Performed a very short investigation investigation into radio modules for general stuff-monitoring projects. Decided that the CC2420 might be good – but a little expensive (~£5 a chip from Farnell). Will continue search for cheaper alternatives. Would be good to produce a large number of devices that use them.
- Looked for an extension lead casing manufacturer. Was pretty unsuccessful. Wanted to find an extension lead casing with space for some extra electronics in it…
Pin headers are found in Connectors -> Multipole -> PCB Header and Jumpers
“The most robust and expensive solution is to use a MAX6348 Power-On-Reset device”
Sounds like a challenge…
The day when we have an open source FPGA will be a good day.
The engineers at Maxim must be completely and utterly unhinged. The MAX9911 (datasheet) is absolutely nuts. It’s got a “low” shutdown current of 1nA. 1nA! Yarrrrgh! I want to know what they regard as “very low”…
I want to be able to program and debug PICs with my MPLAB ICD 2. Unfortunately, Microchip doesn’t spec the USB interface to the ICD 2, so unless I reverse engineer it there’s not much I can do but use the Windows software they provide.
I don’t like windows.
So, I installed Windows Server 2003 in the version of QEMU that the KVM people produce. The install ran really smoothly up until there were 39 estimated minutes remaining. It then took around 4 hours to complete. I installed MPLAB in the VM, plugged the ICD 2 into my laptop and then “plugged” it into the VM’s USB. One of those annoying little “you’ve just done something” balloons appeared and I selected “automagically locate driver”. It failed to find a driver. Urgh.
I then thought “Hmm. I haven’t actually tested that MPLAB works in the VM”. I ran MPLAB. It said something along the lines of “MPLAB doesn’t work in this operating system”. Damn.
So, I started to create a new VM containing XP. Many hours later I had a fresh install of XP. Installed MPLAB. Ran MPLAB. Worked. “Plugged” ICD 2 in. No magic bubble. Rats.
“Perhaps I need SP2… I’ll run Windows Update.”
I ran Windows update. Many many many hours later I have SP2 installed. Plugged in ICD 2 and joy – magic bubble appears. Automagic search for driver successfully installs the driver.
From when I’ve used the ICD 2 before, I remembered that when one plugs it in, you get two magic windows “device connected” beeps – and one has to install two drivers. I’d only installed one on the VM and the magic bubble generator appeared to have run out of fuel.
Then I noticed that the USB Device ID of the ICD 2 had changed. Presumably the first driver changes it in some way after loading firmware into the ICD 2. Telling QEMU to connect the second device caused Windows to locate the device and to generate another magic bubble.
I ran MPLAB and it successfully updated the “operating system” on the ICD 2:
I have yet to try it with a PIC… That’s the next step :-)
Jeff, Steve and I were just considering using capacitors for powering things instead of button cell size batteries. We thought about moving the plates apart as the capacitor discharged so that the voltage increases. Then I thought why not use a squidgy dilectric so that the width between the plates increases as the charge decreases as a result of the force between the charges on the plates. Of course this all relies on finding some sort of suitable dilectric.
I’m writing it here so that Steve can’t patent it :-P
What is it with internet vendors and not understanding how to sell things through websites? Farnell’s website went through an “upgrade” a couple of weeks ago. I’ve just attempted to use it. They seem to have removed the ability for one to remove the individual search criteria that one has applied. They don’t even let you see them!
The Farnell website must be continuously trawled by electronic engineers looking for things. It’s as if they’ve never ever talked to any of them nor read the torrent of annoyed feedback that must pump into their website all day long!
So, a plan. I fair to believe that there aren’t thousands of people who are irritated by Farnell’s website. So I’ve started a petition. Sign it!
Four days ago I started working on getting the Gumsense to turn the Gumstix supply rail off when Linux has shutdown. I started writing a blog post containing all the things that I had examined. I’m still writing that post; it’s getting pretty long, and will arrive soon.
During that process, I realised that I was going to have to write a kernel driver for the Gumsense. I’ve now written that driver. It’s the first kernel driver I’ve written. It’s a relatively simple driver, but it represents a big increase in my knowledge of Linux internals, and I’m pretty pleased with it. It’s an I2C chip driver and hooks into the Gumstix platform code (which I also had to slightly modify so that I could hook into it).
After a surprisingly straightforward and pleasing construction and debugging session, the Gumstix is now on the Gumsense mark 2 :-) The Gumstix powers up fine and communicates with the MSP430 successfully.
So far I’ve found two mistakes and two slight annoyance on the board:
- I’d missed a ground connection to the output capacitor and diode of the Gumstix switchmode supply. Easily fixed by a short piece of thin blue wire soldered between the diode and a nearby grounded via.
- I’d done something weird in the Eagle schematic editor. Eagle has an annoying feature that allows two unconnected wires on the schematic to become part of the same net. That’s not so bad – normally I promote using netnames to connect different parts together. The problem is that in this case, only one of those tracks is labelled. So, I ended up with the MSP430 supply being connected straight to the voltage regulator rather than going through a schottky diode first. This meant that the button cell initially didn’t do anything. Fixing this required the cutting of 4 tracks and the addition of 2 very short pieces of blue wire.
- The first slight annoyance is that I’ve put a dual diode (BAT54C) too close to a capacitor. It all fits, it’s just a little tight.
- I neglected to put a decoupling/resevoir capacitor on the MSP430 internal reference output pin. The datasheet recommends this. I’d written it down in my list of things to do before the board went off to made too. For some reason, I just completely ignored it.
So, the blue wire count is now three. Analogue section next.
|<< Newer Posts||Older Posts >>|
Site by Rob Gilton. © 2008 - 2019