Flash Burning - what do we need to do?

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Flash Burning - what do we need to do?

Post by sry_not4sale »

My 2c:

Trying to write out a generalized abstraction layer for burning to flash I would imagine would involve all sorts of performance penalties in the cpu, so in order to write the code for burning wouldn't we need to flesh out exactly what data needs to be stored? So we can build a structure, and then code/interface around it?

Or am I on the complete wrong track?
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Flash Burning - what do we need to do?

Post by Fred »

Hey Aaron, good to see you back online again :-) I thought you had gone bush or something ;-)

This is exactly what is needed. Clearly I wasn't clear enough :-)

Regardless of the structure present, you will have a block of data of arbitrary size and somewhere in the middle of it is a single 16 bit value that is changed in the ram mirror image. You have to erase 1024 bytes at a time, not 2, so you lose a bunch of stuff that you otherwise wanted. So, you have to copy all 1024 bytes down from ram to flash at that point. Except, you might have two 16 bit values that are changed in ram and only want to burn one down to flash. So, what do you do? Take a copy of the flash to ram before erasing and write it back down part from the mirror image and part from the flash copy? what if there isn't space to do that? etc.

That's what I am getting at. I hope that clears it up, keep posting! :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Flash Burning - what do we need to do?

Post by sry_not4sale »

Settled into job so have spare time again lol

Is reading 1024 bytes from flash quick?

So we want to try group related data into 1024byte chunks? Is there enough flash memory to be able to waste some?
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Flash Burning - what do we need to do?

Post by Fred »

sry_not4sale wrote:Is reading 1024 bytes from flash quick?
Yes it is, full speed. Our code runs from there you see. An aligned word read takes one bus cycle.
So we want to try group related data into 1024byte chunks? Is there enough flash memory to be able to waste some?
Flash, probably, but ram, probably not. The flash needs to be kept compact such that it can be directly copied up into ram as a big block at startup. Runtime changes will be made to the ram copy and burned from there down to the flash when commanded.

Grouping things will help, and it might be that we just have to save all things on the same 1k sector at the same time. Mostly this will be reasonable as you rarely want to lose your changes anyway. However, if you have 512 16 bit vars, they simply will not be related :-) so it won't be that much use.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Flash Burning - what do we need to do?

Post by sry_not4sale »

So this takes us back to, what actually needs to be saved into flash via the CPU?

Do all flash updates have to go through your code? Or does the PC connected have direct access to this?

Only code, configuration and the tables are really stored in flash correct?
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Flash Burning - what do we need to do?

Post by Fred »

sry_not4sale wrote:So this takes us back to, what actually needs to be saved into flash via the CPU?
Only config, variables, settings, and tuning tables etc.
Do all flash updates have to go through your code? Or does the PC connected have direct access to this?
Using the PC you can write the whole firmware file in at once, or even some part of it (I could build a project for loading only the config if it's useful), but only when my code isn't running.
Only code, configuration and the tables are really stored in flash correct?
That is correct, yes.

We will probably squeeze each table into a 1k sector for convenience and the config in a few sectors or a larger block of 2 or 3 or 4 sectors. We have 12k of ram, and we need all our running vars and some code, the stack, and all the tuning data loaded there at the same time. I hadn't thought about it much till now though. Additionally, there is actually 32k of ram, with 8k fixed and a 4k window, so we COULD use some of that if things got tight and swap the window around to manually address it where required.

How the balance of the data looks I have no idea. I do know that I have 250 x 2 bytes of data already, maybe half tuning, half vars. We also have 2 2k tables for CHT and IAT on board and may end up with another one for MAF if we try to support that. Those won't live in ram though as they are change all at once type values.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Flash Burning - what do we need to do?

Post by sry_not4sale »

ok.

Can we get a spec for the structure of data in flash then? I would do it but I have nooo idea about what we need to save for tables. :)
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Flash Burning - what do we need to do?

Post by Fred »

It's currently unstructured, and it's growing and changing daily. I was just hoping for a general discussion about gotchas etc with regards these issues.

Here is a poll that everyone should be voting on :

http://www.diyefi.org/forum/viewtopic.php?f=8&t=283

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Flash Burning - what do we need to do?

Post by Fred »

Bump for a public update from the main man Sean?
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Delta
LQFP112 - Up with the play
Posts: 111
Joined: Fri Jul 25, 2008 8:04 pm
Location: Perth, WA, Australia

Re: Flash Burning - what do we need to do?

Post by Delta »

I probably should have read the whole thread before posting - but my laptop battery is almost flat.

Most live tuned EMS's interrogate the serial port for the current values required. These values are then put into memory (if the value does not come from the serial port then the internal memory values are used, normally you can then tell it to flash the tune, which sends the whole tune to the cpu which writes it to flash. This generally results in several stumbles as the cpu is writing to flash. Since i believe we're going to have a permanent connection to battery with FreeEMS?? I'm assuming you could have a question when the key is turned off sent via serial to ask if the tune should be flashed....thus the car isn't running and hence no stumbles.
Post Reply