implement yield() null function

[ladyada]

for code compat!
can do nothing but example code is littered with yield() for esp8266 compatibility. yield exists in classic arduino, too :)

[igrr]

It may make sense to let yield actually call vPortYield.

[me-no-dev]

hm... I thought I already added that... could have missed it :) will add it in a few

[ladyada]

awesome thank you for all these really fast fixes - its making it really easy to port code & test it!

[me-no-dev]

sure thing! let me know if you hit any other problem :) Do not know if you use PWM yet, but you can take a look at sigmaDelta and LEDC drivers in esp32-hal-*.h Since there is a separate PWM hardware that we do not have a driver for yet (it is much like AVR PWM), I opted not to implement analogWrite yet and instead give access to the available drivers through their own functions. I watched your video from Sunday and would like to give you a hand with the LCD driver if you want :)

[ladyada]

haven't checked out pwm or analog write/read yet. i did get all the TFT/LCD drivers working but they work about 10x faster with bitbang than native SPI due to the mutex. which is totally ok but unexpected for most people. i could deeply optimize the libs but i like the current simplicity....

[me-no-dev]

If more tailor-made api is used for ESP32, then we can mutex once per call. Another option is to expose methods for manual locking and and then skip mutex if already locked externally. I will look through your lib to see what can be done, but I can tell you that I have it here running at over 60FPS (all one of the cores does) so things can be made better for sure

[me-no-dev]

Just to note, if bit-bang is used, there is nothing to prevent a user to concurrently trying to update the display from another thread/core. While I realize that Arduino users are not used to using threads, many will actually love the idea and we will see a slew of problems if we do not lock the hardware properly

[ladyada]

not surprising 60 FPS is possible with blitting the entire display. its tougher when you have to update only a few pixels at a time. ill look making drawpixel/fillrect use only one SPI transaction or maybe have special ESP32 code