t vago's MPGuino workspace thread, continued

[t vago]

Originally Posted by josemapiro

Hi t vago



I think it's a combination of several factors that causes the error so it's hard to find.
But when I can, I will update the bootloader to correct some of the known bugs.

Thanks
José Rodrigues

Reading over the release notes for the Arduino IDE, I came across this little tidbit...



It may very well fix your issue. I remember very clearly that it was shortly after the 20170107 that I started having problems with my Mega2560. At the time, I though I had zapped it with static electricity or something.

[josemapiro]

Originally Posted by t vago

Reading over the release notes for the Arduino IDE, I came across this little tidbit...



It may very well fix your issue. I remember very clearly that it was shortly after the 20170107 that I started having problems with my Mega2560. At the time, I though I had zapped it with static electricity or something.

Yes it is possible, this problem occurs due to several situations some of them have already been detected but it is probable that there are others that have not been, but it is better to update the bootloader to make the correction of some errors Already known.
Maybe it was better put an note on the start page for this possible problem.

Thanks
José Rodrigues

[t vago]

Originally Posted by josemapiro

I've been testing the menu, and it seems to be on track but needs some fixes.
A bug I found, is to move forward, must repeat the line that is down the next menu, but on the top line. How is lets not select the row below.
Another fix would be the arrow that indicates the selected line, position yourself above or below in order to be possible to see the next line to be selected. Ie if you use the up button, the arrow should be down, to show up the next line, if you use the down button, the arrow should be on top, to show the next line below.
For the first presentation this menu is very good, when everything right, I have no doubt it will get 5 stars, is much easier to work.

The menu actually appears to have disappeared into thin air, from when you wrote that so long ago. No matter, I found and re-incorporated it into the latest code version.

Trying to figure out how to implement what you've described. I have something similar in mind - stand by.

Originally Posted by josemapiro

Yes it is possible, this problem occurs due to several situations some of them have already been detected but it is probable that there are others that have not been, but it is better to update the bootloader to make the correction of some errors Already known.
Maybe it was better put an note on the start page for this possible problem.

That's a good idea. I rather dislike having to keep two separate versions around.

[t vago]

Updated the first post in this thread to be a bit more easier to follow. Optional features have now been explicitly described as such. They can be enabled or disabled at compile time. Any exceptions (like software clock and deep sleep being incompatible with each other) are spelled out.

Deep sleep appears to be a success. My MPGuino completely goes blank and appears dead to the world, but still wakes up and responds to button presses (and, more importantly, to the engine being turned over or to vehicle movement). Going to attach an ammeter to see what kind of current consumption goes on while MPGuino is in deep sleep. The complicating factor for this addition was getting deep sleep to work with analog buttons. Deep sleep with analog buttons will consume more current than deep sleep using legacy 3-button support, but will still be less than when MPGuino is active.

The menu system is back in place and functioning well. I think I have implemented what josemapiro wanted.

Modified the code to lay the foundation for additional timeouts, similar to the inactivity timeout, for idle, EOC, and park (engine off and vehicle stopped). All timeouts have a user-definable stored parameter, and each timeout can go from 1 second to 255 seconds. I am looking at an idle timeout of 10 seconds, an EOC timeout of 1 second, a park timeout of 3 seconds, and an inactivity timeout of 120 seconds.

The idle timeout will cause MPGuino to display the Instant Trip and Current Trip idle screen, while the EOC timeout will display the Current Trip and Tank Trip EOC screen. The park timeout will be used for trip auto-saving, to support wiring MPGuino to an accessory power source (as opposed to battery). Once the park timeout has elapsed, MPGuino will then go through the inactivity timeout period as before.

The idle and EOC timeouts will reset if either the vehicle is moving with the engine running, or if the vehicle is stopped with the engine off. The park timeout will reset if either the engine is running or the vehicle is moving. The inactivity timeout will reset if the engine is running or the vehicle is moving or a button is pressed.

Also dusted off my notes from my earlier attempt to add coastdown determination two years ago.

[josemapiro]

Hi t vago
When will we be able to test this new version?
An addition that might be good was when MPGuino starts to present a text asking if you want to continue the previous trip, if it is affirmative you would just press the ok button, if you did not press any button at the end of 20 or 30 seconds would start a new trip .
This would be good for long journeys, which may take long stops to rest and then continue the journey.

Thanks
José Rodrigues

[Ardent]

Originally Posted by t vago

Deep sleep appears to be a success.

I want to test that, but my test time got eaten up with repair time diagnosing and replacing the flakey LCD.

[Ardent]

Originally Posted by josemapiro

Hi t vago
When will we be able to test this new version?
An addition that might be good was when MPGuino starts to present a text asking if you want to continue the previous trip, if it is affirmative you would just press the ok button, if you did not press any button at the end of 20 or 30 seconds would start a new trip .
This would be good for long journeys, which may take long stops to rest and then continue the journey.

Thanks
José Rodrigues

I disabled the auto reset as there is no circumstance where it is desirable for me.

[t vago]

Originally Posted by josemapiro

Hi t vago
When will we be able to test this new version?

Well, I could release it tonight, but I want to test the latest Legacy LCD changes first. Was able to shave off 20 or so bytes after examining that part of the code, but I want to ensure the changes work first.

Originally Posted by josemapiro

An addition that might be good was when MPGuino starts to present a text asking if you want to continue the previous trip, if it is affirmative you would just press the ok button, if you did not press any button at the end of 20 or 30 seconds would start a new trip .
This would be good for long journeys, which may take long stops to rest and then continue the journey.

Alternately, you could have trip save/restore enabled, disable current trip auto-reset entirely, and then manually reset the current trip. It would behave exactly like the tank trip.

Got my new Arduino Uno in the mail, so I now have four active test platforms. Also got one of these in the mail (but I have to put it together first).



It's a combination LCD and 5-button module that connects to the Arduino via TWI (I2C).

[josemapiro]

Hi

Originally Posted by Ardent

I disabled the auto reset as there is no circumstance where it is desirable for me.

Originally Posted by t vago

Alternately, you could have trip save/restore enabled, disable current trip auto-reset entirely, and then manually reset the current trip. It would behave exactly like the tank trip.

My idea was to have something simple and practical, like pushing a button and continuing the trip.
The current system though does the same is not practical.

Originally Posted by t vago

Got my new Arduino Uno in the mail, so I now have four active test platforms. Also got one of these in the mail (but I have to put it together first).



It's a combination LCD and 5-button module that connects to the Arduino via TWI (I2C)

Very good.

Thanks
José Rodrigues

[t vago]

Originally Posted by josemapiro

My idea was to have something simple and practical, like pushing a button and continuing the trip.
The current system though does the same is not practical.

I'll add it in, but it won't be a priority.

However, I do have some good news - My code now is able to use the TWI as an output interface. I have it using a SainSmart 2x16 LCD module for now for testing, but I hope to have that Adafruit RGB LCD shield fully functioning by the time the week is out. After that... a TFT interface? Why not?

I lifted the TWI code from the twi.c code that was part of the Arduino Wire library, and have cleaned up extensively and modified for use with the code. I hope to have it be able to support buffered output very soon. Yes, TWI is itself buffered, but it acts in practice as an extra digital input/output port, with all of the timing constraints and pin manipulation requirements, so I still have to do all of the port manipulations that I did with the original legacy 16x2 LCD module.

I also plan to try to implement LCD brightness over TWI that isn't either off or eyeball-scorching on.

Terms of the GNU Lesser General Public License, which covers the twi.c library