Fred's firmware development diary

[Fred]

Those issues are fixed now! There is a new timing issue, which is subtle and requires some detailed attention. I will attack it tomorrow and hopefully we can get a result then.

http://stuff.fredcooke.com/weird.half.dwell.issue.png

On channel 2, in the middle, that pulse should be twice as long... odd.

Fred.

[Fred]

That one is fixed too, it was some legacy code overwriting the correct values for a short period creating a low chance of a failure.

The current issue is known and solvable easily too. You can see it here:



So easy to find with the saleae logic analyser... :-)

Thank you kind sir! You've certainly done what you intended and helped FreeEMS advance at a higher rate than it otherwise could.

Next up, some light relief for those low rpm sparse input pattern engines such as the ex-hotel and sean's v8. After that it should run almost anything there is a good decoder for!

Fred.

[Fred]

Progress has been HUMMING along recently. I've had little time for the forum, or anything else much, just the code is getting my attention. Tonight I semi completed a change that allows super low rpm scheduling to work just fine. I've tested it on a lathe, but need to test it on a car now. Sean, pull finger my friend. We need you!

Fred.

[Fred]

The uber low rpm extended output scheduling code change works great. I'll add back in the other options, but this will probably be the default in future, and is currently the only option with the older stuff commented out. We fired up Sean's turbo LT1 camaro using this and saw 12 ignition event scheduled for long output, with probably most of those actually run too. The car starts up STRAIGHT away, unlike it did on ms2 before the upgrade. VERY nice :-) I'd love to setup a skyline with similar code, it'd be slightly better again than that! So good... I <3 FreeEMS :-)

[Fred]

Tonight we did a lot of work towards FreeEMS' most extreme install to date. 1600cc injectors on a 2.3 litre four cylinder turbo Volvo that is currently running MS3. That HAS to change...

There appeared to be some weird code issue. I'm going to take a look now, then hit the sack. It's 330am now, and I'm pretty tired. Hopefully we can get it all ironed out tomorrow and fire up the beast that it is on the bestestest EMS in the world (well, OK, not yet, but it's going to be right up there!) :-)

Fred.

[Fred]

I'm in Spain now! And hopefully with a more stable normal life ahead of me, at least, as normal as the life of Fred ever gets, anyway.

FreeEMS is now a viable usable solution for a number of vehicle platforms! Great news! It's just a bit rough around the edges. Plans for FreeEMS now are as follows:

• Tidy up all half done work on the firmware.
• Add one or two or three more decoders.
• Update all of the documentation
• Release 0.2.0 with some of the above in it.
• Coordinate with Dave and Sean and Gufi to get releases of MTX, Loader, OLV out to match the firmware.
• Publish photographs, videos and stories of each and every FreeEMS success.
• Improve and update all of the diyefi and freeems websites and server infrastructure
• Evangelise and spread the word throughout the world on as many car forums as I can be bothered with.
• Do sufficient testing to stabilise the hardware interface document and pin out design and related standards and certifications.
• Based on Puma Spin1 or some point before the "bad" changes went into the Spin2 design, fork and create a conservative mostly SMD reference hardware platform, have it manufactured, and get it into circulation WITH good documentation.

After that, back to the firmware with some of the following:

• Develop XML interface mechanism to allow proper dynamic support for tuning software.
• Add unit testing framework and suite of tests to ensure consistent releases.
• Optimise and improve some code that is currently considered stable, but only once wrapped in tests.
• Integrate XGATE BB code for many more channels.
• Add task scheduling algorithms and mild HAL interfaces for feature code.
• Add more features
• Add more decoders
• Do more releases
• Profit

I'll refine these items more over the next few days as I get started on them. I already upgraded all the packages on the server, and started researching the long awaited mail server upgrade. Lots more to do. I want to distribute the documentation work in a low overhead way using git. Lots of cool stuff is on the horizon. I'm excited to be at this point, finally, and basically right on the edge of major success. Hooray, about time.

Fred.

[Fred]

Tonight good people, I fixed the bug that was crashing the mac, hoo-fucking-ray. Not only that, but to celebrate, I drank half a bottle of Spanish Garnarcha with 15 meses en oak. Yum. Now I feel good. So, to further the celebrations, after I do the dishes (she "cooked" mostly) I'm going to go to bed, and "sleep" and it's going to be very restful, for me, I'm sure of that. Hooray, tambien.

Fred.

[Fred]

I also fixed another small bug in MTX which caused bad rendering on my EEE for the 3d stuff.

