Fred's firmware development diary comments thread

[Fred]

Chuck your thoughts and comments in here.

Admin.

[Fred]

I must say, I'm highly disappointed that none of you at all have anything to say about the code or rate of change of the code or even how well documented it is :-p

...maybe this thread needs a bump...

[jbelanger]

I've had a very quick look at the code and I'll dig into it more but I liked what I saw. I'll see if I can port the code to the 9S12XEP100 because I just bought the demo board which is just $37.65 at Mouser. I know this CPU is not readily available but I don't think there will be much to do to port the code and for experimenting it was worth the potential hassle.

I'm not sure if this is the right place for this but I think it would be a good idea to have some high-level design document for the code. It doesn't need to go down to a very detailed level (even though it might be nice) but at least a high level description of what can be found where and what it does. With one designer, this is not really essential but if this number increases it becomes more useful and it would be nice to discuss design before doing the implementation.

Jean

[Fred]

I've had a very quick look at the code and I'll dig into it more but I liked what I saw. I'll see if I can port the code to the 9S12XEP100 because I just bought the demo board which is just $37.65 at Mouser. I know this CPU is not readily available but I don't think there will be much to do to port the code and for experimenting it was worth the potential hassle.

There is a large pdf doc that describes how to write code for each such that it can be run without change on the other. I haven't looked at it much, but fundamentally they are the same chip in most ways. At this stage at least, all you will need to do is make up a new header (If I had structured ours better, It would have been even easier, and I may change that in future anyway for that reason), and a new memory.x file. Other than that, it should just work.

I'm not sure if this is the right place for this but I think it would be a good idea to have some high-level design document for the code. It doesn't need to go down to a very detailed level (even though it might be nice) but at least a high level description of what can be found where and what it does. With one designer, this is not really essential but if this number increases it becomes more useful and it would be nice to discuss design before doing the implementation.

Perhaps KW's thread would have been better, but this is fine too. I agree, and if you look at the time line, it shows me experimenting and playing with the different modules etc for familiarity and example reasons and writing low level core routines, such a serial comms, ready to be ported to a structured form. Then It shows us all getting together in a thread and fleshing out a detailed design before proceeding any further. At that point the pressure is off me, at least in the short term, and onto "you" i.e. the group to make sure that the design is a good one before any serious implementation occurs.

I would like to point out that the code currently posted is dead simple and just experimental. Although generally I've tried to keep it well docced and tidy there are some evidences of my experimenting in there. i.e. don't judge me on it just yet :-) (The perfectionist (evident discussing dizzys elsewhere) will show through in the code sooner or later).

With a bit of luck, the thought I've put into an eventual design will show up in the basic code structure (which still needs a tidy up) and not need to be changed much/at all to suit our detailed design.

About the time those designs are being drawn up will be about the time that I am seriously looking for a job before my better half plants her foot in my rear end and I end up shivering outside the house at night. Once I am working I intend to spend 2 - 4 hours a day on code and forum catch up and site maintenance etc.

Having said that, I think the code needs to actually more or less work for someone so inexperienced as myself to truly have a good idea what we need to do for the "final"/"initial"/"for good" solution. So I'm working on making it work right now :-)

Admin.

[Fred]

I'll see if I can port the code to the 9S12XEP100 because I just bought the demo board which is just $37.65 at Mouser.

Also, post decent (1024x768) pics of your setup in a new thread :-) (please)

Admin.

[jbelanger]

Concerning the problem of handling the timing when injection timing and injection duration overlap, I think that you should do as follows:
- have a flag indicating that injection is on (since you can't read the pin value). This is set when starting injection and unset when ending the injection.
- before scheduling the start of injection check the status of the injection flag; if the flag is set then set another flag to force the start of injection at the next tooth interrupt.
- when you get a tooth interrupt, check the status of the forced injection start flag; if the flag is set then set the injector pin to ON, reset the end of injection to the correct pulse width duration, unset the forced injection start flag, and set the injection flag.

With this you no longer do precise timing of the injection when you start using forced injection. However this depends on the number of teeth on the wheel and will likely be at more than 90% duty cycle (with 12-1 wheel this is at least 91.7% if you happen to need to start during the missing tooth gap; 97.2% with a 36-1 wheel) and in that case, precise injection timing is no longer that important. Also, this allows a smooth transition up to 100% duty cycle. This should not be required because injectors should be sized appropriately but if needed for whatever reason, this would allow the maximum use of what the injectors can do.

Jean

[Fred]

Thanks for your input :-) It's important that I learn the hard way like this, but at some point help is nice. And. the more ideas the better!

