Avatar for TomWS

TomWS

Member since Mar 2019 • Last active May 2019
  • 10 conversations
  • 63 comments

Most recent activity

  • in Projects
    Avatar for TomWS

    @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.

  • in Projects
    Avatar for TomWS

    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..."

  • in Projects
    Avatar for TomWS

    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...

  • in Projects
    Avatar for TomWS

    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)?

  • in Porting to new Devices
    Avatar for TomWS

    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.

  • in Porting to new Devices
    Avatar for TomWS

    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.

  • in Porting to new Devices
    Avatar for TomWS

    @Gordon, it would be pretty trivial to switch to a different macro, ie JS_SPI_COUNT, in the espruino files (4 in src folder, 4 in the 'targets/stm32' branch. Although, I'm not sure if stm32_it.c needs to be converted or not). The question is, where is platform_config.h generated as this would have to change as well.

    @fanoush is correct, the I2C or SPI code could also verify if spi1_initialised or the i2c equivalent is set when trying to init the other and simply reject it. Multi-I2C would be useful where you have addressing conflicts or a mix of slow and fast devices.

    @fanoush also brings up an relevant point WRT concurrency. I had a case where using EasyDMA was essential for performance on another project and I considered it in the 'too hard to do' on Espruino and stayed with the nordic tools instead. My current project doesn't require that performance, but, without that option, I'm not sure I'd take up that quest on future projects if I was the only one taking advantage of it. It's ironic that Espruino is probably more inclined to use the asynchronous interface with callbacks than other platforms.

  • in General
    Avatar for TomWS

    I suspected you had decided not to do it as it's pretty trivial to add. Thanks for the info. I won't be putting in a PR for this ;-)

Actions