Test my OpenEVSE FW Ver 1.6.2 with RTC and Delay Timers

[chris1howell]

Here you go guys... I'll order boards tonight and will build the prototype in 1 - 2 weeks.

OpenEVSE RGB LCD backpack + RTC

RTC - DS3231 Ultra precise clock

 

[goldserve]

I just fixed the starting and stopping bug by implementing a different way to handle it (more like the original charing Enable/Disable via button method).

It is now ready to beta test so please provide feedback on the menus, LCD graphics, etc. Don't forget, if you like, please see the first post for donations!

Chris,

I like the look of the backpack Hopefully I can get one of these updated ones as well BTW, if I compile in RGBLCD suppport, does version 1.0.8 start up fine if the RGBLCD is not plugged in? It doesn't seem to start or get past reset if I don't have the RGBLCD plugged in. One other change from 1.0.0 to 1.0.8 was the switchover to use LiquidTWI2.h

Cheers!

 

[z0ner]

One other change from 1.0.0 to 1.0.8 was the switchover to use LiquidTWI2.h

Just FYI, 1.0.6 was the first release to implement LiquidTWI2.

 

[GlennD]

When I built Barbouri's board and loaded 1.03 on it I wasted hours trying to get it to work. If you have a display defined it looks for a display and hangs. I configured a version for Adrian with the displays disabled and it works fine.

I really thought I could at least power up the board and check basic functionality.

 

[chris1howell]

When I built Barbouri's board and loaded 1.03 on it I wasted hours trying to get it to work. If you have a display defined it looks for a display and hangs. I configured a version for Adrian with the displays disabled and it works fine.

I really thought I could at least power up the board and check basic functionality.

I have narrowed down the issue to the ADAFRUIT button. If the button is disabled the EVSE will work with or without the lcd connected. It appears if the button is enabled but not connected the EVSE assumes it is pressed. There are a couple possibilies to fix the issue. One is to assumed the button is not pressed until it changes state. The other is to query the display to make sure there is a valid bdevice at thethe i2c address before enabling the button.

 

[GlennD]

I loaded your version 1.6.0 on my test EVSE. Everything looks good. Now I need to receive the clock to fully test it.

By the way, without the clock it puts 165 for hours and min.

 

[GlennD]

Chris, do not waste time chasing the bug. As long as we know about it, its no big deal.

 

[goldserve]

When I built Barbouri's board and loaded 1.03 on it I wasted hours trying to get it to work. If you have a display defined it looks for a display and hangs. I configured a version for Adrian with the displays disabled and it works fine.

I really thought I could at least power up the board and check basic functionality.

I have narrowed down the issue to the ADAFRUIT button. If the button is disabled the EVSE will work with or without the lcd connected. It appears if the button is enabled but not connected the EVSE assumes it is pressed. There are a couple possibilies to fix the issue. One is to assumed the button is not pressed until it changes state. The other is to query the display to make sure there is a valid bdevice at thethe i2c address before enabling the button.

Thanks for tracking this down to this level. I was going to put prints all over or use serial wire debug but now I have something to work on. Since I only have one display right now acting as my development and production system, I would like to set up the timers, RTC, move it to production and let my car charge without the use of a LCD.

Cheers!

 

[goldserve]

I loaded your version 1.6.0 on my test EVSE. Everything looks good. Now I need to receive the clock to fully test it.

By the way, without the clock it puts 165 for hours and min.

Cool. I can't wait for someone else to try it out and provide feedback. I need to test with the more accurate RTC as well. Fingers crossed that it will work without any modifications.

 

[chris1howell]

I loaded your version 1.6.0 on my test EVSE. Everything looks good. Now I need to receive the clock to fully test it.

By the way, without the clock it puts 165 for hours and min.

Cool. I can't wait for someone else to try it out and provide feedback. I need to test with the more accurate RTC as well. Fingers crossed that it will work without any modifications.

Just found my CronoDot RTC that I bought a long time ago... Ill load and test your firmware tomorrow...

 

[goldserve]

OK. I debugged the issue with the EVSE not starting up without the LCD connected. The LiquidTWI2 library is looping on successful END transmission of I2C and when no I2C device is connected, it keeps waiting.

I've hacked the following code in the wire.h library to just return 0 all the time. I will do some more testing later on but will eventually move this fix into the LiquidTWI2 library instead.

uint8_t TwoWire::endTransmission(uint8_t sendStop)
{
  // transmit buffer (blocking)
  int8_t ret = twi_writeTo(txAddress, txBuffer, txBufferLength, 1, sendStop);
  // reset tx buffer iterator vars
  txBufferIndex = 0;
  txBufferLength = 0;
  // indicate that we are done transmitting
  transmitting = 0;
  //return ret;
  return 0; //GoldServe hack to always return false.
}

Edit: I had a theory but adding pull-ups even when the I2C device is not there will not work. The return code will always be some error as long as we don't have the proper device responding on the bus.

