Fred's firmware development diary

[Fred]

Permanent link for installs image/graph/dates. I'll eventually migrate this to a web app, but in the mean time, this will do the trick. I'll just update the symlink to point at the new file each time and it'll be good to go :-)

http://stuff.fredcooke.com/FreeEMS.Installs/

Permanently up-to-date image, currently reading 12:

[Fred]

Spent all day today hacking away at white space! Much better. Issue 434 is closed! Issue 601 has been created!

59 files changed, 681 insertions(+), 674 deletions(-)

A further 322 lines of comments in violation of this remain. Issue 601 is to remove all commented out code which will fix that.

The code is slowly getting ready for others to get involved. Obviously if I'm going to be SUPER fussy about contributions, then my own stuff has to be perfect. Plus, with paint fumes, jack hammers, and chattery Spanish labourers outside the window, I couldn't think clearly anyway...

Fred.

[Fred]

Minor update: #599 is closed, all traces of fake rev and boost cuts from pre that feature being added are now gone. Added last remaining config from em_knaps, outside of his tables, which I'm in the process of trying to convert to C source soon. Which brings me onto today's piece of advice:

Floating point precision, literal precision, design decisions, etc:

http://megatunix.com/tracker/view.php?id=24

Firstly, 32 bit IEEE float data types, in any language, are ONLY good enough for display, in almost all cases. For output, you need to use double precision, at the least, and sometimes stuff like Java's BigDecimal class of artificial data type.

Secondly, if you lose precision, you can never get it back. Thus you should maintain as much as possible from the start. Don't go artificially rounding shit when you don't need to!!!

Thirdly, it would be better, in this case, to not go to a big and long literal decimal form, invert the operation and use the integer and adapt the system to allow that. Though it apparently already does.

So, be careful with your floating point values! And any math, actually. It's easy to make mistakes that are subtle like this and will bite you in the arse when you least expect it.

Fred.

[Fred]

Today I did quite a few things, but the only one that involved code was hacking on OLV. I added YAML definition reading to define the log structure! Epic success. I'll likely try to polish that off tomorrow and push a broken-for-FreeEMS OLV that requires an undefined file format. You can keep using the old version in the mean time. Perhaps I'll not push it to all repos straight away. Once documented this will pave the way for totally custom logs. All logs in future will be required to come with a matching descriptor. Without it OLV won't even try to read it. This means that .la logs will be viewable again, too. Preston would be excited... if he'd not gone awol. Exciting times.

In other news, as of tonight, EMStudio supports any/all size 3D tables. I'll be changing different builds to use different sizes soon. Default will grow to be BIG and impressive and high resolution.

Both of these changes will break MTX.

This is important because the values displayed in the real time vars stuff will be bogus/wrong AND the values you think you're tuning in the MTX UI won't be what the engine is actually using :-/

You've been warned. MTX will no longer be supported once those changes go in. Unless Dave magically adds code to support the interface that has been there all along... I hope he does. Then again, it doesn't matter much right now, because all modern linuxes ship with a version of glib that causes MTX to crash, consistently. Not Dave's fault, but not useful, either.

Fred.

[Fred]

More epic progress on OLV today. I'm steaming along with it. New features, issues ready to close. etc. Good times :-)

[Fred]

I spent two hours hacking on EMStudio tonight, and as a result, particularly of the second half of that two hours, it now works correctly with 3D tables of any size. Mike did the ground work for this, and I fixed a few details. Good team effort. It's nearly 6am now, though, but I couldn't sleep at 3 or so, so I did the productive thing instead. I have a firmware commit from earlier today waiting in the wings, too. I'll get that knocked out tomorrow evening post beach/wife/slacking Sunday.

Fred.

[Fred]

In other news, as of tonight, EMStudio supports any/all size 3D tables. I'll be changing different builds to use different sizes soon. Default will grow to be BIG and impressive and high resolution.

Both of these changes will break MTX.

This is important because <SNIP> the values you think you're tuning in the MTX UI won't be what the engine is actually using :-/

You've been warned. MTX will no longer be supported once those changes go in. Unless Dave magically adds code to support the interface that has been there all along... I hope he does.

That commit for big, and indeed, small, and indeed, old 16x16 tables is now in the dev branch. I'll move it to master once at least two people have verified it working correctly in EMStudio. All existing users except Sim and Peter will still be running 16x16 until they upgrade so tuning with MTX will still work on the same three tables. Default builds no longer work with MTX and look like this:




You've been warned!

More changes to come soon that will also break MTX unless Dave steps up and mans up and follows the project maintaining proper compatibility like he always should have. At the least he should error out if the table axis sizes don't match what he wants to display. That would be a small fix for him.

Fred.

[Fred]

Almost forgot! This is the new default table set, designed by Ben Fenner to my spec, tweaked by me, turned into code from spreadsheet by me:








Thank you very VERY much for your help, advice/experience/knowledge, and sounding board qualities, Ben! :-)

Lambda is good too, but not pretty yet, due to needing to configure display properties in the tuner.

Fred.

[Fred]

viewtopic.php?f=54&t=1819

All logging should now be done with EMStudio!

At least, if you want me to read it, it should!

Fred.

[Fred]

Today I learned a lot about Volkswagen TDI engines and their control strategy. It's dead simple. I have one of these. It has traction control. I hate traction control. I see FreeEMS on this vehicle in the future...

More torque, so much the gearbox can't take it, is available easily. Win-win.

Fred.