I read in these forums, that using the Arduino libraries with the H7 will incur some speed penalties. Is there any documentation on what these delays may be? For example I2C use, GPIO use etc.
Any time you use a library it will "cause a delay" That is because it takes time for the Arduino to process each instruction the same time as in your code for the same instruction. If you are worried open the library and look at the .cpp and .h files, maybe you could speed them up. If you see a delay() in the library be sure you understand why it is there, changing or removing it can cause unexpected results. A lot has to do with the ease of accessing. GPIOs actually require register manipulation but it is hidden behind a C++ statement such as digitalWrite(). You as a programmer have a choice to make and it is also a speed tradeoff.
You probably missed the complete context of the discussions you mentioned (or it was absent). When you use the STM core, it utilizes the STM Hardware Abstraction Layer (HAL). This does a wonderful job of supporting the huge range of processors, but in many cases it adds overhead. If you know what you are doing, you can use the LL (low level) STM interface which is often more efficient but not as full featured as the HAL.
But, the H7 is so fast compared with a processor like the 328, at least, that it may outperform it in spite of the software layering. I'm not sure if the Portenta core uses the HAL, it seems to me very likely since that is how a lot of native STM applications are built. It would be an incredibly tedious job to write a core for that processor without it.
In fact, this has nothing specific to do with the libraries, it's also true for any compiled sketches. Realistically, the best way to find out the answer to your question, is to dig into the library and core code.
1 Like
My five cents:
The speed is not affected if and how many libaries you use. It is the code itself called.
The Portenta H7 runs just with 400 MHz (not with 480 MHz as spec. allows).
The more code you call from library - the slower.
Some code from LIB, e.g. initializing a device/peripheral has a lot of "timeouts" in it: it tries to wait for something, e.g. a device ready. Or, after configuring a register - it has to wait a bit. This slows down the startup (setup()) a lot.
If you cannot external HW, e.g. an I2C device, and the API code waits for this external chip to respond (e.g. with a device/chip ID) - it consumes a lot of time.
The LIB creates just code size (in your flash image), but not runtime overhead (if a function is not called, even the function is part of your code).
Some functions used from LIB (e.g. for me the ETH and network stuff) are not designed for "real-time" (fastest speed). They might use a lot of memcpy() functions to move data. This slows down.
Also, if you use Portenta H7 (a CM7 system) and one of the memories is "not-cacheable" (MPU config) - the performance is slow.
I saw also code in API where all is based on character-wise handling (instead of handling chunks of data - the API code copies all as single bytes). The called API functions determine the performance, not the fact itself if a LIB is used (during compile time bounded to your code).
It is the code in the LIB, not the LIB itself.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.