map repo

[Fred]

Jean, I can't remember in enough detail to say "Yes, and here is why: XXXX" but I recall discussing this with Sean while he was developping it and that was the (possibly wrong) conclusion that we came to.

Quote : "The sand dunes, they will guide you!"

[jbelanger]

It is true of smaller 9S12 chips which have only one flash block but I think this isn't the case here. While I haven't gone through the specs in details, I did see that there was an interrupt available for when the flash operations are done. It would be surprising to have that and not be able to continue with the normal code when doing the flash erase/program operations.

So I do think you need to revisit this. Not having the stumble would be a nice side effect.

Jean

[EssEss]

So I do think you need to revisit this. Not having the stumble would be a nice side effect.

+1

and +1 on JSON, great choice.

[Fred]

So I do think you need to revisit this. Not having the stumble would be a nice side effect.

Hmmm, I'll revisit it for sure, but if the memory arrangement for anti-stumble = can't arrange memory in a way that makes sense for functionality, then it can remain, reality is that it does not matter at all. I was never botherd by it, it's just something that happens, a side effect of the functioning of the device.

and +1 on JSON, great choice.

I thought that until I discovered how unstable the spec is, now I'm torn between what I thought JSON was and XML with what JSON really is scratching at me like an annoying dog.

Fred.

[jbelanger]

So I do think you need to revisit this. Not having the stumble would be a nice side effect.

Hmmm, I'll revisit it for sure, but if the memory arrangement for anti-stumble = can't arrange memory in a way that makes sense for functionality, then it can remain, reality is that it does not matter at all. I was never botherd by it, it's just something that happens, a side effect of the functioning of the device.

Of course, functionality is the only priority. But if it works as I think it does, it would only be a question of putting code in one blcok and data in another. Of course that also means the code needs to always work with a RAM copy but that should be the case for most of what you have already.

Jean

[Fred]

I'd have to check to be sure, but I believe I have all the data in one block and code in another already. And yes, it works from RAM already for most stuff, but perhaps some of the things it needs to read are stored in the affected block? I'll think about it. It's a mild intermittent stumble right now without the concept of sync, but once sync is lost/refound it will be a more harsh stumble for sure. Then I may care more, but I still don't see WHY anyone cares *at all* - care to explain that? :-/

[jbelanger]

The stumble is not my concern. Stopping the code while the engine is running is what I don't like. If it can be avoided it's better and you don't have to deal with burning data as a major exception. Why would you accept losing all functionality while performing one action unless you have to?

Jean

[EssEss]

but I still don't see WHY anyone cares *at all* - care to explain that? :-/

'pausing' code during a flash write just brings up all kinds of bad things where the state you entered before the burn is simply not the same as after the burn. To compound that, I think the burn time is not deterministic (.. will check the datasheet now). I got around that problem in my project by hanging an spi eeprom (fram) off the controller and making sure that the ram/fram is always in sync when writing/tweaking maps from the tuner app. I think you could also get around this by executing from ram(if you have room) and not flash.

[BenFenner]

I still don't see WHY anyone cares *at all* - care to explain that? :-/

It's bad form. Fly in the ointment sort of thing. Maybe something for the iFreeEMS crowd to suss out. =(

[Fred]

I disagree, the state of the engine typically barely changed and once it re-syncs it will have fresh data to calc from and work properly straight off the bat. I will say one thing, no exceptional code will be added to handle burns, other than the burning code itself. The code should robustly handle sync loss etc anyway.

To me it's just like pulling the fuse from the controller for a second and the engine might lose a few rpm in the process and/or stall if it's idling and out of gear. In my truck with MS I just brought RPM up to 2k or so in neutral before burning. Again, and my tuner today agrees, it's nice to get a physical confirmation that what you did worked. I realise it won't be required once acks are provided in a consistent manner by the firmware and Aaron/whowever uses them, but it's still a nice thing IMO.

Anyway, if we can "fix" it, sure, no worries, but the code will not be changed to "handle" this state in any special non-default way, this is for sure :-)

Fred.