[Ovmsdev] SD CARD vs 16MB flash

Mark Webb-Johnson mark at webb-johnson.net
Tue Jan 9 08:57:42 HKT 2018

>> 4. Change to use Analog Lamb WROOM-32 module and their 16MB flash + 4MB ram.
> Would it be feasible to add our own SPIRAM chip to use with the WROOM
> module?

Unfortunately, the only SPIRAM chips supported are the ESP-PSRAM32 and IS25WP032; those are1.8V devices, but the Espressif standard WROOM-32 module uses 3.3V flash. Can’t combine the two as they are on the same SPI bus.

There is an Espressif WROVER module (the one with 4MB flash and 4MB SPIRAM) that is a 1.8V device. It has a slightly bigger footprint than the WROOM-32, but should still fit. We could change to that, and switch to use an external 1.8V 16MB flash - minimal changes to our design.

I suspect it will come down to a choice between WROVER + external 1.8V flash (similar to our current design), and Analog Lamb WROOM-32 (16MB flash + 4MB SPIRAM) with no external flash. The Analog Lamb choice has a long lead time and is very pricey, but is a simpler drop-in replacement. I’m a little wary of Analog Lamb - unknown entity, the sample modules we bought came with old Rev0 ESP32 chips (not good), long lead times, unknown certification status, etc.

That said, here is OVMS v3 running on an Analog Lamb WROOM-32 with 8MB flash and 4MB SPIRAM:

I (30) boot: ESP-IDF v3.1-dev-168-ga1b59679 2nd stage bootloader
I (31) boot: compile time 08:29:22
I (44) boot: Enabling RNG early entropy source...
I (44) boot: SPI Speed      : 40MHz
I (44) boot: SPI Mode       : DIO
I (47) boot: SPI Flash Size : 8MB
I (489) spiram: SPI RAM mode: flash 40m sram 40m
I (493) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (1350) spiram: SPI SRAM memory test OK
I (1350) heap_init: Initializing. RAM available for dynamic allocation:
I (1350) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (1357) heap_init: At 3FFCC7F8 len 00013808 (78 KiB): DRAM
I (1363) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1369) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1376) heap_init: At 4009B618 len 000049E8 (18 KiB): IRAM
I (1382) cpu_start: Pro cpu start user code
I (1387) spiram: Adding pool of 4096K of external SPI memory to heap allocator
I (1395) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console
OVMS > metric list m.
m.freeram                                4276328
m.hardware                               OVMS WIFI BLE BT cores=2 rev=ESP32/0

There is an option to simply add the SPIRAM to the malloc pool, and to move as much of Wifi and LWIP to SPIRAM as possible. It would take some work to get it all going, but that extra 4MB gives us a huge amount of breathing room.

Regards, Mark.

> On 9 Jan 2018, at 12:57 AM, Stephen Casner <casner at acm.org> wrote:
> On Mon, 8 Jan 2018, Mark Webb-Johnson wrote:
>> Now finalising hardware with the china manufacturer. I think at this point, it is
>> worth:
>> 1. Use 1 line SD CARD (which frees up GPIOs SD_DATA1/SD_DATA2/SD_DATA3, but also
>>    avoids the conflict between GPIO12/SD_DATA2 and VDD_SDIO bootstrap pin).
> I just go with the flow on this one.
>> 2. Add some capacitors for power line smoothing, as per Espressif’s example in their
>>    test board.
> Always a good idea.
>> 3. Double-check power on SIMCOM module, to ensure it is as expected (following issues
>>    reported with low-amperage USB ports).
> As I've been testing with release/v3.0 of esp-idf, I had to disable
> the brownout trap entirely.  Even the lowest configured voltage would
> trap repeatedly.  This is with a powered hub (SIIG brand, I think
> decent quality).  Sometimes it seemed I could get by this by flashing
> again, but when it was happening it would repeat with every reset.
>> 4. Change to use Analog Lamb WROOM-32 module and their 16MB flash + 4MB ram.
> Would it be feasible to add our own SPIRAM chip to use with the WROOM
> module?
>                                                        -- Steve_______________________________________________
> 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/20180109/8abb8cf2/attachment.htm>

More information about the OvmsDev mailing list