I'll have to re read that in the morning. I'm a bit tired to understand it now.

have a flag indicating that injection is on (since you can't read the pin value). This is set when starting injection and unset when ending the injection.

I don't think this is necessary as there are three things you can check : PORTT reads correctly IF its DDRT value is set to input. PTIT always reads correctly. The OC action registers act as a flag that gets set and unset.

I'll keep playing with my current idea "B" until I prove that it doesn't work or does. If it doesn't I'll try yours :-)

There will be a way to do it without dropping accuracy or timing, I just have to find it :-)

Thanks again! Good to know you are keeping an eye on me :-)

Admin.

[jbelanger]

have a flag indicating that injection is on (since you can't read the pin value). This is set when starting injection and unset when ending the injection.

I don't think this is necessary as there are three things you can check : PORTT reads correctly IF its DDRT value is set to input. PTIT always reads correctly. The OC action registers act as a flag that gets set and unset.

True. But one advantage of having the flag is that it abstracts the method used to control the injector pins. If you bit bang the injector outputs then you need to do something else. With the flag, the check is a simple bit compare no matter which method is used.

I'll keep playing with my current idea "B" until I prove that it doesn't work or does. If it doesn't I'll try yours

There will be a way to do it without dropping accuracy or timing, I just have to find it

Thanks again! Good to know you are keeping an eye on me

Admin.

It's always good to try to keep things accurate but I doubt that having precisely timed injection with over 95% duty cycle will make any difference (but then I'm not an expert on the subject). And if it's a concern, I would change the injectors to have a more appropriate capacity instead.

If you can find a simple way to do it then great. If not, then I don't think it's worth having complex code in a time critical part of the code. Don't forget that you're the one saying you want to avoid "if" statements in the code. This is one of the more critical part of the code for performance. By the way, these statements are also valid for your proposal of having a timer prescaler that would require multiple timer interrupts for a single injection pulse.

Jean

[Fred]

True. But one advantage of having the flag is that it abstracts the method used to control the injector pins. If you bit bang the injector outputs then you need to do something else. With the flag, the check is a simple bit compare no matter which method is used.

True, although, this is prototype code, and I suspect that switching to bit banging pins will be sufficiently different code to have it's own setup anyway. As it is, it is clear what you are doing as its not just a flag, its also the action, and you arent checking a flag, you are checking the state of the control bits themselves (leaves no doubt in your mind when reading the code, or at least, thats the idea :-) )

It's always good to try to keep things accurate but I doubt that having precisely timed injection with over 95% duty cycle will make any difference (but then I'm not an expert on the subject). And if it's a concern, I would change the injectors to have a more appropriate capacity instead.

True, the accuracy doesn't matter up there, but the perfectionist in me wants to strive for it whether it matters or not. Kind of like polishing the combustion chamber or something. You do it so you know it's there right? :-)

If you can find a simple way to do it then great.

Plan B worked a treat :-) I'm just waiting for youtube to process the vids that demonstrate how it doesnt work without a chunk of code and how it works nicely with it.

By the way, these statements are also valid for your proposal of having a timer prescaler that would require multiple timer interrupts for a single injection pulse.

That's true too, it would have to be lean as hell for that. I strongly doubt that we will need to do that with proper sequential though. I think having the fuel timed right and accurate will prove to be very very good indeed. right now the time base is 0.8us and max period is 52ms which is plenty long enough and accurate enough for most anything really. Still, the test code for extended pulses works, so it's an option to do that at some stage in the future if we feel the need :-)

Thanks again!

[jbelanger]

Good that you have a working solution!

I should also add that, as I'm not convinced you need multiple interrupts for high duty cycle, I'm also not convinced you need multiple interrupts for low rpm accurate timing of the start of injection. In that case also, I don't think there is any benefit to precisely time the injection instead of using the easier method of just starting the injection on a tooth interrupt. This could be done up until you can time the start of injection with a single interrupt. I must say I haven't done the computations to validate that this is ok for reasonable toothed wheel but rely on your statement of 100rpm.

Jean