[Ovmsdev] OVMS Hardware v3.1

Thu Jan 18 08:25:40 HKT 2018

Short answer: RAM (3.0 has 520KB internal, of which about 100KB is usable, and 3.1 adds another 4MB of external RAM while allowing us to claw back some of that missing 400+KB).

Long(er) answer:

If I’d known back then what I know now (that 80% of the 520KB internal RAM would be unavailable to us), perhaps a different decision would have been made. Looking back, OVMS v2 had 3KB RAM. Anyway, we are where we are and a fairly simple switch to WROVER (from WROOM-32) provides a solution to the problem.

The WROVER and WROOM-32 are really very similar; pinouts are identical. The only difference is the addition of the 4MB PSRAM in the module, GPIO 16, GPIO 17, and the change of VDD_SDIO from 3.3v to 1.8v (which has the knock on effect to our external 16MB flash). Module price is even almost the same.

The circuit layout changes 3.0 -> 3.1 are (a) to improve electrical isolation and power on the high speed buses (which should be done anyway), and (b) to cope with the change to 1.8v on VDD_SDIO affecting our external 16MB flash. Change (a) has to be made anyway, and (b) is pretty minimal, but does bring some risk (time).

ESP IDF 2.1 -> 3.x had to happen anyway, for the SDCARD issue as well as for the huge number of bugs Espressif have squished in the past six months (just have a look at the 3.0b1 release notes).

