Fred's firmware development diary comments thread
Posted: Sun Feb 17, 2008 3:27 pm
Chuck your thoughts and comments in here.
Admin.
Admin.
TRUE DIY engine management discussion forum
http://forum.diyefi.org/
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.jbelanger wrote: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.
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'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.
Also, post decent (1024x768) pics of your setup in a new thread :-) (please)jbelanger wrote: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 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.jbelanger wrote: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.
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.Admin wrote: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.jbelanger wrote: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.
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.Admin wrote: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.
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 :-) )jbelanger wrote: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, 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? :-)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.
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.If you can find a simple way to do it then great.
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 :-)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.