Fred's firmware development diary

[Fred]

I spent all weekend working on the code. I continued to massage the mathematics section and get a better idea of what is required. This went OK and I made significant progress there. I also continued to play with the paging and memory layout stuff. This didn't go quite as well. I'm still not sure why the code was returning all ones at this stage, but I do know that it means it's reading unwritten erased flash as that is the state it ends up in. The memory address referenced in the code matched the memory address in the memory map and also the s19 all three of which I checked carefully. I find this strange. Perhaps hcs12mem needs some work? Perhaps the SM is borked. Not sure.

Or, more likely, my build process is not the best. I've just extracted the entire imaged through the page window, and I think putting it back in through that method is far superior too. I'll have to redo and tidy up the linker scripts and memory definitions and then maybe, just maybe we can have some working code with full tables and lookups etc.

Excellent. Best I keep studying the other software stuff I need to know about in the mean time, but I think I have a game plan now.

Fred.

[Fred]

Extractions of the entire flash to disk show the following :

For version 0.0.12

Text1 :
linear = 0x390000 - 0x392C70
ppage = 0xE48000 - 0xE4AC70
48k = Not present! (good, as it shouldn't have been)

Text :
48k 0xC000 - 0xD9C0
linear 0x3FC000 - 0x3FD9C0
ppage 0xFF8000 - 0xFF99C0

Vector tables and serial monitor :
linear = 0x3FF710 - 0x3FFFFF
ppage = 0xFFB710 - 0xFFBFFF
48k = 0xF710 - 0xFFFF

Thing is, text1 wasn't populated in that version, SO, my guess is that the erase is not erasing all sections like it should, or only erasing the bits it needs to erase to write what it needs to write or something.

It was contrary to the literature I have found on the addressing schemes in the past... Hence it not working as my setup was done to those formulae and not checked on the real thing (no need to until now).

Based on this I should be able to produce a working paged binary next time I have a play around with it.

Fred.

[Fred]

I've verified that the flash is not being erased as it should be. I think there IS a bug in hcs12mem with regards erase. I'm not sure about writing to paged locations yet, but I think it will work properly now that I'll have it configured properly. Hopefully the author will respond to me otherwise I'll have to fix his tool myself I guess (Assuming I'm right about the erase thing). It is a great little tool other than that though :-)

Secondly a few thoughts crossed my mind over the weekend :

• ISRs MUST be stored in unpaged space which is a mere 32k. This should be fine as everything else can be paged in and out as required. ISR code should be short and small anyway.
• All data required by the ISRs should be available through near calls to local unpaged RAM or unpaged Flash. This will keep them fast.
• All required tuning data must be stored in RAM without paging to allow tuning in real time. We have a large block of ram that is pagable that could be used to store lots of data in a paged way with ease and allow tuning, but if we can fit it in the 12k without doing that, all the better!
• Each block of functional code should be stored in the same page as it's data to avoid unnecessary overheads during execution.

I thought there were some other things that came to me, but either there weren't or I've forgotten...

Fred.

[Fred]

Interesting data 101, AKA, the dream shattered <cries quietly> :

The calculations and table lookups etc don't even come close to keeping up with the ADC sampling :-( Factor of 10 or more slower than the sampling at 9k rpm and still only half finished or so. This could be improved upon a fair bit by doing various things at boot and using function pointer arrays etc. I won't bother until later when we see if it sucks or not. That 32 bit math REALLY is slow...

Interesting data 300 :

I managed to figure out the flash pages, and loading etc. So our new load limit is 48 of data and code before we have to resort to flash paging and fix hcs12mem or the serial monitor...

Which is good. It also means I can get some more testing and coding done on functional aspects and produce a new greatest ever release soonish.

currently sitting on 21k of binary, perhaps as much as 24k by release time at the worst I guess. Basically we have plenty of flash to do most reasonable things before having to fix hcs12mem up/figure out why it isn't happy with us.

Back to doing useful things...

Fred.

[Fred]

I got a few things sorted out in the code last night and I'm feeling a bit happier about it now, I need to give it a tidy up and polish and then put out 0.0.15 today, preferably this morning. Hopefully while tidying I don't decide to make major changes ;-)

Fred.

[Fred]

Interesting data 101, AKA, the dream shattered <cries quietly> :

I was wrong!!! I don't think I've ever been so happy to have been wrong :-) (well, maybe I have, but this is pretty good too)

I just measured the math runtimes at 307 * 0.8us at low rpm, 324 at no rpm, and as much as low 400's at 9000 rpm due to the increased total ISR time in amongst the calcs...

This is good I think. 0.3ms for the math is sweet, and means that even at full noise we WILL run it for every event!! even on a v12 :-)

Code: Select all

CoRT=00064, DeRT=00147, CaRT=00094, MtRT=00306, MsRT=00305

core vars, derived vars, calcs, total, and sum (to check each other) times in 0.8us ticks. Huston, this IS going to kick arse :-)

A full log line from the latest build is here :

Code: Select all

Logs=00033, Sec=00001, RPM=02655, IAT=29709, CHT=36004, TPS=33875, EGO=34097, BRV=14393, MAP=09766, AAP=09973, MAT=29436, CoRT=00064, DeRT=00172, CaRT=00091, MtRT=00329, MsRT=00327, ADCC=00247, TIOC=00000, TOTC=00247, Calcs=00034

And I have a file suitable for potential temporary parsing if anyone is interested.

Fred.

[Fred]

Statistics :

