KurtE
Senior Member+
I have been playing around with some of the core libraries and either have outstanding Pull requests are potentially soon will generate additional Pull requests. Wondering about what people thought and or if anyone would like to test out some of these, such that maybe we can get some of them into a beta release when hopefully Paul is not under the gun to get a new release out as to match a new Arduino IDE...
Some of the changes include:
SPI: SPI.transfer(buf, cnt) - goes a lot faster as it keeps the queue full using 16 bit writes... Currently this is PR: #23
Wondering if it would make sense to maybe create some new versions of transfer methods that maybe allow you to make use of the hardware CS pins without having to know about PUSHR?
Also wondering if it also would make sense to merge (or migrate) some of the functionality in ILI9341_t3 library into may SPI? I did so with my SPIN C++ classes, so had versions of the wait for fifo not full, wait for fill empty... Also in SPIN is functions like: is this pin a MISO pin, or MOSI or SCLK, like the CS pins. That way in theory when new boards are introduced you just need to update in the main library. Also if your code can then be adapted to something like SPIN where you pass in which buss to use, the underlying library takes care of knowing which pins are valid.
ILI9341_t3: - Merge in some of the things from my ILI9341_t3n library - Have not issued PR yet, code changes up at: https://github.com/KurtE/ILI9341_t3/tree/Merge-Bounds-offsets-_T3N
Changes include:
Some of the changes done be blackketter in PR13 - Clip Rectangle, and setting drawing offsets
Draw Opaque Font characters - I re-implemented this to work like Opaque system font draw
Can still function with only one hardware CS pin (must be DC).
Also can function if MISO is not valid - but read functions will fail...
What I did not merge in from my ILI9341_t3n library includes: my ability to turn on a logical frame buffer on T3.5/6 (Note: I am not using the DMA stuff here). Also did not merge in my ability to work on different SPI busses, as this uses my SPIN library, which is not part of the normal system.
Wire: I have a version of Wire library, which again I have not done a PR on. I actually have 2 versions more in a second. But the later version is up at:
https://github.com/KurtE/Wire/tree/SUpport-Wire123-Malloc
These versions created a base class for Wire and I created subclasses for Wire0 (Wire), Wire1, Wire2, Wire3. I mentioned above 2 versions. The first version, simply created the objects with all of the data. But as each of these have default 2*32 byte queues, each was eating up something like 80+ bytes. So when T3.2 and TLC have two of these, was eating up 160+ bytes, 240 on T3.5 and 320 on T3.6. So second version, put most of the data into a structure that only gets allocated if you call certain apes, like begin. Obviously if you are using a TLC and you do a begin on both Wire and Wire1, it will use that amount of memory, but that is as expected... But if you only use one of them you are only paying the price for one of them...
The Wire library still needs some testing before I issue a PR. Will explain more about what I have done in the next posting.
Thoughts?
Some of the changes include:
SPI: SPI.transfer(buf, cnt) - goes a lot faster as it keeps the queue full using 16 bit writes... Currently this is PR: #23
Wondering if it would make sense to maybe create some new versions of transfer methods that maybe allow you to make use of the hardware CS pins without having to know about PUSHR?
Also wondering if it also would make sense to merge (or migrate) some of the functionality in ILI9341_t3 library into may SPI? I did so with my SPIN C++ classes, so had versions of the wait for fifo not full, wait for fill empty... Also in SPIN is functions like: is this pin a MISO pin, or MOSI or SCLK, like the CS pins. That way in theory when new boards are introduced you just need to update in the main library. Also if your code can then be adapted to something like SPIN where you pass in which buss to use, the underlying library takes care of knowing which pins are valid.
ILI9341_t3: - Merge in some of the things from my ILI9341_t3n library - Have not issued PR yet, code changes up at: https://github.com/KurtE/ILI9341_t3/tree/Merge-Bounds-offsets-_T3N
Changes include:
Some of the changes done be blackketter in PR13 - Clip Rectangle, and setting drawing offsets
Draw Opaque Font characters - I re-implemented this to work like Opaque system font draw
Can still function with only one hardware CS pin (must be DC).
Also can function if MISO is not valid - but read functions will fail...
What I did not merge in from my ILI9341_t3n library includes: my ability to turn on a logical frame buffer on T3.5/6 (Note: I am not using the DMA stuff here). Also did not merge in my ability to work on different SPI busses, as this uses my SPIN library, which is not part of the normal system.
Wire: I have a version of Wire library, which again I have not done a PR on. I actually have 2 versions more in a second. But the later version is up at:
https://github.com/KurtE/Wire/tree/SUpport-Wire123-Malloc
These versions created a base class for Wire and I created subclasses for Wire0 (Wire), Wire1, Wire2, Wire3. I mentioned above 2 versions. The first version, simply created the objects with all of the data. But as each of these have default 2*32 byte queues, each was eating up something like 80+ bytes. So when T3.2 and TLC have two of these, was eating up 160+ bytes, 240 on T3.5 and 320 on T3.6. So second version, put most of the data into a structure that only gets allocated if you call certain apes, like begin. Obviously if you are using a TLC and you do a begin on both Wire and Wire1, it will use that amount of memory, but that is as expected... But if you only use one of them you are only paying the price for one of them...
The Wire library still needs some testing before I issue a PR. Will explain more about what I have done in the next posting.
Thoughts?