For the time being, please note, MTX is NOT safe to use with mac os x and FTDI. The fix that I added to it broke all MS support, and there wasn't a clean way to add it in a "persona" specific way, as far as I could see. Thus MTX does not have the fix at this time. msloader and mtxloader should have it and should work well with any serial adapter on osx or linux or even windows. good news. Sean's loader works fine on linux and mac now, with the fix, and needs porting to windows, which should be a small deal, hopefully.

Now that I have a loader, I have no excuse not to get stuck in and get some serious firmware work done. There is still something bugging me, but I might do some other work, and see if I can get it to function cleanly in the final form, even if I don't understand the problem with the intermediate form.

I should try to write a list of stuff that is wrong with the firmware that I want to fix, too. Quite a lot, but nothing serious, really.

Not tonight, though.

Fred.

[Fred]

For always on functionality, we need a bit of new code:

When we get told to go to sleep, we need to turn off clocks and so on and so forth and set a flag and disable the main loop, possibly by changing while(TRUE) to while(allSystemsAreGo) where the value of that condition is dependent on clock and sleep states etc.

When we wake up we need to restore all of the above functionality before allowing normal code to run. Some calls to existing init routines could be useful, or made to be useful.

As it turns out, ALL interrupt sources can generate a wakeup, thus all interrupts except some chosen one need to be turned off and disabled before going to sleep, currently I'm thinking "stop all interrupts" then "disable all interrupts cept our wakeup" then "restart general interrupts". Likewise, when waking, the whole lot need to come back on again, cleanly. Currently our interrupt init mechanism sucks anyway, so the foundation to this work is going to be to fix that up and maybe make the control mechanisms for that be generally accessible for use in this scenario. EG, currently the serial interrupt fires once at boot, for no reason...

Thinking about this some more, I guess we'll wind up at the line after the one we went to sleep on, so it'll be something like this:

Code: Select all

notice that its time to sleep
tidy up loose ends
disable all interrupts
disable individual interrupts
enable "all" (just one now) interrupts
record current state and data etc
signal mcu to go to sleep
<hours/days/years go by>
assume that we just woke up (this may need some delay or busy wait loop on some sort of clock flag or similar to prevent wakeup code running while shutting down? RTFM)
fix up all clocks, states, setup variables, etc
reconfigure all interrupts
exit to normal running

Fred.

[Fred]

Some random notes on things to look at and add, not including the known items referred to but not mentioned above.

Implement COP mechanism without lower threshold.

Setup EEPROM to record information about shut down and start up including time/date, sensor values, etc. Note that no shutdown tag = went down unexpectedly, log this as part of startup info.

Assign a pin for wakeup duties, write code for stop/sleep/wakeup, test.

Read docs further to determine if loader can check for blankness using the hardware command prior to writing.

Look at suggesting that Sean split timeouts into expected time to reply in terms of X bytes * Y rate + internal processing time (burns take a known period, as do erases) + hardware latencies, all parameterised. See page 1261 of the manual.

Look at moving the ADC sampling to not sample continuously and to sample when triggered from the decoder, and then read the values from the registers in the adc interrupt or main loop where they are converted to usable values. This needs thought, see previous post in this thread about different requirements for sampling different inputs.

If using the interrupt method, consider self triggering from the interrupt in order to obtain multiple readings in a short time frame and then average them in some fashion.

Review datalogs to find slow temperature change showing transition "noise" on adc line of single step as it gets closer and closer to the next value. Look at ways to make this transition a single step with minimal lag and min processing time and maximal response and minimal memory footprint.

Setup config data for decoders in its own block and make it indexable from outside, and make the shared data come from each decoder such that defaults are reasonable.

Design a mechanism for programmable ADC sampling in decoders, source data from flash config.

Think about making all decoders behave the same way with respect to first signal, first rpm, first schedule etc.

Add logic wrapping sched to unsched if no valid upto date info for angular speed is available. Leaving existing sched info in place is bad/wrong/dangerous. This should be the default state until first crank occurs and provides usable data.

rest - no sched occurs
decoder receives initial signal, records data - fuel pump comes on
decoder receives sync info, uses past data to generate angular speed information and does prelim adc reading - calculations get done
decoder receives next signal - output scheduling begins
sync lost by timeout or bad signal - all pins are unscheduled

logic for this should not exist in each decoder as it is shared functionality, hence putting it in the scheduler such that nothing is scheduled.

Scheduling check loop, WITHOUT actual scheduling seems too slow, figure out why and fix.

SCM and CME and so on should be checked, this may help with the issues Spudmn is facing. Perhaps we can configure a limp mode for the code such that it outputs some help message on serial? see 2.4.2.2 for details.

CRG section of the manual contains all of the necessary info for always on implementation. Need to keep in mind simpler on-with-key system designs while implementing this.

More later.

Fred.