Fred's firmware development diary

[Fred]

http://web-cat.cs.vt.edu/eclipse/cxxtest/

I might have a crack at setting that up for cross-compilation tests, too.

Both types have a place IMO. The screeny ones for final release/push and cross compilation before even loading it to the device.

Fred.

[Fred]

Someone was asking me about my preferred commit style.

Anything of key importance to the commit MUST be in the first line. Fact. The only way to avoid long lines is to break the commit down into multiple smaller ones, which isn't always possible. Thus long lines have to be considered OK, despite Linus and co. This is fine, though, one tiny setting fixes display:

Code: Select all

[core]
        pager = less -+$LESS -FRX

If you put core things into other lines you will lose them from display in many circumstances, which is unacceptable. The only thing that should go on the subsequent lines are more fine grained details about the same things already mentioned above, nothing new/different.

Fred.

[Fred]

I've drawn up a diagram on how to conduct large-scale OTW tests and hacked some of it together quickly. When I get clear of my other chores I'm going to pursue this a bit further and fully test the one testable function. Then it'll be time to attack issue 156 and add other testable functions to the API. Then it'll finally be time to refactor the living shit out of everything that isn't tested such that it can be, and do it. This will leave the firmware in REALLY good shape for utter reliability into the future. World class stuff, then. But not yet. Not IMO anyway, despite the happy "customers".

New issue: http://issues.freeems.org/view.php?id=750

What this allows is for me to power up a device, hit go, and get a full set of results back some time later. At the moment it's very quick, however bulk tests will take a while to get done.

With full coverage the project will be unstoppable.

The chained conditions feature must wait until after this framework is usable in an efficient way. Then it can be developed and verified before pushing code to users.

Fred.

[Fred]

Just looking at required test cases, for example:

Each type of 2d table needs 65 tests, currently there is only one type, so that's 65 tests.

Each type of 3d table needs 1616 tests, currently there is only one type, so that's 1616 tests.

Other simpler functions will have much lower counts, and these counts could be trimmed to more sensible levels, but that covers most/all corner cases, and is thus robust.

Fred.

[Fred]

Semi-public announcement of number 13! viewtopic.php?f=55&t=1938

More detail once I tidy up my act, and get through my chores.

Semi public = only for those following this thread/forum section, etc. Not for other sites/media, yet.

Fred.

[Fred]

May I proudly present, automated firmware and OLV builds: http://builds.freeems.org/

Use BenchTest from here, or any of them for RPM readings. Building your own from source is better if you want to run something.

I'll be upgrading both over the coming days/weeks. OLV by including additional binary types. Firmware by including custom built s19s and compressing them.

4:34am, time for bed!

Fred.

[Fred]

Nice log showing bad wiring + low battery + detection of it:

[Fred]

Injection style options explanation and chart is now available! :-)

More detail here: viewtopic.php?f=54&t=1941



Fred.

[Fred]

Quick 2am update:

I've been busy for several days working on software components to support my development and raise the quality and rate of my firmware output.

On this, I'm making excellent progress. The next week or so is going to be VERY busy for me, so even if I'm not posting much, I'll be working on something, I promise.

I've created a new forum for my reference tools in the official apps section, written an intro post, and moved my ultimate loader thread there, too. Keep an eye on that section because, from time to time, it'll get some updates.

Fred.

[Fred]

Updates for tonight:

Engine 15 nearly ran. It kicked and bucked and spluttered and coughed and popped, but none of the owners timing guesses were right and it wouldn't fire a timing light with MS-spec outputs to the ignitors (IE, not good enough). Close, soon, very soon.

Loading performance of the Ultimate Loader has peaked and I've moved on to UI and feature stuff, and polishing up the SM lib that it sits on which is still alpha and yet to be formally released.

See updated figures here: viewtopic.php?f=41&t=1922
And more detail here: viewtopic.php?p=30533#p30533

Summary: If you're waiting more than 16 seconds to load current firmware, you're waiting too long.

It can be done in 10 without verify, which is actually reliable, as any failure to answer correctly results in an error, and any failure to write correctly results in an error. So the only way you could get a bad burn is via plain wrong data getting to the device after a correct command or with a corrupt/buggy SM. The latter is very unlikely, and the former pretty unlikely if you're using decent gear. I wouldn't recommend it until the firmware can self-verify, though.

User 'ehb' said something to me a while ago, which recently gave me an idea: If I were to make this tool commercially available, proceeds to support me, would anyone be interested? It's not user-ready yet, so it's just for me for now, but it should be rock solid and user-ready soon.

HW tomorrow!

Fred.