To me, Strider’s comment (on teslamotorsclub.com <http://teslamotorsclub.com/>) this morning sums it up:

Excellent news Mark! Don't rush on our account. I would rather have a bulletproof unit than to have it a few weeks earlier.

I don’t want this project to turn into a Perl 5. Our time aside, I’m particularly aware of all the money, time and effort the China guys are putting into this without any payback until we start manufacturing (they get $0 for design work, but a margin on the production runs). I specifically haven’t run this as a kickstarter project, to avoid taking people’s money and committing to a time pressure to get something/anything out. We need to get it right.

Regarding releasing 3.0 now (everything works on the 3.0 boards we have), vs waiting for 3.1 hardware, to me the points are:

It seems that with the 3.0 hardware there will never be enough RAM to run _everything_ (wifi, bluetooth, cellular, vehicle, etc) at once. It seems that without bluetooth, we can fit in, but as Michael pointed out the other day - fixing sdcard just makes the memory situation tighter. I worry that this will cause end-user issues. There is just not enough safety margin in the RAM.

I don’t think the firmware is production end-user ready anyway. For developers, it is fine. For technical end-users, very close. But for non-technical end-users, we need time to iron out the bugs, and add the ease-of-use stuff. We had this issue with v1 OVMS - it wasn’t ready for non-technical end-users, and support in the early days was a PITA.

The 3.x platform is looking extremely powerful and able to do what we need. In particular, I’m impressed with connectivity and console (all the work Steve did on SSH, and consoles), but also Reverse Engineering CAN bus support, logging, notifications, OBDII HUD, etc. I think this can be a fantastic platform for all sorts of wonderful stuff.

We need to add that extra electrical protection on the high-speed buses anyway, so that needs another prototype board run (just to make sure nothing is messed up). Moving WROOM-32 -> WROVER adds perhaps a week’s delay; provided the prototype doesn’t have any problems, of course.

Maintaining two different hardware bases, for production, is going to be a lot more hassle than one. Developer units are fine - we can flash our own firmware - but support for end-user production units is something else entirely.

Regards, Mark.

> On 18 Jan 2018, at 2:01 AM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> So, I'm not a practicing electrical engineer (though I do know which end of the soldering iron to hold), but I did spend many years in R&D project and program management...  Is there a reason the v3.0 hardware can't go to market?  There are many potential customers who have been waiting patiently for the product, and switching horses at this late date in a traditional development scenario would be extremely unusual.  Historically, such things often turn out badly.  (I have scars...)
> 
> Now, I know (and am grateful) that this isn't a traditional development project, and that has some really big advantages.  The world of modular hardware and development has moved light years forward.  But we do need to deliver something.  3.0 doesn't have to be the last thing we ever do; is it good enough to make a substantial number of potential customers into real customers?  What would they not be getting?  What would the cost be (both monetary and other) to ship 3.0 as it is, and roll to 3.1 relatively soon after 3.0 ships?  For example, to ship 3.0 as is, would we need to build a more complicated fulfillment process to custom-build each delivery, in order to optimize RAM?  What do we lose by shipping 3.0, in terms of our ability to do 3.1?
> 
> Just asking...  We've discussed bits and pieces of the situation, but I wouldn't mind a nice summary.  What really are the options at this point?  
> 
> Greg
> 
> 
> Mark Webb-Johnson wrote:
>> 
>> We hit a snag with the 3.1 hardware design. The flash voltage (VDD_SDIO) in WROVER module is 1.8V. In WROOM-32 module, VDD_SDIO was 3.3V. Also, as previously mentioned, the WROOM-32 modules uses GPIO16 and GPIO17 for external PSRAM (SPI CLK and CS signals). What wasn’t clear was _why_ they chose those pins. It now is…
>> 
>> The ESP32 design is that some pins (GPIO16, GPIO17, FL_DATA_2, FL_DATA_3, FL_CMD, FL_CLK, FL_DATA_0, FL_DATA_1, and of course VDD_SDIO) operate in the VDD_SDIO domain, and the rest operate in the 3V3 domain. So, switching VDD_SDIO to 1.8V (is 3.3V in OVMS v3) also switches those eight GPIOs to 1.8V. Another complication is that VDD_SDIO is not exposed (not a problem for 3.3v, but an issue if we want 1.8v to power the external flash).
>> 
>> I attach spreadsheet with ESP32, WROOM-32, and WROVER pinouts, along with strapping pins used and power domains (3.3V, SDIO/1.8V, etc). I think this makes things much clearer.
>> 
>> The WROVER pins are essentially the same as WROOM-32. No more, no less. But, VDD_SDIO changes from 3.3V to 1.8V.
>> 
>> It seems that the simplest approach is:
>> 
>> Free GPIO4 (SD_DATA1), GPIO12 (SD_DATA2), and GPIO13 (SD_DATA3) and make SDCARD 1-line protocol.
>> Note that GPIO12 is MTDI and is a strapping pin for 1.8V/3.3V, so we’ll try not to use that.
>> GPIO16 and GPIO17 are now used by PSRAM (CS and CLK), and not exposed. So:
>> Move UART 2 (TX to modem) to GPIO13.
>> Move UART 2 (TX from modem) to GPIO4.
>> Leave GPIO16 and GPIO17 unconnected (used internally by WROVER).
>> 
>> That leaves the problem of GPIO22 (FL_CS2) for our external flash. All the other (shared) pins are VDD_SDIO (1.8v), but that pin is in the 3.3v domain, and we need it to drive an external 1.8v flash chip (which is not 3.3v tolerant). From what I can see, there are no free VDD_SDIO domain pins. #17 through #22 are used for SPI flash HSI, and the last two GPIO16 and GPIO17 are used for the PSRAM (and are not exposed outside WROVER so nothing we can do about it anyway).
>> 
>> The only solution we can see is to continue to use GPIO22 for FL_CS2 external flash, but use a level converter 3.3V -> 1.8V. We only need uni-directional, but it must operate fast enough not to interfere with a 40MHz SPI bus. Maybe a resistor voltage divider would be too slow / interfere too much, so safer to use a simple single channel uni-directional 3.3V->1.8V logic level shifter chip. Trying to find a flash chip that is 3.3V tolerant, and test it, would just introduce more delays (for the sake of one extra 9cent component).
>> 
>> Regarding the SDCARD. According to the specs, this is driven at 3.3V and our circuit has this on 3.3V pins, so that should be ok. The only issue is strapping pins GPIO2 and GPIO12. I can’t get this to work with Analog Lamb’s WROOM-32+PSRAM module at all, but it works fine on the Espressif WROVER-KIT I have (in both 1 line and 4 line modes). So we just use the capacitors and pull-up resistors from the WROVER-KIT arrangement, along with our existing GPIO2-GPIO0 link (as per Espressif SDCARD documentation):
>> 
>> The changes to support this now include:
>> 
>> Swap the GPIOs around, as above (freeing some pins from moving SDCARD 4-line to 1-line, and staying clear of the nasty GPIO12).
>> Add a new small 3.3v->1.8v regulator, to power just our 16MB external flash chip (and level converter).
>> Add a new unidirectional 3.3v->1.8 level converter for CS line of 16MB external flash.
>> Switch external 16MB flash to a 1.8v component.
>> Add a few capacitors on the power lines near external flash and SD CARD, to help with peak power draws.
>> Re-work SD CARD pull-ups and protection circuitry (as per latest Espressif WROVER-KIT design).
>> Minimising length of SPI and SD bus lines, and keeping them away from sources of interference (where possible).
>> Increasing size of solder pad for USB connector, and large capacitors, to make stronger.
>> 
>> I’m triple checking this tonight (as it goes to make boards tomorrow). I would appreciate any feedback from electrical engineers on this list.
>> 
>> Regards, Mark.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>> Subject: [Ovmsdev] OVMS Hardware v3.1
>>> Date: 10 January 2018 at 2:41:58 PM HKT
>>> To: OVMS Developers <OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>>
>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk <mailto:ovmsdev at lists.teslaclub.hk>>
>>> 
>>> 
>>> Production…
>>> 
>>> Analog Lamb, while interesting, is just (a) too expensive (double the price), (b) unproven, (c) uncertified, and (d) has long lead times. Using proven Espressif certified modules seems the safer way to go.
>>> 
>>> So, we’ve decided to go with a switch to a standard certified ESP WROVER module, and external 16MB flash memory. The circuit board footprint for this is a little larger than the WROOM-32 module we’ve been using, and requires one more 3.3V->1.8V power conversion, but seems the safest way to go.
>>> 
>>> Accordingly, I’ve agreed with the China guys to proceed along these lines for the main board:
>>> 
>>> Change WROOM-32 to WROVER (on circuit antenna version, similar to WROOM-32).
>>> 
>>> We can free IO12 (SD_D2), IO13 (SD_D3), and IO4 (SD_D1), by using just 1-line SDCARD. I don’t really want to use IO12 as that is a bootstrapping pin.
>>> 
>>> WROVER PSRAM uses IO16 and IO17, so we can’t use that for modem.
>>> Move modem to IO4 and IO13.
>>> 
>>> Change to 1.8V 16MB flash chip (W25Q128FW?). As SDD_VDIO is not exposed, add a simple regulator 3.3V->1.8V for external flash?
>>> 
>>> When burning e-fuses, need to take care with 1.8V/3.3V SDD_SDIO fuse - leave at 1.8V.
>>> 
>>> Add capacitors for SD CARD and external Flash, as per Espressif example.
>>> 
>>> Increase size of solder pad for big capacitors, and USB connector, to make it stronger.
>>> 
>>> For the data lines of circuit traces SDCARD, SPI bus, external flash, take care to keep away from power traces or other sources of interference and keep the traces as short as possible.
>>> 
>>> The change to WROVER is a PITA at this stage, but that 4MB PSRAM should give us more headroom and the extra bill-of-materials costs is just a couple of US$.
>>> 
>>> For the modem, we’re double-checking the power (which seems ok, but check to be sure), and changing passive -> active antenna. At the moment, it seems to be just a couple of passive components soldered inline between two easily accessible points. For existing developer modems in the field, we’ll try to make a simple upgrade kit (passive->active) for GPS, and post them out. If you don’t need GPS (such as Roadster users), the modem boards are functionally the same as the production ones.
>>> 
>> 
>> 
>>> 
>>> Existing developer OVMS v3 boards (with WROOM-32 module) will continue to be called v3.0. New production OVMS v3 boards (with WROVER module) will be called v3.1. We have conditional compilation in the firmware, to switch the pin assignments and whatever else is required.
>>> 
>>>  Branch: refs/heads/for-v3.0
>>>  Home:   https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3>
>>>  Commit: 9504df70be78b6626970ec0ea53d2c2470e90afa
>>>      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa>
>>>  Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>  Date:   2018-01-10 (Wed, 10 Jan 2018)
>>> 
>>>  Changed paths:
>>>    M vehicle/OVMS.V3/main/Kconfig
>>>    M vehicle/OVMS.V3/main/ovms_peripherals.h
>>> 
>>>  Log Message:
>>>  -----------
>>>  Support for OVMS hardware v3.1
>>> 
>>> Converting developer v3.0 boards to v3.1 is not really feasible (a skilled solderer could probably use a 16MB Analog Lamb WROOM-32+PSRAM module; that would be a relatively simple de-solder + re-solder of the module, a not-so-simple re-arrange of the traces for IO16->IO4 and IO17->IO13, and disabling of external 16MB flash). Anyway, those existing developer modules should be fine to continue to use (just without the extra PSRAM).
>>> 
>>> We are today finalising the circuit schematic and board layout for the above, and building a couple of test boards (with WROVER modules). I should have one in about a week’s time (assuming all the components are available). In that time, we’ll finish the ESP IDF v3.0 support, and test late next week / over next weekend (20th/21st Jan). Assuming no problems, we should be able to give factory the go-ahead to produce early the week after.
>>> 
>>> Given that timing, I doubt if we are going to be able to get these boards made before the Chinese New Year holidays. Even if we can get them made, FastTech distribution may not be able to get them out during the holidays. Manufacturing in China starts to close down around the end of January / early February this year. New Year itself is mid-February. Anyway, we’ll get this all finalised, payment and instruction to start manufacturing in place, then do the best we can and get these out available during February. A big warning is going to go with them that this is for early adopters only, and firmware is changing on a daily basis. Updating firmware via wifi / sd card should be fine.
>>> 
>>> I’m seeing a light at the end of a long dark tunnel.
>>> 
>>> Regards, Mark.
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>> Begin forwarded message:
>>> 
>>> From: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>> Subject: OVMS Hardware v3.1
>>> Date: 10 January 2018 at 2:41:58 PM HKT
>>> To: OVMS Developers <OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>>
>>> 
>>> 
>>> Production…
>>> 
>>> Analog Lamb, while interesting, is just (a) too expensive (double the price), (b) unproven, (c) uncertified, and (d) has long lead times. Using proven Espressif certified modules seems the safer way to go.
>>> 
>>> So, we’ve decided to go with a switch to a standard certified ESP WROVER module, and external 16MB flash memory. The circuit board footprint for this is a little larger than the WROOM-32 module we’ve been using, and requires one more 3.3V->1.8V power conversion, but seems the safest way to go.
>>> 
>>> Accordingly, I’ve agreed with the China guys to proceed along these lines for the main board:
>>> 
>>> Change WROOM-32 to WROVER (on circuit antenna version, similar to WROOM-32).
>>> 
>>> We can free IO12 (SD_D2), IO13 (SD_D3), and IO4 (SD_D1), by using just 1-line SDCARD. I don’t really want to use IO12 as that is a bootstrapping pin.
>>> 
>>> WROVER PSRAM uses IO16 and IO17, so we can’t use that for modem.
>>> Move modem to IO4 and IO13.
>>> 
>>> Change to 1.8V 16MB flash chip (W25Q128FW?). As SDD_VDIO is not exposed, add a simple regulator 3.3V->1.8V for external flash?
>>> 
>>> When burning e-fuses, need to take care with 1.8V/3.3V SDD_SDIO fuse - leave at 1.8V.
>>> 
>>> Add capacitors for SD CARD and external Flash, as per Espressif example.
>>> 
>>> Increase size of solder pad for big capacitors, and USB connector, to make it stronger.
>>> 
>>> For the data lines of circuit traces SDCARD, SPI bus, external flash, take care to keep away from power traces or other sources of interference and keep the traces as short as possible.
>>> 
>>> The change to WROVER is a PITA at this stage, but that 4MB PSRAM should give us more headroom and the extra bill-of-materials costs is just a couple of US$.
>>> 
>>> For the modem, we’re double-checking the power (which seems ok, but check to be sure), and changing passive -> active antenna. At the moment, it seems to be just a couple of passive components soldered inline between two easily accessible points. For existing developer modems in the field, we’ll try to make a simple upgrade kit (passive->active) for GPS, and post them out. If you don’t need GPS (such as Roadster users), the modem boards are functionally the same as the production ones.
>>> 
>> 
>> 
>>> 
>>> Existing developer OVMS v3 boards (with WROOM-32 module) will continue to be called v3.0. New production OVMS v3 boards (with WROVER module) will be called v3.1. We have conditional compilation in the firmware, to switch the pin assignments and whatever else is required.
>>> 
>>>  Branch: refs/heads/for-v3.0
>>>  Home:   https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3>
>>>  Commit: 9504df70be78b6626970ec0ea53d2c2470e90afa
>>>      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa>
>>>  Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>  Date:   2018-01-10 (Wed, 10 Jan 2018)
>>> 
>>>  Changed paths:
>>>    M vehicle/OVMS.V3/main/Kconfig
>>>    M vehicle/OVMS.V3/main/ovms_peripherals.h
>>> 
>>>  Log Message:
>>>  -----------
>>>  Support for OVMS hardware v3.1
>>> 
>>> Converting developer v3.0 boards to v3.1 is not really feasible (a skilled solderer could probably use a 16MB Analog Lamb WROOM-32+PSRAM module; that would be a relatively simple de-solder + re-solder of the module, a not-so-simple re-arrange of the traces for IO16->IO4 and IO17->IO13, and disabling of external 16MB flash). Anyway, those existing developer modules should be fine to continue to use (just without the extra PSRAM).
>>> 
>>> We are today finalising the circuit schematic and board layout for the above, and building a couple of test boards (with WROVER modules). I should have one in about a week’s time (assuming all the components are available). In that time, we’ll finish the ESP IDF v3.0 support, and test late next week / over next weekend (20th/21st Jan). Assuming no problems, we should be able to give factory the go-ahead to produce early the week after.
>>> 
>>> Given that timing, I doubt if we are going to be able to get these boards made before the Chinese New Year holidays. Even if we can get them made, FastTech distribution may not be able to get them out during the holidays. Manufacturing in China starts to close down around the end of January / early February this year. New Year itself is mid-February. Anyway, we’ll get this all finalised, payment and instruction to start manufacturing in place, then do the best we can and get these out available during February. A big warning is going to go with them that this is for early adopters only, and firmware is changing on a daily basis. Updating firmware via wifi / sd card should be fine.
>>> 
>>> I’m seeing a light at the end of a long dark tunnel.
>>> 
>>> Regards, Mark.
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180118/caa8820a/attachment.htm>