/* 
 * Function twi_writeTo
 * Desc     attempts to become twi bus master and write a
 *          series of bytes to a device on the bus
 * Input    address: 7bit i2c device address
 *          data: pointer to byte array
 *          length: number of bytes in array
 *          wait: boolean indicating to wait for write or not
 *          sendStop: boolean indicating whether or not to send a stop at the end
 * Output   0 .. success
 *          1 .. length to long for buffer
 *          2 .. address send, NACK received
 *          3 .. data send, NACK received
 *          4 .. other twi error (lost bus arbitration, bus error, ..)
 */

So to fix it, I changed the following functions in LiquidTWI2.cpp instead.

void LiquidTWI2::burstBits16(uint16_t value) {
  // we use this to burst bits to the GPIO chip whenever we need to. avoids repetitive code.
  Wire.beginTransmission(MCP23017_ADDRESS | _i2cAddr);
  wiresend(MCP23017_GPIOA);
  wiresend(value & 0xFF); // send A bits
  wiresend(value >> 8);   // send B bits
  //while(Wire.endTransmission());
  Wire.endTransmission(); // Fix to not spin in no I2C device (GoldServe)
}

And

void LiquidTWI2::burstBits8b(uint8_t value) {
  // we use this to burst bits to the GPIO chip whenever we need to. avoids repetitive code.
  Wire.beginTransmission(MCP23017_ADDRESS | _i2cAddr);
  wiresend(MCP23017_GPIOB);
  wiresend(value); // last bits are crunched, we're done.
  //while(Wire.endTransmission());
  Wire.endTransmission(); // Fix to not spin in no I2C device (GoldServe)
}
#endif // MCP23017
#ifdef MCP23008
void LiquidTWI2::burstBits8(uint8_t value) {
  // we use this to burst bits to the GPIO chip whenever we need to. avoids repetitive code.
  Wire.beginTransmission(MCP23008_ADDRESS | _i2cAddr);
  wiresend(MCP23008_GPIO);
  wiresend(value); // last bits are crunched, we're done.
  //while(Wire.endTransmission());
  Wire.endTransmission(); // Fix to not spin in no I2C device (GoldServe)
}
#endif // MCP23008

 

[mitch672]

I wonder if at initialization, you could run a piece of code, similar to "i2cdetect" shown on this AdaFruit tutorial (link belw), on how to add a RTC to the Raspberry Pi, then if you get no devices at the I2C addresses of the LCD display, or RTC, just don't try to use them, and assume they are missing, this might be the solution to making OpenEVSE flexible, so it doesn't need to be compiled for specific hardware options, but checking for them during startup, and if found, uses them, if not, it functions without hanging/requiring a recompile.

http://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/wiring-the-rtc" onclick="window.open(this.href);return false;

BTW, I tried your code, and it works, except I don't have the RTC hardware yet, so erroneous time/date readings show up. A perfect case for testing to see if I2C device ID "68" is present, if not, disable the date/timers functionality.

 

[goldserve]

It could be easily done but i'm almost out of code space and I'll need to put a lot of conditional statements...The EVSE will be mostly stationary and won't have hardware pieces missing from time to time so i don't think there is motivation to try to fit this function in.

 

[mitch672]

It could be easily done but i'm almost out of code space and I'll need to put a lot of conditional statements...The EVSE will be mostly stationary and won't have hardware pieces missing from time to time so i don't think there is motivation to try to fit this function in.

Ok, I did manage to find an example of using an Arduino as an I2C scanner, FYI:
http://todbot.com/blog/2009/11/29/i2cscanner-pde-arduino-as-i2c-bus-scanner/comment-page-1/" onclick="window.open(this.href);return false;

The motivation BTW, is so a single version of OpenEVSE can be distributed, and you can add (for example), the LCD display without having to recompile or having it hang if it's missing and compiled with it.

 

[goldserve]

Okay, I see your point but my motivation has dropped significantly now that I'm done the fun coding part

 

[GlennD]

There is still 2 i2c displays to account for. The original monochrome backpack and the RGB Shield and its variants. The current version must have the proper one selected or it will not run.

Most of the current interest is in the RGB shield and its select switch but it was originally setup for the backpack and a switch off of one of the ports.

 

[garygid]

What is different between the two displays that makes the monochrome
Display not a subset of the RGB display (with Red = Backlight On)?

Do they have the same I2C address?

Is there no way to tell them apart via firmware?

 

[goldserve]

Added a video tour of the new menus for FW version 1.6.0

[youtube]http://www.youtube.com/watch?v=xEW_XIwJIlo[/youtube]

 

[borland]

That's great goldserve! Nice video too.

It looks like your using only one button for setup and timer functions with short and long presses. How hard would it be to have a Setup setting for the Clock and Timer, to allow control timer/clock functions from another button which would be mounted on outside of the NEMA panel?

For a wall mounted OpenEVSE, you would only need to Setup/configure the installation once (e.g., maximum current), then close the box up. For tamper proofing purposes, you wouldn't want the installation setup functions to be accessible from outside.

 

[goldserve]

All the menus can be taken out and you can program the timers from the serial command prompt. You could install a special connector like an audio jack and route serial out of the box. I imagine you would probably not want any of the other disable safety check menus as well.