Hello everyone!
I've been adapting a sketch from an AVR chip to Tensilica LX6 (In specific, AtMega328P -> ESP32)
Along with previously nonexistent errors that were easy enough to fix (like "cannot convert const char* to char*", which was solved by a cast [I read somewhere this was unpredictable but acceptable, and I don't know any other way to fix it]), I received some errors that were FAR beyond my scope of knowledge:
C:\Users\Eric\Documents\Arduino\libraries\PDQ_ST7735/PDQ_ST7735.h:348:34: error: '_SFR_IO_ADDR' was not declared in this scope
: [spi] "i" (_SFR_IO_ADDR(SPDR)), [lo] "r" ((uint8_t)data), [hi] "r" ((uint8_t)(data>>8))
There are a bunch more, all with similar if not identical errors in different parts of the file.
This is from the PDQ GFX library, a much improved version of Adafruit's GFX library.
The locations of interest are all assembly (if AVR assembly would even work on another architecture is another question). The problem that's occurring is that these macros, like _SFR_IO_ADDR, are not defined for this board.
How can I fix this? Manual values? If so, where can I get these values?
Thanks!
The ESP core doesn't to do the stupid stuff the Arduino team did in their core library in the digital i/o routines.
So digitalWrite()/digitalRead() on the ESP core will be very fast. Not to mention that the part itself is running MUCH faster.
This is why you can't use naked constants on the ESP core.
i.e. digitalWrite(D10, HIGH) is not the same as digitalWrite(10, HIGH)
So I would not bother to mess with all the crap and hoops you have to jump through to try to make the poorly designed digital i/o routines run fast on AVR. ARM cores have similar issues given the way the Arduino team did their code and API. The API semantics itself create lots of problems but that came from Wiring.
Most of what has to be done to try speed up the Arduino digital i/o routines on AVR (and ARM) is simply is not necessary on the ESP core. The ESP developers know what they are doing and have a much better understanding of how to make things efficient so their implementation does not suffer from the crazy overhead that the team Arduino cores suffer from.
In other words, if you go to all the trouble to implement the indirect port i/o that is being done in this library you are likely to not see any benefit over just using the digital i/o routines directly on the ESP core.
In fact, there are some situations where it can actually be slower.
Not to mention that some operations supported by the above libraries i/o primitives (like writing value to all the bits in a register) are simply not possible do to the different way the registers work.
ESP uses a single 32 bit register for all the pins. AVR uses multiple 8 bit registers.
The AVR also suffers from some h/w design issues that create many issues for s/w when trying to set or clear bits in an atomic way.
When it comes to graphic libraries, often the way to improve performance is to do things smarter at higher level rather than to try to speed up the lower level i/o operations down at the metal layer.
In graphic code there can be cases of the higher level code not being very smart about how it handles the drawing or pixel manipulation which causes lots of lower level calls.
So yes, while speeding up the low level code will make things faster, in this type of situation the real answer is to fix the high level code to be smarter and to do less low level i/o calls.
But so often, people (code authors) don't take the time really understand the system as a whole and to figure how to optimize the overall system. They often just start jumping in and start trying to make this individual routines faster.
In this case, I'd recommend first getting the code working with a portable mode and see if it is fast enough.
If not, then get out your tools including things like a logic analyzer and start profiling the code to look at where the real overheads are and dig in to fully understand all the code and its interactions.
Often times there can be surprising where the real overheads are.
I have used this technique for many decades when trying to determine where latencies and overheads are.
The technique is the same, regardless of whether the code is application code, graphic code, or even kernel code.
I've figured out some problems (for instance the ESP32 chipset was not defined, but the ESP8266 was, so I just treated it as though it was a 8266 chip).
It compiles, but I have not tested it (i don't have the chip itself yet...).
Thanks again for your in-depth explanation. This will be handy to know in the future
