Fred's firmware development diary comments thread

[Fred]

She ain't running yet! But things are pretty damn close :-)

Of course it will run like it has a plug lead off etc but it will be a good start :-)

Pics and vids will be mandatory when it runs. I've been taking plenty along the way though - eg SeanK sleeping while I worked ;-)

Fred.

(about bloody time!)

[BenFenner]

I didn't find out about the logging trip until I read about it just now. That's great! I'd be so proud if I were you Fred. Pat yourself on the back for me. =]

[Fred]

Thanks man, the fat lady hasn't sung for MS yet though, so stiill lots more work to do :-)

[Fred]

PS, war driving to post this :-) The joys of being homeless and living on the road!

[AbeFM]

I miss my cooler...

[jharvey]

Seemed like we were getting a bit OT in the injector thread, so I'm migrating to here.

the cool thing about that is you don't have to worry about the build environment - fred has already set it up. and a datasheet/um will cure the other problem.

I gave it a try a while back, but I don't currently have a Debian install, and it was proving to be a fair bit of work to apply the patches in Fedora. Even on Debian, everything is from scratch, and several of those from scratch intricacies don't work on Fedora. The work to make it go with Fedora was more than I cared to get into. I want to develop a functioning device, not a debug and develop a compiler. While I think it's great that you can do such development, I'm not good enough with my coding to work at that level effectively. I have been tempted to setup a VM and run a virtual Debian, but that's also a bit of work that I haven't pushed up in priority. I posted about that experience in this thread several posts back. I think this link might jump to it. http://www.diyefi.org/forum/viewtopic.p ... &start=140

When it comes to firmware, perhaps I should list a brief overview of what I'm capable of. I'm not quite a noob, I'm also not an expert. Perhaps my lack of insight into the hip bone, leg bone stuff is my lack of understanding of the PIT timer, and other S12X specific features like the semaphores. While I understand the concept, I haven't worked when them before, and I certainly lack a gut feel about these items. I've worked with more common processors like PIC's, PSoC, and ARM based chips.

I don't have a lot of experience with embedded processing, but have done FIR, IIR, A2D, D2A, GPIO, and IRQ based operations. I also have a basic understanding of many ASM and C programming techniques. There is certainly a lot of room for improvement in my embedded skills.

I'm currently dubbing with a project that uses Eclipse and arm-elf-gcc on my XP box. I also have that same environment setup on my Fedora box. I'm growing familiar with items like the crt0.S file, and other such build environment items that are common in the GCC build environment.

One key issue I run into with FreeEMS, is that I don't know the design intent. I can read the code, and get a fair idea of what it does, however I don't know what it should do. With out knowing what it should do, I can't say yeah or nae about how well its doing its task. I also can't say, yes it does its task, except in this condition, it does XX which may or may not be a problem.

About the Doxygen thing, where you patting me on the back for pushing Fred to use it, or were you patting Fred on the back for doing a good job implementing it? Doxygen is a great tool for documenting what's there, and the tags/notes offer a nice way to document design intent. Fred certainly has done a good job so far. I think the comments could be better filled in by including what goes into, and comes out of a chunk of code. Right now it typically notes things like, "schedules events". If it said something like, "schedules events by setting IRQ VIT table to schedule this event at the next available time", that would tell specifically what comes out of it, and I could confirm if that is what it does. I made some suggestions on how I thought the comments should read, see the above posts from me on Feb 28th of 09. With luck, found at this link. http://www.diyefi.org/forum/viewtopic.p ... &start=132

In the NipponDenso.c code, which I believe was (perhaps still is) the most developed section of code, I see lots of comments like "out of date as at 3/1/09", "VERY temporary" and "this will be wrong when the var is used correctly". I just don't know what parts of this code I can trust. I see the code was posted on 2009-02-09, with the 3/1/09 note. Struck me as odd. I also don't know what's out of date, what's temporary and what var is being used incorrectly? I have a lot of trouble capturing the design intent with that code. With out knowing the design intent, I'm having a lot of trouble in my attempts to contribute.

[EssEss]

where you patting me on the back for pushing Fred to use it, or were you patting Fred on the back for doing a good job implementing it?

I thought you did it and fred added it into the repo .. in that case the 'pat' is still for you

I have been tempted to setup a VM and run a virtual Debian

thats exactly what I did, but I made the mistake of using the stable build which didn't have the cross compiler as a pkg - the thread is somewhere around here. this was the first time I touched linux since about 10-15yrs ago too - things are sooo much easier nowadays. the sun vm was free and I just used debian so that I was as close to freds environment as possible. I think someone has also done it from windows too. if you have CDT installed on eclipse, you could probably just import his build from the makefile .. I'm almost certian that eclipse offers an export to a makefile too.

With out knowing the design intent, I'm having a lot of trouble in my attempts to contribute.

yep - knowing that something is around the corner prevents me from wanting to contribute to a base which will be obsolete momentairly. i've got plenty of other things to keep me busy until it happens.

[Fred]

NipponDenso.c, though functional, at some level, is purely experimental! The entire file is subject to change and this will all be happening very soon as we need to rearchitect and code that area to make it more general, more efficient and more reliable. That file is a big mess, really. I still comment my messes though, as it means I can pick the mess back up later :-)

I wrote most or all of the doxygen stuff, but Jared definitely pushed me into it - a very good thing indeed. He was also the one generating them for a long time, possibly all of the publicly available ones. Doxygen changed some of their code at some point and I can't figure out how to make it behave correctly with current builds now. The diagrams went horizontal and got HUGE.

Fred.

[jharvey]

Is NipponDenso.c the most developed RPM capture code at this time? Or are you using a different chunk of code, perhaps the MissingTeeth.c? What RPM capture code is the most current?

About the Doxygen call graphs, I believe the problem isn't Doxygen, but the call graph generator. I've seen that happen a couple times in the past. I suspect if you downgrade your call graph generator program to a stable version, your graphs will act as expected.

[Fred]

Each is the most developed of it's kind. Right now there is that, missing tooth, and simple, simple i haven't published yet, but it is as its name says :-)

All of them need to be merged/split/changed/reworked to use common blocks of code and be more efficient. NipponDenso currently takes too long to run.

Fred.