Fred's firmware development diary

[Fred]

The next release will be out tomorrow! I worked on it all day and night but realised I wasn't quite finished just yet and couldn't get it done tonight. All that is left is finishing release automation with the makefile as inspired by maven! :-)

Fred.

[Fred]

Well, I finally got it done, I released UltraJizz, and perfectly on-time, too!

http://www.diyefi.org/forum/viewtopic.php?f=41&t=849

Dev is all go again :-)

[Fred]

Other than the bit field experimentation which I'll probably decide to run with and finish off later, I've fixed the ADC config today. I had not configured one of the registers that sets the ADC module clock... so it was out of range... and now it's not. I noticed this due to innaccurate readings of battery voltage. I actually noticed that on the road in the Volvo too, but put it down to resistor value tolerance. In the lab, right now, these settings produce a full 1023 reading at 4.8V instead of 5.0V which is still not right, but with the old settings max occurred at 4.65V or so. I'd like to understand why this reads this way, but currently I don't. I just know that it does, on the TA board, at the least. If anyone reading this has any thoughts, feel free to comment! More work to come over the next few weeks, I promise! :-)

[Fred]

I've done a little to FreeEMS recently, but once I have some more time post China, I'll be doing a lot more. I've had some great ideas about code and stuff while here, and I'm excited about implementing some of them. Plus, the Tuner situation is on the up, with Marcos getting ECUManager working with it in the last couple of days and some thought being put into how to modify MTX to work with it too. Having three tuning authors giving me a hard time will motivate me to finish that aspect of the firmware, something that is pretty overdue. It works OK as is, but we need to polish it and finish some of the higher level design aspects pretty soon.

http://stuff.fredcooke.com/ECUManagerTa ... stTime.png

And HD video : http://www.youtube.com/watch?v=qZ6mAtnTFXE

Awesome work Marcos! I look forward to more! :-)

Fred.

[Fred]

Tonight, not for FreeEMS, but for EdwardSquirt, I wrote a scheduler!!! I've been thinking about how to do that for years, and today I did it. I ran it around noon and started coding first thing, i tried it, and it worked perfectly first try, yay! I took a video of it to demonstrate, note this is NOT FreeEMS code, but something very similar, slightly slower, much more generic will be included in FreeEMS sometime soon.

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

Fred.

[Fred]

Today was the last day coding on EdwardSquirt, for a while, at least, so for the next 2 weeks, if I get a few spare minutes, I'll be working on FreeEMS again in NZ. I've been flat out busy here working on this system, it works well enough, for now, and the limitations are known, and my time here is up. All in all, everyone is more or less happy. System works, system owners delivered with crash course in EFI and electronics, future direction clear enough. Hooray.

More news from us soon! :-)

Fred.

[Fred]

On the flight back from Hong Kong to Auckland I worked on pseudo code for a generic scheduler that would work for any wheel pattern. Mean while, Sean[0] has been working wonders on the binutils code and has successfully run XGATE code from the FreeEMS code base! Congratulations to him. In a week or so, we'll merge the code bases and distribute binutils installers for win and deb based systems. From that time on FreeEMS will officially be using XGATE, at the very least, to flash an LED :-)

I'll be taking a dev board and serial cable on my next little trip, so will try to get some work done from time to time :-)

In the next few months I'd like to finalise the real time code, scheduling, several wheel decoders, etc. Get them modular make sure the code reuse is good, etc etc. XGATE will be crutial to that as it's going to do at least some of our bit banged output pins, and do them well.

It's likely that I'll impose a limitation on low tooth count wheels forcing them to have their triggers close to, and before, the point where they need to start dwelling, and/or firing. More thought is required on that. With current timer resolution, which I think is appropriate, 52ms is the maximum delay after a trigger point. Dwell needs to start some time before firing (2 - 10ms or so) but this will only be a limitation during starting and below idle speeds. At higher speeds it'll be a non issue. I think such a limitation is acceptable given how much it will improve the code base, how many users it will affect, and how small an effect it will have upon them.

Fred.

[Fred]

On the flight over to Vancouver this morning I did some more work on the scheduler thing. There are quite a few limitataions and aspects to consider for the generic approach so I'd like to lay it out as formal requirements and limitation decisions and proceed on that basis. If this is done, there is every chance that people like Jean and Abe and and and will tear holes in it and make me make it right/better. More to come.

Fred.

[Fred]

I just built FreeEMS with XGATE code in it! I estimate that we will have an XGATE release inside the next month. That would be cool :-) All credit to SeanK who has been working his arse off on this. See the Advanced section for more detail. Good work young padawan.

[Fred]

Spent the afternoon working with Sean on xgate tool testing. Tomorrow we could have it integrated into the main trunk. If so, you'll be required to build using Sean's tools from now on. It could take a few days to clean things up such that windows users can install them, but linux users, and probably mac users should be ok.

The tool set will probably consist of three or four deb packages and will all need to be installed to work correctly. Hopefully we can make the windoze installer a single item that puts gcc, newlib and binutils in in one go.

More news tomorrow with some luck :-)

Fred.