I have built an in-dash head unit graphical mpguino display

[skybolt]

Originally Posted by oldtamiyaphile

I would love to see a histogram in five minute intervals like the Prius G2 has.

Interesting. I haven't found the histogram to be very useful ... do you rely on it much or is it just eye candy? (Eye candy is a perfectly legitimate reason by the way).

For this project it would requre adding an additional chart type, and given the power of th d3js.org charts, I don't think a simple 2d histogram would cut it ... but then a histogram would be hard to fit on the screen.

I'm thinking something like this:
, but then maybe a simple line BEHIND the existing graphs might work.

I would have a real challenge fitting it all on one screen.

[oldtamiyaphile]

Originally Posted by skybolt

Interesting. I haven't found the histogram to be very useful ... do you rely on it much or is it just eye candy? (Eye candy is a perfectly legitimate reason by the way).

The Prius only has a single economy readout (which I use to monitor the tank to date), so I use the histogram as my 'trip'. So a bit of both, really.

[t vago]

Originally Posted by skybolt

No code with string 192, no easy math that maps to 19200 given 20/16MHz change, no identifiable myubbr string. **sigh**

There is a nice line

const unsigned int myubbr = (unsigned int)(processorSpeed * 625ul / 96ul - 1);

, but altering the 96 to any other multiple I can think of hasn't worked yet. I'm busy doing other things, so I haven't divided 625/96 or 96/625 but I will say then when it was compiled for 20MHz on a 16MHz microcontroller, data read properly at 19200 (or was it 9600?). Point is, the 16/20MHz change and relationship to 625 merits a quick run through a calculator. 625 is .625 which is 5/8 I believe, but 96 to 192 is a 1/2.

I think I may have oversimplified that myubbr calcuation. Here's what it should look like:

const unsigned int myubbr = (unsigned int)((processorSpeed * 62500ul / 9600ul) - 1);

With that line re-written as above, you should be able to replace '9600ul' with any legal baud rate that the Arduino can support.

I'll take a look at your other question when I get the time. Thanks again!

[t vago]

Originally Posted by skybolt

Also, since format takes a long, what do you do to format strings? I'll admit I haven't yet looked for strings, I'm just working on hijacking your serial out string to send it as json.

My format() routine calls my SWEET64 pseudoprocessor with a round function/decimal conversion function to round off the unsigned long number according to the decimal place specified by uint8_t ndp, and then to convert the input from hex into a chain of binary-coded decimal bytes for output.

After that, all it does is expand the output of the SWEET64 binary-coded decimal chain into an output ASCII string.

The string output is left in mBuff1

[skybolt]

There is nothing wrong with your myubbr statement -- this particular board (8 MHz 3.3v) can't push the data at anything faster than 38,400. My other board can be read at 57600 but no faster (on either code base, not just yours).

leave the myubbr as it is. I did have to change the processorSpeed to 8, but that would be expected.

[skybolt]

OK, T, I've added my json functions to your code base. I see how you're calling tFuelRemaing using the index and dfBitShift (some day you can explain how that works, seems like just an index), but some of the parameters don't behave as I expected

dSizeTankSize always returns 24, but dSizeTankSize doesn't look like a pointer so I haven't tried dereferencing it (and I'm not sure what the syntax would be anyway). Also, I'm not sure of the function of dOffsetTankSize, but any math operations on it cause format() to return "-----" which I see is an overflow - is that also called if the number is too small .. i.e. too large of a negative exponent?

I also see dSizeTankSize and dTankOffsetSize are in program arrays. So, to the questions:

-How do I call tank size?

-Is dOffsetTankSize the position of dSizeTankSize in the array, or is it a value such as "reserve fuel?". I'm hoping it's some kind of fuel reserve, but if not that'll be easy for me to add.

-My json send function is big and it's a lot of simpletx. I am seeing my global variables memory footprint gets larger as I add more the sendJson(). This tells me that simpletx is probably building itself in global variable space. If that's true, would making it into several smaller functions drop the footprint? (My guess is no or I would have tried it). I see when you call simpletx you call it once after constructing a big string. Would that be more efficient?

Attached is my set of updates. I will put it in GitHub once I figure out how to create and upload a repository from the command line -- It's time I learned that instead of going to Github, creating the repository, linking the local repository to the remote location ......... I am perfectly comfortable doing all that but I want to do it all from the command line. My GitHub guy will be here in the next hour or so.

Some random thoughts: the drag race function can be useful for hypermilers. All I have to do is add fuel use per run and people can optimize for least fuel use for 0-30, 0-60, etc., as well as least fuel use for first 30 feet, 60 feet, etc. Accelerating away from a stop is a huge efficiency drain and this will help people track it. I'll be renaming it away from "drag" to something more descriptive.

[skybolt]

I need to call tank size/max tank volume in order to show graphically how much is left. How do I call it using your code?

Also, what is the purpose of dOffsetTankSize? Is it the location of dSizeTankSize in an array, or is it a value (like a reserve fuel value?)

[t vago]

Originally Posted by skybolt

I need to call tank size/max tank volume in order to show graphically how much is left. How do I call it using your code?

As it stands now, you don't. All calculations were meant to be performed using SWEET64, as they take up much less program space. 64-bit unsigned integers are not natively supported in the Arduino library, so the orignal 64-bit calculations were performed by many subroutine calls. As I added more and more functionality, I discovered these calls were taking more more and more flash space, so I came up with SWEET64 to combat this issue.

It might be better to code a SWEET64 pseudocode program to generate the bar graph. It so happens, I have done some work on this program. It was originally meant to drive an analog output signal suitable for input to an analog gauge. This was a requested addition to MPGuino that I had worked to add. I just never got around to testing it.

your sendJSON function is straightforward, and the reason why it consumes more RAM is because simpletx is being called with many otherwise-constant strings that are being stored in RAM. Unlike the RAM buffer used to generate decimal representations of numbers, these strings would never ordinarily change. Moving these strings to flash memory should take care of RAM consumption.

Let me work on the code a bit, and I will post what I come up with here.

Originally Posted by skybolt

Also, what is the purpose of dOffsetTankSize? Is it the location of dSizeTankSize in an array, or is it a value (like a reserve fuel value?)

pOffsetTankSize tells MPGuino what address in the EEPROM to read TankSize. pSizeTankSize is the size, in bits, of TankSize.

[skybolt]

Thanks for the info --- I'm going to take a deep look at SWEET64 to see how it works, and I'm looking forward to seeing your new/changed code.

In the meantime I'm able to determine tank size by adding tFuelUsed to tFuelRemaining ... after I better understand SWEET64 that might not be necessary, but I'll look into it anyway.

Keep in mind that when I calculate the 'graph' or 'bar size' all I am doing is passing an integer or float to the raspberry pi via json, all graphical routines are handled in javascript on the pi side.

I will post both repositories to GitHub, today, and will add more meaningful comments.

[skybolt]

Arduino code that creates JSON output:
https://github.com/skybolt/Tavi_165_Mpguino


Web GUI to read arduino data from serial port:
https://github.com/skybolt/autoUpdate