Fred's firmware development diary

[Fred]

Well, it's been quite a long time since I knocked out a release. The plan for the next release has fallen through so I've got a new plan :

Implement serial send and receive in binary with packets.
Implement comms app to handle this and display state.
Implement a copy of data in RAM loaded there at boot from flash.
Implement RAM tunability - this will be lost on reset, BUT I realised tonight that if I tune and tune and tune and get it good and implement a way of saving that tune to disk and reloading it, we can use the system in testing mode without flash writing functionality.
Implement savable and loadable tunes in a basic way.

And what ever I run across in the process too, of course.

Look for that in about 1 week or so.

Fred.

[Fred]

I got a few hours in on this today. making duplicate vars etc so that there can be flash and ram copies etc etc.

Also put some work into the serial stuff in the firmware.

And finally some JEMS JMS experimentation too.

Tomorrow I *may* get some time to do some more work on this stuff as I have no passwords and logins on the systems at work just yet. At the very least another 2 hours coding on the train will get done.

I'll try to get out a release with or without the stuff I want to put in it by the weekend. It may even be non fucntional, but it will have the latest code and the point is to get it out there for others to read and digest and hack and criticise heavily.

In a while when I'm happy with it I'll be putting up a thread asking for a code review by suitably talented and interested parties. Don't bother just yet as there is quite a lot left to do before I'm happy with what is there...

Fred.

[Fred]

Drum roll please....

I got some good dev done on the train tonight!

Figured out how to create unions of the main tables for populating ram and also create separate ram regions for various items. I won't release before the weekend because I want to confirm my changes on the hardware (duh!) and make further changes too.

It should be running out of ram instead of flash by the next release with a bit of luck.

Perhaps we can even get some uber basic serial send AND receive happening and use Seans burn code to tune and burn down the changes :-)

It will really start to come together fast once that stuff is in and functioning :-)

Fred.

[Fred]

Tonight I experimented with memcpy and found that the compiler is clevererer than I thought it would be. If called with length 1 it uses a single movb asm line, for length 2 it uses a single movw asm line, for more it calls memcpy from the library :-)

I also placed the unions in the page window and added memcpy calls to bring flash up to ram and some vars to hold RPAGE values etc etc etc.

I examined the memory maps to ensure things were doing as I wanted. I hope when I try it on the hardware it works first time :-) Probably not, but you never know.

I'm always weary of changing a lot without hardware testing as if it's badly broken it can be a pain to figure out which change broke it.

Anyway, we'll find out on saturday morning!

Fred.

[Fred]

More memory stuff done and more to do tomorrow too. It's 2am and it's time for bed. I'm knackered! Alarm at 5:30, yay...

Fred.

[Fred]

More memory and settings stuff done tonight, lots more to do. I'll need to draw a line somewhere and make a release in poor condition. Then I can get truly stuck into making it really really good :-)

Fred.

[Fred]

This morning I got the config into blocks and created flash memory areas that the linker populates. The reason I bothered doing this was A to align the data, and B to ensure if someone screws up and makes the struct too big, a linker error is thrown.

More to come over the weekend :-)

Fred.

[Fred]

Tonight on the train I started implementing the paged table and array retrieve functions. Nearly midnight and one glass of wine with no dinner at the time.

As a bonus, I also got to drive home. I've been wanting to have a stab at breaking the speed limit across some local roundabouts for a while and I think I came close tonight, but there was more to have without headphones in and more awake.

Tomorrow I'll actually fire it up and make sure it still works. Then I'll try to read the data from ram instead of flash and make sure that works. Then I'll try to get some really basic serial two way happening to write to the ram and see if that works too. Then I'll spend sunday tidying it all up and releasing it.

So, comms next I guess. We really need some good comms now so that tuning guys can get started writing an interface for it.

I've got a fairly detailed design for really good two way comms on a single serial line drawn up based on Stus work, but I think it should be more generic so that the same code (written ONCE) works for CAN comms too. I definitely need to think more about that. Perhaps I'll write up a thread on how I was going to do two way and what we need to figure out to do multi way comms for CAN etc.

Feel free to bang any comms thoughts into that thread that badly needs a bump.

Fred.

[Fred]

I just loaded up some firmware for the first time in a month and it is running, but not receiving interrupts or anything and just outputting a lot of zero bytes every 2.3 seconds over the serial line. So, at least I have somewhere to start looking :-)

Fred.

[Fred]

Solved, I didn't update the makefile objcpy args after changing the memory layout, it's running as before now. Time to have a shower and then try to make it run out of ram.

Fred.