Fred's firmware development diary

[Fred]

Big thanks to Mike and Andy for their efforts tonight! Most appreciated. It's 4:20am here, time for me to turn in for a few hours before my phone date in the morning. Branch "fredfixes" has been updated with a number of key fixes and new functionalities. Recommend using it if you're using EMStudio from source. All I've done is ask questions and provide advice and direction for the last 2.5 hours. Time for a snooze. BIG day tomorrow, and equally big Thursday, with a HUGE weekend ahead. Will update as I can. Fred.

[Fred]

Tonight I did a number of things, but chief amongst them was design an entire new internal architecture for the firmware. What? Yep. I came up with what I think are workable changes and patterns to do the things that we need to do. I'll probably try to get some of them hacked in soon, but I'm not going to go public with any of it until two things happen. One of them is all current stuff has been tested by everyone. Maybe I'll even make Sean pull out the Camaro :-p

Did some work on the new secret app too, but nothing major, just messing around, really.

Fred.

[Fred]

Busy days!

Engine 20 turned out to be running on Alpha-N mode. I "wrote" that 5 years ago as a space filer until I had time to think about it more and do something better. I never tested it. But they did. And today, we even tuned with it a bit. Pretty cool.

I finished assembling their jag 0.4-alpha FC special addition an hour or so ago, tonight. Tomorrow it will be hooked up to engine 20 and tuned more. Redoing their wiring setup and using the Jag will improve reliability no end. Today we got struck by a few things including relay switch off spikes causing sync loss and dry joints causing a 3 cylinder engine, rather than 4.

I may even get to write some code before I leave :-)

Fred.

[Fred]

The last six days have been HUGE, slept just 4, 5.5, 4, 6, 6.5 hours in between them! Did lots of soldering, lots of advising, lots of giving people shit, lots of taking shit, saw engine 20 fire up and almost sound healthy, got very hot and sweaty in a room with a number of other men, drank a nice bottle of Ozzy red that's not available in Spain, etc etc. Great fun all in all, and pretty productive overall, despite a few disheartening setbacks.

[Fred]

Tonight I learned that the BDM software works fine on my EEE (once I plug in a bigger screen... but that's another story...) and won't work on this box, also running Debian sid. WTF. The screen size thing is a WTF too. It opens shrunk to fit the screen (ignoring insets like start bar etc) and becomes unresizable! Fail.

I will check the versions now...

4.9/4.9.3? - won't work on this box, only intermittently...
4.9.4b - works fine on eee, always, cept when on internal screen...

[Fred]

Additional thing learned tonight, if you have pins shorted out in different states, the CPU gets quite warm, quite quickly. :-p

[Fred]

Tonight I learned that the BDM software works fine on my EEE (once I plug in a bigger screen... but that's another story...) and won't work on this box, also running Debian sid. WTF. The screen size thing is a WTF too. It opens shrunk to fit the screen (ignoring insets like start bar etc) and becomes unresizable! Fail.

I will check the versions now...

4.9/4.9.3? - won't work on this box, only intermittently...
4.9.4b - works fine on eee, always, cept when on internal screen...

And tonight I copied the same one across, installed it, and tried to use it, same behaviour. Either my kernel/system is broken, or some libs. MTX is also more broken on this box than on my eee. Grrr.

[Fred]

And now the same behaviour on the eee, but depending upon which socket I push it into... odd. The mac loads ohci drivers, and the eee uhci drivers, but the /var/log/messages output is the same for each of the three ports. I've previously noticed that one of the ports is a bit loose and can get intermittent power, so it's touchy. This is the one that works with the BDM, the less worn one doesn't. WTF.

[Fred]

Doing some work on making FreeEMS brick-shit-house spec today. Found that the PLL stuff self recovers beautifully, but that while screwed the serial is (predictably) corrupted, as it bases its clock on the bus clock. Here is a screeny of a terminal streaming packets:



Each character represents the result of a packet.

"." is good/normal
"B" is bad checksum
"I" is incomplete packet
"E" is escape pair mismatch.
"O" is buffer over length (happened at the top for another reason)

Other clocked subsystems will be affected too, so I should handle this event and cease performing normal duties until it has recovered, and of course, log it.

Fred.

[Fred]

PLL and clock both handled appropriately now. PLL pushed, clock to be pushed soon. Code like this gives me this feeling:

http://www.youtube.com/watch?v=fXW02XmBGQw

Next up, some SM experimentation and addition of COP reset behaviour. Then it'll be pretty robust from a "get stuck" point of view.

Fred.