map repo

[SleepyKeys]

With a com protocol like MS yes it's sure nice to have the physical confirmation. With FreeEMS it's a bit redundant. When I wrote the flash burn code, I was in a bit of a hurry so I didnt deviate from the FreeScale docs too much. If I remember correctly besides the size the "flash module" itself is the same as the one they use in the C64(MSII). This has been suggested to the MS crew many times which leads me to belive it may not be a good idea or not possobile.

Proper code should be able to resync and start giving proper fuel and spark at any rpm.

[jbelanger]

Proper code should be able to re-sync but that doesn't mean you want to generate a need for it if you don't have to. That seems very sloppy to me to do otherwise unless you have a good reason for it.

The C64 only has one flash block so they don't have a choice. I think MS3 doesn't have the stumble but I'm not sure and I don't know how it was done. Not wanting to have a big exception is reasonable (like having to run in RAM for the burn duration which is not possible anyway) but having a flash burn in the background and continuing to run with the RAM data should be the preferred solution. And that could open other interesting possibilities such as special event data logging where you save some data triggered on some unexpected events.

Again, I might be wrong with my assumption but I just wanted to point out that it should be checked. And to give my opinion on what the proper behaviour should be. But I'm not the one who's going to program it so you'll do whatever you want with it

Jean

[SleepyKeys]

I agree it is sloppy, but not a problem for the reasons stated besides being sloppy. Just saying not sure if it can be done with the XDP, XEP yes.

[tpsretard]

i also agree it is sloppy.
do it right the first time out...

Also the stuble/re sync in MS3 is gone..

[SleepyKeys]

MS3 is XEP.

[Fred]

I don't even see it as sloppy - it is a hardware limitation, primarily. If I have to jump through hoops to make it go away, no, it won't happen. If it makes sense to make it go away then yes, it will happen. I don't think it's possible or practical or worthwhile to persue though, there are NO side effects when you are driving the car, ONLY during tuning - a presumably short period of an EMS ownership period. If it's not too much effort, is possible, and doesn't influence the other aspects of the design negatively, then sure, otherwise consider it a design decision, not sloppiness.

Fred.

[jbelanger]

It is only a hardware limitation if you can't run from a flash block while another one is being erased/programmed. If it is possible to run from a flash block while erasing/programming another one, then it is a sloppy software architecture/design.

You don't have a wait loop when you're reading an ADC, why would you do that for flash programming? A bit extreme for a comparison but still a similar idea.

Jean

[sry_not4sale]

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.

What was the issue with the JSON spec again?

[EssEss]

I spent some time over the last day working w/JSON - it's so simple how can major changes to the spec even effect anything ? I tried to find anything I could on how the spec is unstable, but all of my googling came up with nothing. The entire spec fits on a webpage complete w/diagrams .. In the implementations I browsed through there is a small token based parser. You don't get all the fancy parsers that come along w/xml based stuff, but in this case I see it as a plus.

[Fred]

If it is possible to run from a flash block while erasing/programming another one, then it is a sloppy software architecture/design.

Disagreed. Do not forget that there are many other reasons to distribute data into different flash blocks too. If it makes sense for other functional reasons to divide things up in a way that causes burn stumble then chances are I will have burn stumble rather than skew the design in significant ways to prevent something that at the end of the day simply does not matter.

You don't have a wait loop when you're reading an ADC, why would you do that for flash programming? A bit extreme for a comparison but still a similar idea.

Sure, understood, but that does not mean that while designing the structure of the software you are sloppy if you choose to have that happen rather than N other compromises that you may have to make to achieve not doing that.

Anyway, we WILL look into it, but I really don't think it's intelligent to compromise functional design for that unimportant inconsequential niggle.

Fred.