Most recent activity
-
@allObjects, my 'random comment' was tongue in cheek since I'm referring to the boards with nRF52832, which does have 3 hardware SPI Master ports and 3 hardware SPI Slave ports (via 3 shared resources), and I'm using those 3 hardware ports on my MDBT42Q board, it's not so random after all.
It is true that boards that are fabricated without any additional GPIO pins, the availability of extra SPI ports is meaningless. But Pixl, MDBT42Q, and nRF52 Thingy, to name a few, are all capable of simultaneously supporting multiple hardware SPI ports.
-
I like the tool. Good idea and effort! This will be very useful for tailoring the firmware to individual needs, optimizing the build to fit those needs.
What if I want to make a 'non-standard' board out of a standard one, eg, use MDBT42Q to make one that supports 3 SPI instead of just one (to take a random example ;-)
Can we have a tab where the basic capabilities (eg number of SPI) can be selected?I like the menu pick and choose style (although I haven't tried to build one yet) and add your own extension. Can you replace modules with your own (eg jshardware.c)?
Also, requiring a .md file with each submission (maybe could be deferred) would go a long way toward having extensions used by someone other than original author...
(note: I had posted this on a different thread, but realized that it really belonged here..."
-
Also, requiring a .md file with each submission (maybe could be deferred) would go a long way toward having extensions used by someone other than original author...
-
These extensions are only for standard boards? What if I want to make a 'non-standard' board out of a standard one, eg, use MDBT42Q to make one that supports 3 SPI instead of just one (to take a random example ;-)
Can we have a tab where the basic capabilities (eg number of SPI) can be selected?I like the menu pick and choose style (although I haven't tried to build one yet) and add your own extension. Can you replace modules with your own (eg jshardware.c)?
-
Do you know if those separate 255 byte transfers can be chained such that there isn't a pause in the SPI clock? I guess that might screw up the idea of using it as a general purpose neopixel driver.
It turns out I was somewhat incorrect on maximum number of bits you can transfer. There is a maximum of 255 bytes per SPI transaction, but, with EasyDMA operating in 'ArrayList' mode, the SPI transaction will be repeated (from the next contiguous address) without a 'pause'. Since the TX and RX is double buffered, presumably this means no pause in the SCK (although I haven't yet tried this). To STOP the transfer, you need to count the TX END events and issue a STOP to the peripheral. This could be done via PPI and a HW counter. This means that, if you can break the data block into 'n' equally sized blocks, then total transfer size is 'n' x TXD.MAXCNT.
I think the 'ArrayList' terminology is misleading and confusing. It implies (to me anyway) that you can have a list of transactions with independent and dis-contiguous buffers and sizes. Nordic's SPI Manager driver, however DOES provide this, but I doubt that the SPI clock is continuous between transactions. I've used the SPI Manager and it is powerful, but with power comes complexity.
-
One potential problem (why I didn't use it by default) is there's hardware bug which means that 1 byte SPI transfers fail
There's another gotcha with nRF52 EasyDMA that I find annoying, the count on the SPI transfers is 8 bits which means that you can only transfer a maximum of 255 bytes, creating a really cumbersome sequence if you're transferring to/from something that has fixed 256 byte pages (like Flash memory to take a random example). You essentially have to transfer twice as many blocks for each page (transferring in 128 byte blocks, is the most efficient).
While concurrent SPI might be nirvana, there is a slight advantage to having muliple SPI ports if you're trying to lay out a tight board with multiple SPI devices. It's very easy to assign unique SPI pins to each device to simplify board routing. While the reconfigure-ability of the nRF52 pins doesn't REQUIRE you to use different SPI peripherals, using multiple peripherals does reduce the amount of reconfiguration necessary. I'll concede that this advantage, of course, is meaningless to an existing Espruino board, however.
Did this or the SW update solve your problem?