Fred's firmware development diary comments thread

[jharvey]

.odt is just OpenOffice... Which is free for Windows, Linux or Mac.

For some reason my linux box want's to use SQL for something, and doesn't work. I installed it with yum install openoffice, so I don't know why it doesn't play nice. Haven't had time to figure it out yet, I'm sure the solution really is simply, just a time constraint issue. My windows machine is commonly use to telle commute, so I have to keep MS office in prime shape, as well as I'm running out of HDD room on my MS machine. So I simply can't install it there.

[jharvey]

I really like the freemind doc. It does a good job of showing where different parts of code are intended to reside and how they are expected to connect to other parts of code.

I've made a PDF version of it and attached it to this post.

[Fred]

I'd better update that to reflect the serial changes in the near term :-)

Fred.

[sry_not4sale]

A FreeEMS developers life

Yeah, except you don't sleep

[Fred]

I do too! I've had a bunch of earlyish nights recently. In fact, I'm hitting the sack before 12am again tonight! :-)

Fred.

[jharvey]

I've been reading up (when I can) on the firmware. One thing I'm wondering about, but haven't figured out yet is a memory layout. I'm wondering where main.c, enginePositionISRs.c, and such functions map too once compiled. I'm also wondering how the stack is handled.

Most of my experience with the stack has been that it resides at the end of the PC code section, and fights back-wards against the running code. If the stack gets too big it clobbers into the running code. However, this processor supports separate paged memory right? So I'd bet the stack is located outside of the running code section(s). Is that right? I also see the memory map is one list, so perhaps it's all the same thing with out paging....

What I'm most wondering about, is that enginePositionISRs.c location. To me it feels like most sections are fairly standard in how input gets in and out. The one section that I think might benefit from not having a one code fits all solution, is the RPM input code. There seems to be several tooth variants that require very different techniques to process. Some use one wheel with a massive amount of teeth, others use two separate wheels, some simply show TDC and let you guess the rest. These really require different algo's optimised for each different task. Then once the RPM input data is collected and processed, the output(s) from that code are quite standard in how the rest of the EMS receives it's RPM data. To me it feels like we may want to make this part of the code kind of modular, such that you upload a different section of firmware based on your hardware layout. So lets say the code resides between 0x4000 and 0x8000, but typical compiled size is 0x2000 and the enginePositionISRs is 0x0100 long. If we specify the memory slot for enginePositionISRs (during the function construct I think) to be 0x7000 such that the it resided between 0x7000 and 0x7100, we could upload to just that section with out having to do a full blown upload or compiling of the full firmware. Every time the ISR is called, it would be located at the same starting point.

I think this technique would be handy for keeping code out of the firmware unless you actually need or use it, keeping space available, as well as it would allow people to write specific RPM processing code with out needing to compile the entire firmware.

I suspect the memory layout is left up to the compiler, is that right? Such that each time enginePositionISRs is located where ever the compiler felt it should go.

[Fred]

If not specced an item is placed in 'text' by default.

see :

memory.x
memory.h
makefile (objcopy)
linker script

the next version has a more sophisticated setup and a long document describing it all which I will update this morning based on your comments just now.

firstly, the code is all running straight from flash, not from ram. flash is full speed.
stack fights backwards towards the global variables and clobbers those if it gets HUGE.

Your idea for the input capture ISRs is valid and I have thought about it. It's cool that you've thought it up too though :-)

There are a number of techniques for achieving that...

I'm not sure which to take, but here they are :

• your idea of copying in chunks of code via the tuning app.
• having many versions compiled in and reburning the vector table to point to different ones.
• having many versions and branching to them based on config
• building the code for a specific input arch from source each time

i've been favouring the latter one for a large number of reasons, but I'm not ruling out your approach at all and it is a good one.

Attached is a pdf just for you, first draft, not including this mornings changes that I haven't made.

Fred.

[jharvey]

I tend to go for the block firmware upload approach, not because of the current limitations, but because of round 2. Right now I see only one block that would be nice to reprogram, but when we start adding other stuff like IAC we now have stepper and analog systems, ect. So other blocks will likely show up.

The problem is that we now have say three firmware's for each build, with round 2 and IAC we have 6 firmwares, and if we have another block, we would go to 12. The number of firmwares grows quickly.

However, I see some potential problems with the block idea, you also have to make sure your IRQ's and such are doing the right thing. So it might not be as easy as just just uploading the block. Also right now it's only 3 firmwares, so it's not a big deal. Probably best to focus on making it go, then round 2 could include the blocking or what ever approach is best.

Keep up the good work.

[Fred]

Doing that for anything more than the wheel decoding is a very bad idea. It would increase complexity through the roof. Most of that stuff can live in paged flash and therefore we have STACKS of space left for it. Not a problem at all really. ISRs are different in that the hardware makes the call asyncronously and therefore it must be fixed. actually, linking and building 15, 30, 50 firmwares that are identical except the wheel stuff would be pretty easy and not take excessive space either.

Loading it with a tuning tool introduces possibilities of bugs that would otherwise not be there (incompatible code versions and global var locations etc etc etc).

I'm still thinking multi build is the best approach. I can't see a draw back to it actually.

Fred.

[Fred]

Memory doc updated. Bottom of second to last page has changes, rest is the same.