Seemed like we were getting a bit OT in the injector thread, so I'm migrating to here.
EssEss wrote: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.