So I’ve been working on trying to get u8glib working on my Spark Photon (spoiler: I have it working right driving two displays simultaneously).
I opted to access the HAL functions directly for GPIOs, SPI, and delays. This raises two questions:
Should I be calling the HAL? One thing I like about it is that it works with C and C++ (some of the firmware API is C++ only). Also, using SPI it allows me to define my own CS (SS) pins so I can drive multiple devices from the same HW SPI and even frees up the SS analog pin if I choose not to use that.
Is there a reference for the HAL? I’ve been guessing what things do so far from their usage in wiring & etc, but it’s not always clear what is and isn’t a strict necessity.
Sauce
p.s. any victim… errr… volunteer… want to try out my u8glib when it’s a bit cleaned up?
@Sauce, all of the HAL functions are reflected in higher level functions. When you say it allows you to define your own CS for SPI, this can be done already with SPI.begin(CS). The new low-level I/O functions allow super-fast bit-wise I/O. So, to your question regarding being encouraged, well the entire code is open source so go at it!! Is it good practice? Perhaps not but that may be debatable. I would say look carefully at the documentation before you decide to go down into the HAL.
There’s still the C+±ness vs C-ness of the two different APIs that I’ll have to think about. With respect to u8glib, almost all of it is written in C with the exception of the arduino-like wrapper U8GLIB.{cpp,h}. This would be the only platform that doesn’t follow that rule.
On the subject of looking at the documentation carefully, maybe you should SPI.begin(CS) doesn’t appear to be there!
SPI.begin(CS) doesn’t appear to be there!