Fred's firmware development diary comments thread

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary comments thread

Post by Fred »

jharvey wrote:Is there a way to make nice circular pictures / timing schematics? Something similar to what delta posted about a while back.
Try Kivio, it's a Visio clone from KDE esp for diagramming. I ran across it in the EEE help stuff. Thought you might like to know.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Fred's firmware development diary comments thread

Post by jharvey »

About the serial bug, have you looked at it on a bit level? Perhaps it's reading the bits reversed, so lsb is on left rather than right. Or perhaps you expect a 1 and it's a 0. Curious if that could be the issue, and some times a bit hard to see when starring at 0x.

Can you post a bit of data sent, then received?
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Fred's firmware development diary comments thread

Post by jharvey »

Fred wrote:Try Kivio, it's a Visio clone from KDE esp for diagramming. I ran across it in the EEE help stuff. Thought you might like to know.
Looks very similar to Dia, also looks much more like the office I'm used to using, so I'm installing it.

I've been stewing over flow diagrams, but I can't seem to make myself happy with what I've come up with. Right now I'm simply scratching it on a paper, but still, I don't think they show how the software flows. Seems everything works fairly independently from the other parts. I think it really wants different flow diagrams for init, spark, and fuel. Blocks lay-ed out something like this perhaps.
  • power on --> init --> normal op
  • init,
  • set up reg's, timers and hard config
  • reset some stuff / flush some buffers
  • turn on IRQ's and allow "normal op" to take over
  • normal op,
  • main
    • sample A/D's
    • perform scheduled calcs
    • send log data
    • loop
  • RPMISR(s)
    • calc RPM, position, ect
    • schedule fuel / spark timing calcs
    • enable fuel / spark
  • IgnitionDwellISR
    • start dwell
    • keep track of ignition
  • IgnitionFireISR
    • fire coil
    • keep track of ignition
That's a basic overview for the moment.
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Fred's firmware development diary comments thread

Post by jharvey »

I'm having a pinch of trouble connecting the software and the hardware. To me it looks like the hardware is like this.

CPU
  • timer 1 --> spark 1
  • timer 2 --> spark 2
  • timer 3 --> spark ect
  • gpio --> injection 1
  • gpio --> injection 2
  • gpio --> injection ect
  • A/D 1 --> map
  • A/D 1 --> tps
  • A/D 1 --> ect
However I see ign dwell isr and ign fire isr. Which I thought were controlling these pins via software, not hardware. Perhaps I'm reading the code wrong, or perhaps what I'm reading is a draft...

Scratch scratch, still stewing it over, code isn't my strong point.
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Fred's firmware development diary comments thread

Post by jharvey »

From here http://freeems.sourceforge.net/doxygen- ... ts_8c.html this may want to update for the next release

firmwareVersion [33] = {"FreeEMS Vanilla v0.0.13 pre-alpha"}

Should be 0.0.16 not 13 right?

Should I post small nit picky stuff like that to you directly, or do you think it's good to have it public. It's your preference, I'll do it however you prefer.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary comments thread

Post by Fred »

That [second to] last list is almost totally wrong. You can't really know what in the code is doing what in the hardware without reading the 1000 page spec doc extensively and mapping them across, hence the (slightly out of date) pin out document.

Much of the code is somewhat skeleton stuff. Much of it will change a great deal over the next few months.

Definitely public, thanks for pointing that out.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Fred's firmware development diary comments thread

Post by sry_not4sale »

jharvey wrote:From here http://freeems.sourceforge.net/doxygen- ... ts_8c.html this may want to update for the next release

firmwareVersion [33] = {"FreeEMS Vanilla v0.0.13 pre-alpha"}

Should be 0.0.16 not 13 right?

Should I post small nit picky stuff like that to you directly, or do you think it's good to have it public. It's your preference, I'll do it however you prefer.

Thats what a bug tracker should be about, so ideas/suggestions dont get lost and can be voted on IMO
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary comments thread

Post by Fred »

I've added a note to the release procedure about the versions. And updated the file ready for the next release. I'll keep the interface version and the code version in sync for now as they will change each time there is a release from now until the forseeable future anyway.

Aaron tells me the SF bug tracker is ok, cancel that, the bastard has started using it :

https://sourceforge.net/tracker2/?group ... id=1029737

I guess that is a good idea! I'll add something to the bugs thread about it now.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Fred's firmware development diary comments thread

Post by jharvey »

I've looked over the 9s12 data-sheet again, and I've updated the list a bit. This is how I see the connections between hardware and software at the moment.

CPU
  • ext bus --> spark 1,2,3,4,5,6,7,8,9,10,11,12 (using 2 PIT timers)
  • 8 timers --> injection 1,2,3,4,5,6, RPM1, RPM2
  • A/D 1 --> map, tps, ect
  • PWM --> not currently used / test outputs
This now match's what I expect from the software. Perhaps updating the pin-out data table would help. The column "output ignition" perhaps should say something like "S12 data-sheet description" I'll have to see if I can learn me enough about the bug tracker to add that to SF.

[Edit] I edited the above because it had some inaccuracies, and I don't want to avoid having copies of it out there that are inaccurate [/Edit]

I'll likely make a dia of the above, for a pretty picture to use in web pages and such.
Last edited by jharvey on Thu Oct 23, 2008 5:33 pm, edited 1 time in total.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary comments thread

Post by Fred »

jharvey wrote:[*] ext bus --> spark 1,2,3,4,5,6,7,8,9,10,11,12 (using 4 PIT timers)
Closer :-) Only two pit timers though.
[*] PWM --> not currently used
Not for anything important, but they visually verify the sensor readings right now.

The column is already called "Freescale intended use" and there are cpu internal, external etc names also. Not sure what you are looking at/talking about there.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply