Fred's firmware development diary

[Fred]

I've been creating test packets to feed to it to get certain behaviour and the escaping works on send from ems to pc, but not in reverse for some reason. You can force it to escape a byte thats not escaped in the original by ensure your checksum and your contents together add to a special byte which means the checksum on the return journey needs escaping. That works.

Time to figure out the receive thing...

Fred.

[Fred]

I haven't found the issue yet. I've sent the latest code to Aaron and Sean to play with and to my German friend known as Mr K too. Perhaps one of them will see something I'm missing.

It's one of those "you know its right under your nose, but can't see it" bugs...

when serially receiving a packet with an escape char in it it never
receives the packet properly.

I've put in debug for bad checksum, for the part where it stores it,
and for the various reset conditions, no joy.

it definitely gets the byte in the unescaped format and it definitely
never finishes as the checksum never fails or succeeds. It's like its
missing the stop byte, BUT, i checked the overrun error too...

Hopefully one of those guys will see it.

Fred.

[Fred]

Solved!

"I know a mouse, but he hasn't got a house, I don't know why I call him Gerald, but he's a good mouse" - Syd

~ != !

woops

EVERYTHING WORKS :-)

Fred.

[Fred]

It's 2am, I've sent a prelim to Sean and Aaron for various reasons. I'm going to do the dishes, have a snack and hit the sack!

I may release 0.0.17 tomorrow night as I've completed most of what I wanted to before releasing.

Next up, PIN OUT :-)

Dave/Jared, one of you add a task in the tracker for the pin out update :-)

Hit Aaron up for a hardware label/section or something so we can track hardware issues there too. I was losing track of my lists in Jareds big thread...

Fred.

[Fred]

I got some good work done on the train tonight, but I'm too tired now to make solid progress so it will have to wait a bit more. Tomorrow on the train I can make further progress on it hopefully.

I have most of a serial packet handler in place. I need to figure out the best way to build the replies up and get on with it :-)

Currently it is listening for request to reset and for request to wrap and return. I'll add more basic stuff soon.

Fred.

[Fred]

I forgot my caffeine shot on the train yesterday morning and ended up unable to think/code and then fell asleep... woke up in london feeling like arse. Not good.

The trip home was productive though :-)

I can't see any reason why I can't release a fully functional serial implementation and some near-final documents describing them today.

Right now I'm just tidying the headers and sussing out length information handling stuff.

By the time I release I should have the following working :

• Full header decoding and creation
• Full error checking
• Interface version request/response
• Firmware version request/response
• Max packet size request/response
• Echo packet return request/response
• System reset request/action
• Async error packets
• Async debug packets

If I get carried away with it I may get it returning blocks of data from flash and ram and adjusting data in RAM aswell. I think I'll leave Sean to confirm that flash burning works and test it out when he says it works 100% :-)

Wish me luck, perhaps that is too long a list, but it doesn't look too difficult to achieve provided there are no funny bugs popping up!

Fred.

[Fred]

Some stats :

RAM :
0x1000 - 0x2000 = 4k = page window
0x2000 - 0x2820 = 2k = serial buffers
0x2820 - 0x2CA3 = 1k = used non page vars
0x2CA3 - 0x4000 = 5k = free ram/stack space

I should probably double the serial buffers to allow the thermistor tables to be processed in one packet.

Flash :
0x4000 - 0x6000 = 8k = switchable small tables/configs
0x6000 - 0x6800 = 2k = fixed non switchable configs
0x6800 - 0x7000 = 2k = IAT table
0x7000 - 0x7800 = 2k = CHT table
0x7800 - 0x8000 = 2k = MAF table
0x8000 - 0xC000 = 16k = main tables (ve, advance, fuel timing, lambda)
0xC000 - 0xEF0C = 11.75k = code and constants
0xEF0C - 0xEF10 = SFA = init section/bss
0xEF0C - 0xF710 = 2k = free unpaged flash space
0xF710 - 0xF800 = 0.25k = vector table
0xF800 - 0xFFFF = 2k = serial monitor

If we run out of code space in the short term I'll drop the MAF table temporarily to allow continued development.

In summary, we have plenty of ram, and plenty of paged flash, and enough unpaged flash for 16 - 33% code growth.

This means there should be plenty of time for Sean to write us a loader firmware to access the balance of the flash that either the monitor or hcs12mem can't access.

Fred.

[Fred]

When I said "I can't see any reason ... today" I had totally forgotten about going out to dinner tonight... which means that I may not, but I WILL get it out tomorrow as its VERY close to being ready to go out :-)

I had to do some refactoring to make things "right" today so I didn't complete what I thought I would in the time I thought I would.

I'll set the alarm tonight and get up early to work on it in the morning.

I MUST do my GST return this weekend too. And I promised some research on the infamous pin outs...

Currently I think I could manage all of those things, but we'll see. Number one priority is to get the serial stuff out for Aaron and Marcus and Shameem and others to read and digest and develop against. First equal is the GST report. That is closely followed by the IR886 and pin outs with the income tax return a distant third.

Cleaning the lounge may also be forced upon me by the good woman... I admit walking across the lounge would be nice... ;-)

Right, shower shave sh** ;-)

Fred.

[Fred]

Well, I didn't break the receive ISR code, but the packet stuff isn't quite right yet. It makes it as far as the main loop to be processed then something goes hay wire and it never sees the block of code to action the event. There are a number of reasons this could happen so I'll add an LED for each one and we'll see what is going on :-)

Once the basics are ironed out it should be plain sailing. The next thing I implement is definitely going to be error codes and/or debug packets as it would aid with this quite a lot!

Fred.

[Fred]

By the time I release I should have the following working :

• Full header decoding and creation
• Full error checking
• Interface version request/response
• Firmware version request/response
• Max packet size request/response
• Echo packet return request/response
• System reset request/action
• Async error packets
• Async debug packets

Well, I have all but the two async types done :-)

No testing just yet, but I'm confident that they will work fine.

Interface and reset are tested though. I need to draw up a matrix of possible combos of options so we can thoroughly test all the options, perhaps in some automated way with a tool in future.

Tomorrow I'll be doing some chores and then doing those async ones and testing it a bit.

It's cool to be able to reset the thing remotely btw. Saves me reaching for the button ;-) Doesn't work for changing to the monitor code, but perhaps I can add an option for that too? I just have to find out where it is in memory and call that location as a function. May try that tomorrow too.

Looks like we are on target for 0.0.17 out tomorrow some time, though the docs to match the code could take a bit of time. So perhaps late tomorrow then.

Fred.