Fred's firmware development diary

[Fred]

Chores today didn't take too long, so got quite a bit done today, too. Tomorrow's chores should be done by 1 or 2 pm or thereabouts, so hopefully more progress after that. I was drawing some designs out on paper today, and came to realise how I want things to work. I got started on coding it tonight, but didn't get that aspect usable just yet. Mañana mas! :-)

[Fred]

Yesterday's chores took all day. I was contemplating bed around midnight and realised that I hadn't written a single line of code all day. I decided to remedy this and replaced 1 line with 12 to do something a bit different as an experiment. Then I went to bed. IE, achieved nothing of value to the project yesterday. Today I will achieve something, though I'm unsure what :-p

[Fred]

Great progress made! In lots of different ways :-)

I'm pretty excited about some new hardware that someone has been designing using Eagle. I may have been giving some feedback on this, but once this person "goes public" with it, I encourage everyone else to critique the thing too. I really like what he's done so far, though :-)

My "top secret" app is feeling more like a full blown app every day. Today it does some neat tricks that make it super slick and fast to use. I think it was yesterday that I made it do something properly (and cleverly) that it had previously been doing badly, but smoothly. And the day before that I gave it some bling and unique features.

Unsure what I'll be doing tomorrow, but it will involve the first dirty harry flick :-)

Fred >> Bed!

[Fred]

HUGE day today :-)

Today I christened the new app. For a first timer, she did really well. Someone even suggested a new name which I intend to put into the production installer on one system in their honour. BIG progress, really satisfying, really happy. New ground broken in multiple different ways. First use of quite a bit of code today, too, and highly successful overall. Really efficient in both CPU cycles and memory, by design. Still needs some massaging to do everything required of it, however the performance has been surprisingly good, beyond expectation.

Tomorrow I have to fill out some paper work as a matter of priority. After that I need to fix a bug/omission that I spotted just before bed. Then I need to write up some notes and TODOs from yesterday and today. Various other things will pop up, for sure. I might flesh out a couple of new features for fun, too. Lots of tidying up of various loose ends and POC stuff to do as well.

Thursday will be a firmware day. I need to finish off 256 and get some bench testing in on the common decoders and other stuff I have available. Then I can push it out to users to verify and play with. Then I can push the resulting commits to master and move on with one less temporary branch.

Time to snooze soon! :-)

Fred.

[Fred]

viewtopic.php?f=54&t=2108 FYI

[Fred]

Heaps done today! Not on the firmware, though. Tomorrow I need to send a letter to the other side of the world and work on the firmware. New app gets shelved until I have the work for 256 testable on at least 5 platforms (three for me, one for sean, one for peter). Then it'll be down to business cleaning up my lib situation and getting some libs released using a new ID format. That'll allow me to add a crucial feature to the new app. Then it'll be down to finishing off missing parts and bringing prototyped parts up to spec. It's functional and usable right now, though. Just for me for the time being. Will be on the phone to the south east in the next few weeks for sure :-)

[Fred]

Failed to send the letter. Failed to code fw. Did clear my desk and power up my test rig, though. Then got pissed off/upset at a couple of people and went for a drive. Then coded a new feature and saw some wondrous things in front of my eyes for the first time. Now time for snack and bed. 2:34am :-)

Manyana mas!

Fred.

[Fred]

New feature more polished, chores done, Saturday relaxation had, phone calls made, pretty good day overall! More tomorrow :-)

Any feedback on Ari's hardware design is welcome, here's the link: viewtopic.php?p=33767#p33767

242am, bed!

Fred

[Fred]

256 is up and running here in Barcelona!

New configuration items:

Code: Select all

		syncConfirmationsRunning: 10, // TODO make this sensible
		syncConfirmationsStarting: 0, // TODO think about which users need this and which would be better with 1 or 2

I don't know what a good value for running is, and it'll depend on your decoder type anyway, with more sync points, a higher number will be appropriate. I'll let you report back on this. It's a balance between protecting the engine while under load and allowing it to stay running with intermittent sync losses at idle. Also the higher the number the longer it'll be dead for and the more violent that transition will likely be. Zero confirmations will running really means one. It's not possible to put zero in running, and nor should it be.

New behaviour is to confirm sync at least once if already running, and from not at all for cranking on a fresh start. You can make it more conservative, however increasing the cranking confirmations will only slow your starting down so is not generally advised except perhaps on fresh setups. The above defaults are likely to be OK for most people. I'll change them as we learn more about this.

Some pictures here:

http://stuff.fredcooke.com/SyncConfirmations/

With descriptions below.



This one shows what happens if your signal is pretty much totally wrong and your starting setting is zero and your running setting is non zero (forced). IE, it fires a few rounds off at first, then nothing more post the first sync loss:





This one shows a 48 + 1 signal applied to a 24+1 decoder with 1 confirmation on starting and 0=1 on running, nothing is ever output:





Simulated sync loss while running with running setting at zero (forced 1). This shows clearly why it's important to have this feature. Without it outputs would have begun, and begun wrongly after the "crank" signal recovered due to the sync being picked back up in the middle and not being lost until the following sync point came in with a wrong count:





Simulated sync loss while running with running setting at 10, which means 11. This is clearly excessive, however if you had chronic sync loss, it could be worth while to protect this strongly. The value used will depend on how reliable the syncs actually are. Even tooth plus one is the worst possible case for this. Most others are a lot better:





This one shows a delayed start from 10 confirmations in starting mode, hence I recommend zero, or at most 1 (to protect against bad firing bending a rod or similar, IF you're paranoid):





Current location ID for these two configs is 0xC026 and adjustments can be made with EMStudio. If you're increasing the running value, it could mean your "burn stumble" gets sufficiently worse so as to kill the engine. It should fire right back up, no big deal. It might make sense to keep the running number at zero (effectively one) while tuning for this reason, and leave it at a higher value for real world use.

I'll push a beta version of this up today. The commit will clearly state what is supported and what is not. Do not use it or test it unless your decoder is listed as supported...

Fred.

[Fred]

So aside from the even tooth decoder, I also completed work on the J series decoder and the hall effect dizzy decoder. I didn't take a stab at Sean's LT1 decoder or the missing tooth decoder yet. I didn't push the code up yet, either. It's not quite ready. Sim has a binary for the snot rocket if he wants it, though. The same one used for the above tests.

I started working on the firmware at about 11:15am and didn't stop working on it until about 20 minutes ago, 1:45am. I did have a brief intermission for dinner, though. That makes for 14 hours straight on the firmware today.

BenchTest module was broken, and had been for some time, untested by anyone, me included. I fixed and pushed that up some hours ago.

Tomorrow I'll complete work on 256 and get it out for testing. I'll also integrate Andy's two configs and update Peter's config. I might also retire the slater config as that car is dead. RIP slater! I might sneak in some light refactoring on the table look up stuff with respect what Eric found a few months ago.

Then I'll work on the new app until each decoder sees some real world testing. Then I'll probably dig into the next two key issues which are related to each other.

A great day, all in all :-)

Fred.