Fred's firmware development diary

[Fred]

I forgot to mention that :

1. The hardware docs are updated, BUT, not complete, and therefore useless.
2. The serial interface docs are updated, BUT, not up to date, or complete and therefore useless.

Flash works, though.

Much to do :-)

Fred.

[Fred]

I have finally been converted.

I will soon be that annoying kid preaching like some sort of religious nut case that Git is the ONLY way forward. Indeed, I've barely used it and I'm already thinking this way for my own use anyway.

The eclipse plugin needs work (maybe I could help a bit?) but that doesn't matter too much really.

What is important is that now any of you can branch the code quickly and easily. You can either just steal a branch by cloning the clone url, OR, what you SHOULD do is setup an account on github and fork it there. You can keep your copy at home upto date with mine and push your merged changes up to the site where i can see them and pull them back in.

This goes for everyone even the most disinterested hackers. If your changes are public as mine will be from now on, your stuff has every chance of making it in. You are now free to hack away at anything and everything. Worst case is I don't like your work and won't pull it. Best case is you sign up on mantis and organise your efforts with myself and Sean and we avoid double up and working on dead code etc.

Sign up on this site : http://github.com/

Then fork the firmware by going here : http://github.com/fredcooke/freeems-vanilla/tree/master

I'll do a bit of a guide soon I guess.

As for today... I played around on the train and fixed a build issue... caused by Git. Git doesn't persist directories that are empty... and my makefile didn't handle that... now it does. Commited and available right now :-)

I've got a serial thread to produce tonight and a few other things to do, hopefully I can get some real work done on the code or docs again tomorrow.

Fred.

[Fred]

Oh, and did I mention how nice it is NOT having .svn directories every-bloody-where? Very nice! :-) Especially when grepping for key words etc.

Fred.

[Fred]

This morning and this evening I implemented buffered burning. What this means is that the tuning author does not have to think about what stuff to send to the device other than the bit they want burned. This functions for burns down from RAM too.

For example, if you have changed the idle table and the warm up table and you aren't happy with the idle, but want to save/persist the warm up table without saving the idle table you now can with ease.

Mint, another notch in the belt ;-)

Just need to test it... which should be possible fairly easily actually. I'll do that some time tomorrow while everyone else is drinking and being merry :-)

Before I test it though, I need to figure out how to push/pull my changes from one laptop to the other. Hmmmm, no idea, google time.

Fred.

[Fred]

The current buffered burn code in the git repo is broken. Just a FYI for anyone wanting to play with it. I'll be fixing that in the morning and tidying up some hacks that I included for testing.

Fred.

[Fred]

The read works now, but write only erases the block...

I need to make it copy whatever is directed straight to flash up to ram as well also.

Fred.

[Fred]

Just an FYI for potential serial hackers, if you are having issues with your code, it is possible to write to the tx buffer and increment the pointer from inside whatever function you have called. In this way you can see what values were being used for various things. You need to #include commsCore.h and just do what is done all through commsCore.c. At the end of the case statement for your payloadID type you can just call checksum and send.

I just go this packet back using that technique :

Code: Select all

00000000: aa aa 00 00 03 6c a0 a0   00 00 00 a0 00 a0 40 2f 
00000010: cc 

Code: Select all

6c a0   a0 00   00 00   a0 00   a0 40

Code: Select all

0x6CA0
0xA000
0x0000
0xA000
0xA040

Code: Select all

0x6CA0 - buffer address
0xA000 - chunk flash address
0x0000 - offset from start of sector
0xA000 - FlashAddress
0xA040 - chunkFlashEndAddress

Clearly the error is that the buffer address isn't in ram at all and is in fact in the middle of a block of unused flash. Hence it is actually writing the buffer to flash... with FFFF and the memcpy calls just silently fail to write to flash...

This shouldn't take long to fix at all now that I've debuged it like this.

Hooray for serial!

Fred.

[Fred]

Well, as predicted, that was easy to solve. I've since realised that the functions I was using were previously untested. I've realised this because there are more issues with them. I'm not sure why yet, but the obvious thing to do is to improve the error packets and enable them to have a payload of some sort. Or perhaps I'll just add in some temp/custom debugging in the mean time. I'm not sure, but I want to push a fix before tonight as I don't know when I'll get the next chance and the repo is currently a little broken...

Fred.

[Fred]

The issue was just that my hand made test packets were wrongly formatted etc...

So, test packets are fixed, code is fixed, and it's all available right now if you are interested :-)

Nothing that special, but it's kinda cool that these posts are live with the code they talk about now.

Esp with the fact that it's dead simple for your changes to be just as live back to me!!

I look forward to pulling some changes from someone soon :-)

Fred.

[Fred]

I've been away on holiday on englands south coast for a few days, but still working hard amongst other things. I'll be back tomorrow evening and hopefully can make some commits on the way home and push when I get there.

Sean has some first hand commits against the code too now, see this link for a look at how he is (seemingly) ahead of me :

http://github.com/fredcooke/freeems-vanilla/network

Hopefully a few people who are interested in contributing grab a copy and show us what they have soon :-)

Abe? Gearhead? ETC?

The work I've been doing is on documenting the source. I'm adding structured history of changes and stuff and separate pages for various items. I'm converting all the function comments into doxy style ones and generally tidying things up and rearranging headers etc in the process.

Hopefully with these new additions the source should be incredibly easy to grok when viewed via Doxygens efforts.

Full credit to Jared for starting the ball rolling on that front!! :-)

Fred.