Fred's firmware development diary

[Fred]

After a morning of Dave hacking around on my machine laughing at my directory names and slim disk space margins, MTX JimStim support is almost there. There is a byte offset issue of some sort but otherwise it's cool :-)

The issue that Chris was seeing is the serial interrupt running once at startup time with a bit twiddle debug line in it. It shouldn't do that, so thanks! I need to look at the init stuff and rearrange it until it behaves correctly. Also, the reason that it takes so long to start up and that the led doesn't come on straight away is the flash erase and write at boot time for xgate. I guess we really do *need* the loader functioning because it's just too slow to start right now. Good work being done :-)

Fred.

[Fred]

http://status.github.com - currently fcuked...

For freeems-vanilla, you can always grab the code from these repos too:

Code: Select all

fred@roadeee [09:24:00]:src$ grep url ../.git/config 
	url = git@github.com:fredcooke/freeems-vanilla.git
	url = git@gitorious.org:freeems-vanilla/freeems-vanilla.git
	url = ssh://fredcooke@freeems.git.sourceforge.net/gitroot/freeems/freeems-vanilla
	url = ssh://repo.or.cz/srv/git/freeems-vanilla.git
	url = git@freeems.unfuddle.com:freeems/freeems-vanilla.git

Obviously adjust for read only access, but they should all work fine. I try to keep them all up to date.

Fred.

[Fred]

viewtopic.php?f=8&t=939

It's on! :-)

Fred.

[Fred]

Update to the freeems for xmas pressy thread:

viewtopic.php?f=8&t=939&p=11565#p11565

I've also been poking around the comms code making notes and figuring out a game plan. The last two commits have this work in them.

We need to dig up and figure out the version and data description semantics and format thread/ideas/etc. That is required for firmware to be supportable by tuner authors. This same info will be used by the loader for partial loads. I want there to be only a single source of this information. That means either:

Generating the files from the code and comments, OR,
Generating the code and comments from the files.

I don't want a maintenance nightmare where the files can become mismatched :-/

Along the same lines, I want the version strings to be scripted too so they can't mismatch either.

If I do actually get to the point of having FreeEMS hardware on my truck, then I will need scheduling and missing tooth wheel decoding to work perfectly for that.

Lots to do, and little time to do it in. I am focussed, though. The second FreeEMS engine up and running would make an awesome xmas pressent :-)

Fred.

[Fred]

"FreeEMS, it'll be ready in about 5 years" said a friend of mine. I won't repeat my response to him here.

I did start on modifying the serial API to allow full adjustment of all parameters, though. I should have that knocked out by end of tomorrow. Today it's too late and I'm too tired.

I modified a few headers to be clearer the other night too. Things are getting close comms wise.

Fred.

[Fred]

I spent last night tidying up the binary test packets for Dave to use as examples, so they're much better organised now, all that aren't in "broken/" are tested and work. I'll try to keep them up to date with the serial changes, but right now, they work just fine, and I don't *think* any of the serial changes will break them this time. But, I could be wrong.

Next things are:

• Making the block adjust routines handle partial updates
• Making the returns and errors consistent and cleaner

Then I'll ignore comms for a while and focus on the goals for the next release... and MAKING MY UTE RUN! :-)

Dave is making leaps and bounds at modularising Tunix to support different styles of comms and so forth, hooray! I can't wait to tune my first vehicle using Tunix and FreeEMS, it'll put a grin on my face that will last days!

Till next time... :-)

[Fred]

All packets are acked consistently now! Yay, testing is in progress in the US of A right now. Next is that API change, and maybe a sequence number setup of some sort as that was requested by many people, and I think it's a good idea and we currently don't do it.

[Fred]

I've improved the data location id arrangement and added some extra checks for overly short packets. I added the two api changes to the update commands. And I added the sequence number scheme. This leaves the serial api pretty much complete for now. It will likely grow with time as we add both firmware code and features and more complete tuner support for it.

Next up, documentation! I need to update the written docs to describe how it all works now, and document the data layouts and detailed API.

Tomorrow I need to work on the truck, but in the evening I'll get stuck into the documentation stuff.

2am, long day, another tomorrow, and the one after, xmas coding, fcuk the family, I've got shlt to do.

[Fred]

Today I updated the firmware API document to actually reflect code in the current firmware! GASP. About time...

I also removed some bogus code from the block fetch code that prefixed tables with firmware constants... that was silly/annoying/inconsistent, Dave will love me a little more now.

Finally, I updated the comms change notes to remove all the stuff that is done and/or decided on.

Next is update the core protocol docs and the data description stuff and add more example packets.

Then when Dave is happy enough, I can get back to the next release goals and the ute pcb adapter and the ute fixing.

Fred.

[Fred]

The core protocol document is updated and pushed, editorial review welcome! Ditto for the firmware specific one.

Next up is the sched interface. I'll dig out and update my proposal document and maybe start implementing it. At the same time I'll be putting in a test decoder that uses the same timers and interfaces, but internally to generate the rpm and events from it. RPM will need to be read from some live ram config location and the pattern will need to be fixed. Possibly just default to 36-1 for the time being. This will be useful not only for testing sched code and PIT code etc, but also for testing injectors. I'll need to update the phoney corevars code so that inputs can be configured rather than read, and it'll be testable without a jimstim all of a sudden.

Fred.