• 11kB of code
• 11kB of data
• 22kB of flash image
• 1100 Bytes of RAM used for vars
• 0.24 - 0.35 ms runtime for all calcs/math
• ? of stack used for running/code/etc (anyone know how to determine this figure?)

It's at the point where if you could guess the tune before booting it up and have it stored in flash before hand, it could run a Toyota! Probably not very well for a number of reasons, but it's really getting close to being a real EFI controller now which is kinda exciting for me anyway :-)

Various things are missing totally such as :
Fuel pump prime and safety turn off
Injector prime
Post start enrich
etc etc etc.

I think we should segregate all settings that remain constant for the life of the car from those things that change with tuning. All things that don't change for tuning should be only in flash. All things that need adjusting on the fly should be in ram too. Once we determine how much of that there is, we can either squish the main ram down to some smaller amount and place them in the rest of the 12k outside that, OR, shrink the main ram down to 8k and page the ram for the other parameters. I'd prefer the former as it is far less complex, but if we are getting greedy with table size and count etc etc then there may be no choice.

Fred.

[Fred]

0.0.15 is out now!

https://sourceforge.net/project/showfil ... _id=612637

Remember I said the change log for 0.0.14 was big? This is twice as big again :

0.0.15 (Avogadro) 10/7/08
Moved injector.c inc file into inc
Added main running variables struct
Added input handling code for all main vars
Renamed all clock counters clock instead of counter
Added counter for calcs routine
Added struct for counters
Added struct for clocks
Added struct for runtimes
Added flash .c and .h files
Added derived vars struct
Added lookup .c and .h files
Added VE tables and Advance tables
Reformated structs to use typedef statement
Added error codes define file
Added config defaults file
Split remaining settings out into structs.h file
Moved documentation about structs to structs file
Removed contents of initConfiguration()
Moved tuning tables and lookup tables and configuration to the other primary flash block.
Added table lookup routine for X by Y unsigned short main tables
Changed main table structure to be more suitable for variable sizing
Added config checker that outputs a count of misconfigurations
Added send function for string without length relying on null byte to terminate
Added send function for block of data from memory with address and length
Fixed the ignition out pins in the pin out doc
Added the hardware flow control pin to PE7 in the pin out doc
Added full length equation with divisors and scaling
Sorted out the memory management up to 48k
Setup the paged macros for data and functions
Moved some vars to globals calculated at boot time to save loop time
Moved user string to config block
Added 16x2xunsigned short table struct
Added MAF input to the pin out doc
Added MAF transfer lookup table
Added correct and physics based mathematics code and calcs
Relocated rodata into text for loading convenience
Added text2 region temporarily (page window)
Added dependency on makefile and linker stuff to make file
Added relocation of flash block lma addresses to make file
Added realistic data to the MAF lookup table
Added a couple of basic hard coded scripts for memory analysis
Added dumps of each object file
Refactored IO banking system and documented it
Changed timer extension use code to use union for performance
Split core vars generation out into own function
Split derived vars generation out into own function
Added some structure for corrections to PW
Swapped order of CRLF pair to be correct in HR log function
Rearranged main.c code for better effect
Slowed logging down to 10x per second
Increased verbosity of log
Added reset rpm to zero if non synchronously sampling ADCs
Split Lambda table out from VETables.c so it can be arranged in memory more conveniently
Split config into tunable and fixed
Moved many literals to #defines
Fixed "out by 100" error on load indices in tables
Moved rough RPM calc to per event rather than per rev and inited cycleTime to longmax
Reincluded the broken ignition code
General tidy up of all files



As I said earlier, this is enough to run a Toyota or Mazda F2T badly right now IF you could guess the tune before trying.

Enjoy!

Fred.

[Fred]

I just did some experimentation with the serial transmit speed, and isn't it just horribly slow :-(

Google calc bytes per second

I'm getting 80kbps from 115.2kbps transmit speed, so that's not too bad, but the processing of the numbers into text etc is slowing it down a bit. The busy wait thing is hurting everything else in the process. To transmit 512 bytes/chars of log (current log size) down the line it's taking 50000us or 50ms which is UBER slow compared with everything else. Moving it to the serial interrupt will probably be a good thing for everything. Something like 10 executions per milli second or one every 100 us means plenty of time left to do all sorts of other things if the routine is kept short (which it will be easily).

This really illustrates a point though. We should focus on the communications and basic transfer of data over serial and do higher speed logging some other way with a higher data rate and hopefully some sort of buffer (yet to look into that yet). Maybe CAN or SPI or IIC something?

It also kinda says "switch to binary NOW" because for every number, char, short, or long we send, it's 3 times slower to get across the line, for each one of those, you need a label to ID it amongst the data and a gap to make it readable = one char becomes 8 x slower than just sending it raw with a pre defined order, and a short is 5x slower, and a long is 3.5 x slower.

So, in saying that, if my time is not to be wasted on developing throw away serial code for some arbitrary data format, the thing to do is invest more time in the serial protocol now until we wrap it up then code that, then use it to get data in and out efficiently.

Lastly, it says to me that whichever mode of transmission and logging we use, XGATE should be doing it 100%. That is something to work on much later though. The protocol design does not depend on the CPU variant sending the data...

Fred.

[Fred]

I would like to announce a small break through :

I just compiled the first version of the firmware with assembly in it! I can't take credit for the code, and it does nothing extra at the moment, but it was kinda cool to do :-)

That's all, hopefully our resident ASM code guru will provide us with some flash burning loving in the near future :-)

Fred.