t vago's MPGuino workspace thread
1 Attachment(s)
In the course of modifying the original MPGuino 0.86 code to incorporate the fuel injection correction factor for Chrysler vehicles with returnless fuel systems, I've been fiddling with the code, doing this and that and the other thing.
Since that other thread is really only meant for addressing that issue with Chrysler returnless fuel systems, it became increasingly apparent that a separate thread was needed to describe the other things I have done with the code. So, here it is. (All CPU workload figures assume a 20 MHz processor) Hardware Support added (as of 10 December 2013):
Program Features added (as of 20 May 2015):
Technical Features added (as of 25 October 2013):
Features in progress (as of 18 Jan 2016):
Features to be added (as of 12 May 2014):
The attached source code was developed to be copied and pasted into an Arduino 1.6.4 IDE window. Also, the code is configured to work on a JellyBeanDriver board - a 20 MHz AtMega328 with the traditional MPGuino 3 direct-wired pushbuttons and 2x16 character LCD screen. Make changes to the "#define" section, beginning at line 226, as needed. If you use the AVR command-line tools, use these settings for setting the programmable fuses to ensure that your MPGuino will work: Quote:
|
You have been busy :D
And i'm still struggling and trying to make flow-meter mode, voltage and some temperature reading features :) But a feature request, in case you dont notice, make those alert displays that they can be enabled and disabled. |
Okay...
I've been on vacation, but I am back now. Work continues on my code. These features have been added:
This has been modified:
The code is becoming a monster, though. It's at 20178 bytes, and shows no sign that it's going to stop growing any time soon. |
Quote:
I've also gotten my cpu load down to 3-5% on a 4x20 LCD, just by tweaking the LCD routines to meet the spec. The killer is delay2 (5 milliseconds) in LcdCommandWrite. It only needs to be 120 microsec. That should eliminate the need for that buffer you added. BTW, replacing "sei" with "sreg=OLDsreg", as you recommended in the Chrysler thread, seems to have stopped my weely T2-overflow crashes. Thanks again! |
Quote:
My code was actually about the same size as the 0.86 code was, for a few weeks. It took adding the ability to save/load/view trip data in multiple EEPROM slots, and the actual screen editing code, to cause my code to bloat out. At that, most of the bloat is text strings. Quote:
Quote:
|
Quote:
Buffered LCD code (approximately 1 ms per character): CPU loading = 2.2% Free Mem: 1044 Program Size: 20178 Bare LCD code (80 us per character): CPU loading = 3.2% Free Mem: 1172 Program Size: 20548 To be fair, the Bare LCD code did seem to be a bit more crisp in response, than the buffered code. However, it would not be that big of an advantage, compared to the fact that the code grew by 370 bytes, while only gaining 128 bytes of RAM. Ugh. |
i can't see how adding buffer code takes less flash space than the standard routines. Just glancing at my .sym file, the total space used for all LCD functions is 448 bytes. Then again, i did optimize the fornication out of it, stealing Arduino library bits where needed, and dropping alot of overhead.
I'm also running on a 168, so ram is at a much higher premium for me. Probably not the case with your 328. I'm still trying to squeeze in SD logging (512 just for the buffer) along with my bar graph and speed range tabulator. Also, by buffering the LCD output, aren't you really just hiding the true load, which could hit you on future addons? |
Quote:
I attempted again to remove the buffering earlier today, and only gained about 50 bytes. However, CPU utilization went way up, to around 20%, even with using the smallest possible delay with writing LCD bytes. No thanks. My LCD code takes up 460 bytes, including the buffering. Quote:
Quote:
The "true load", as regards outputting LCD characters, consists of waiting. If the code is waiting, then the code is not really doing anything useful. After all of that is done, the program patiently just sits there and waits for a button press, or for the loop to end. I figure, since the program is anyway not doing anything meaningful during that time, it can process the buffering. I'm strongly tempted to use the timer2 overflow interrupt handler to handle processing the LCD and serial buffers. If the overflow handler would process the buffer, then there'd be no need at all to worry about CPU loading due to outputting. |
Quote:
Quote:
|
This all makes me wonder if a multi-threading scheme could be based on the avr timers. I'll have to think about that some more later.
|
All times are GMT -4. The time now is 11:01 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com