dcb! Nice to see you back
Thanks for contributing - and yeah, I'm really still in awe at a lot of the creative (in a good way) things done with the MPGuino code... it's just a lot of things I see in the code that are either done just plain goofy, or just that I don't understand the hack yet... for example, the #defines are littered all over the code, making it really hard to track where things are defined (is it a variable or a define?, that's always bugging me), and the "loose" C bracketing
{
like this;
or if (this)
... do that;
}
... just drives me up the wall when trying to follow a program flow. A good 3/4 of my time so far has been spent trying to follow the program flow so I can understand
exactly to the binary digit what's going on in its head, and so far I've ended up having to boil a lot of stuff down because I just don't get it. That's my biggest concern...
You've gotta give Arduino some credit though. Unlike the re-implemented utility functions in MPGuino, the Arduino code is continuously updated to fully implement and support the latest hardware, and implemented in a very flexible way (admittedly, with a little performance overhead, but considering the ATmega328 is idling so much as it is). From what I find, the LCD interface is the most time-consuming part of the loop, and everything else (interrupts) are resource-independent (as long as I don't do too much cli() and sei()), so as long as I'm frugal with LCD updates - plan twice, write once - I think we have lots of wiggle room with timing
However, I have already run into conflicts between the custom AVR code and the Arduino core libraries... the way interrupts are implemented in each, breaks delay() and any functions that internally rely on it (I haven't checked delayMicroseconds though but it seems delay() is now timed like delayMS). I might have to "choose a path" soon, and either go all-AVR, or convert the whole MPGuino code (interrupts, timing, etc) to Arduino code... I don't much like the latter idea due to the incredibly stable way it runs already. But we'll see...
Sorry I haven't posted much in the past week, as I really only get a chance to work on this on weekends. Portal 2 came out on Tuesday, after all!
I really just need to find a good, clean work area to sketch out a flowchart and pseudocode. I went the "quick and dirty" way with the new settings menus in my modded code (the clock menu is really pathetic, but it works). In the new code I plan to implement everything inside the running loop if at all possible (multithread-emulating scheduler?), so the UI remains predictable and prevents the menus and alt modes from interrupting the main loop's functions (using instant to update current/tank, for example). It's going to be a lot of fun.
BTW, I never got any feedback on my UI mock-ups... I'm still planning on implementing that basic system (with just very minor changes I've thought of since that night):
http://ecomodder.com/forum/showthrea...tml#post227195
As for features, I also forgot to mention, yes, the improved big font as well. Don't know if there's much I can do to improve on that, other than drop the padding 0's... but that's another fun thing I'll have to figure out an interface for... I didn't really address that very well in the UI mockup. I rarely use Big in the car, because it's so hard to get to! :P