Higher level spi

[manuelbl]

As I've seen the pull request related to SPI initialization, I'd like to propose another change to the SPI hardware abstraction layer. Instead of the low-level API:

void hal_pin_nss (u1_t val);
u1_t hal_spi (u1_t outval);

introduce a higher-level API:

void hal_spi_write(u1_t cmd, const u1_t* buf, int len);
void hal_spi_read(u1_t cmd, u1_t* buf, int len);

The new API simplifies the code as the start and end of the SPI transactions are obvious and don't need to be indirectly derived from the NSS level. My TTN library for ESP-IDF would also profit as the ESP-IDF API for SPI is designed around entire SPI transactions.

Another benefit is that the code size of the new implementation decreases on all processors that I have tested (slightly at the expense of code readability). The RAM size stays exactly the same.

I cannot judge if there are many alternative HALs that this change will certainly break. If that's the case, feel free to reject the pull request.

[terrillmoore]

Sorry, I've been very busy on another project. This seems like a reasonable idea, however we also need to initialize the HAL (thereby driving NSS inactive). This is issue #38 -- otherwise NSS drifts active, and the RFM95W responds to (interferes with) other devices on the bus. Anyway, I'll try to review this weekend.

[terrillmoore]

@sjpark-mcci @svelmurugan92 (and others who have platforms that can run a quick test -- we need horizontal coverage) -- can we arrange to test this with the SAMD and STM32 ports? To check out this branch, you need to invent a local branch name, e.g. issue158 that doesn't exist yet in your repo. Then:

$ git checkout master # get to the main branch
$ git pull  # get all recent changes on master
$ git fetch origin pull/158/head:issue158  # get the changes for this pull to local branch issue158
$ git checkout issue158  # checkout the branch for the pull request.

Then build and make sure that TX and RX are working? Thanks!

[manuelbl]

FYI: I've tested it with a ESP32 device and a blue pill (STM32F103).

[terrillmoore]

Great. Just need to test on SAMD and (I hope) AVR, and we can accept it. MCCI will test on SAMD and STM32L0, but we have to get a volunteer to test on AVR.

[manuelbl]

I've successfully tested it with an Arduino Pro mini clone (OTAA, TX, RX).

[svelmurugan92]

@terrillmoore We have tested on SAMD and STM32.
Results looks fine.

[terrillmoore]

@manuelbl OK. This is a potentially-breaking change, so we'll need to bump the version to V3. As it happens, for TCXO support #95 , I'm making enough changes that it's got to be V3 anyway (even though I don't think it's breaking, there are enough differences that it makes sense to go to V3). Will process this this week.

[cyberman54]

May i ask on status of this pr? Could really need it.

[terrillmoore]

@cyberman54 It's close to top of my list. We have a couple of new boards that need the fixes from #95, and it's been tedious digging through all various layers. I may be able to get to it today. Sorry for the delay.

[terrillmoore]

@manuelbl I'm going to touch this up a bit and commit it.