Mark, Micheal,

Thanks for both your responses.

I was not using the "-j4" and i had the virus scanner going berserk in the back ground. I am now getting times that are in the ball park.

I looked at Fabrizio's thread. I very much applaud his efforts. I am not yet in a state where i can start porting code yet. Still trying to understand everything thats going on in the modules.

Here is what i am trying to do:

I want to re-purpose the project for use in a high-end ebike.

The major changes that i am exploring are:

Add 1 or 2 serial interfaces.
Add a display/ dashboard /odometer to the system. This means there will be another data consumer. (thinking of equipping a display with can functionality)
In order to work around the lack of io pins on the esp32, i was thinking to replace the 2 MP2515's, the MAX7317 by a sinlge STM32F1xx chip (or higher level model) . Inside the STM i can implement dual CAn, dual UART and use the rest of the pins as GPIO. Interfacing between the esp32 and the stm will still go though the SPI. If I implement the same register structures as the dedicated IC's in the STM code, the software changes should be oversee-able.
There are 3 concerns that i have:

The latency of handling the CAN busses is probably going to increase. Hard to say by how much at this stage. It might be minimal. The STM has dedicated CAN protocol functionality like the MP2515's. Its the glue code that bridges between SPI and CAN that i am worried about.
Congestion of the SPI bus: In the scenario where one of the CAN busses has a display on it and one of the UARTs is connected to a BMS or MotorController. There will be major data flows in 2 directions on the SPI.
Even if i keep the code in the STM as dumb and transparent as possible, there still is the need to update it in the field. This means i need 1-2 more sections in the ESP flash for OTA -ing the stm plus the software functionality to perform an OTA of the STM from the ESP.

What are you guys' thoughts about this. Is this feasible or am i crazy 🙂?

Thanks,

Eddy

Eddy,

note that Fabrizio works on porting the OVMS to ESP-IDF 4:

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263#issuecomment-606132473

Maybe you can join forces?

Regards,
Michael

Am 08.04.20 um 04:05 schrieb Mark Webb-Johnson:

Am I correct to assume that the 16Mb of memory is on the module now?

The ESP32 chip uses an external flash chip. The WROOM/WROVER modules include a flash chip in the modules.

In the very early days of development prototypes for OVMS v3, we used an external 16MB flash chip (as only 4MB WROOM modules were available at the time).

For production, we switched to 16MB WROVER modules, so don’t require any external flash chip any more.

How are the core developers dealing with this slowness?

I don’t find it slow at all (but I use MAC and LINUX for development). Most of the time, it is an incremental build (only building changes code, and then a linking step) - it normally takes longer to flash the chip than build the code. I timed a full ‘make clean; make -j 4’ to see what it is for me:

$ time make -j 4

...

real 2m53.557s

user 5m55.978s

sys 1m40.391s

Just under 3 minutes real time. Perhaps you can check in windows to see how much worse it is?

Is it at all possible, if i could force platformio to use the correct the idf-esp libraries, to compile the OVMS code in a more recent environment that uses cmake and ninja?

I haven’t tried it myself. We do have some make scripts in various components that may rely on the existing build system. Things like the versioning.

OVMS was written when ESP-IDF was quite new, and unpolished. At some point, we will most likely migrate to a newer build system, as ESP-IDF matures.

Regards, Mark.

On 8 Apr 2020, at 8:37 AM, Eddy Vromen <eddy_vromen@hotmail.com> wrote:

HI All,

I have a question about the flash memory of the ESP32.

I read that the ESP32 uses 16Mb of external flash memory and in the schematics on page 27 there is a flash memory chip. However, in the latest v3.2 schematics there is no external flash chip.

Am I correct to assume that the 16Mb of memory is on the module now?

How does this impact the e-fuse settings?

Another question that came up while setting up a development environment:

The version of esp-idf thats used by the OVSM project uses the Mingw32 environment. Based on my limited exposure to using this environment, its very slow compared to compiling esp-idf code under e.g. platformio under VSCode.

How are the core developers dealing with this slowness?

Is it at all possible, if i could force platformio to use the correct the idf-esp libraries, to compile the OVMS code in a more recent environment that uses cmake and ninja?

Thanks,

Eddy

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26