Search results for:

Did this or the SW update solve your problem?

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

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

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

I looked at the DFU code and see that there isn't a programmable hook into it. So this begs the question, does anybody else want this?

@fanoush, I have a test case running where I use I2C and either SPI1 or SPI3. I did not try a test case where I try to use I2C and SPI2, although, if they weren't used concurrently, it might work, but, as you say, since they share HW resources, it's not a good idea. I don't think that there is any checking at the jswrapper level so it wouldn't be prohibited.

The jswrapper only enables TWI1, not TWI0.

I'm now testing multiple SPI ports on my version of the MDBT42Q board and have discovered a bit of 'chicken and egg' problem.

The Espruino build process uses BOARD.py to define the included features of a board. Ok, creating a new BOARD file and setting

'spi' : 3,

seemed to work and allowed me to pass a simple test:

I2C1.setup({scl:D10,sda:D11});
SPI2.setup({mosi:D07, miso:D05, sck:D04, baud:1000000});

function tellAbout(intf) {
  if(intf._options.mosi)  {
    console.log("interface is SPI");
    intf.cs = D09;
  } else {
    console.log("interface is I2C");
    intf.addr = 0x1c;
  }
  
  console.log(intf._options);
}

tellAbout(SPI2);
tellAbout(I2C1);

console.log(SPI2);
console.log(I2C1);

However, when I tried to actually USE the new port, the SPI hardware wasn't being used. I then looked at the jshardware.c file and saw that it was fixed at 'spi0' only, so I updated that to conditionally include code to instantiate and use spi1 & spi2. This, of course, required that I update sdk_config.h to set the respective SPIx_ENABLE macros (otherwise the nrf_drv...c files didn't know about these devices).

Once this was all done, the extra SPI ports worked marvelously.

Unfortunately, when I regressed the build for the original MDBT42Q I got a bunch of compiler errors stating that EVSPI2 & EVSPI3 were not defined. After a bit of research, I discovered the problem. EVSPIx are enumerated in jsdevices.h based on a macro SPI_COUNT defined in the auto-generated platform_config.h. Unfortunately, this macro is also defined in sdk_config.h based on the number of SPIx_ENABLE macros. As a result, using SPI_COUNT in jshardware.c file to conditionally build used the existing macro definition created in sdk_config.h due to the ordering of include files, overriding the definition in platform_config.h.

I suspected that reordering the include files in jshardware.c to try to solve this problem was probably the way to madness (DAMHIKT!) and ended up creating a new macro, SPI_MAX, in jsdevices.h, so that the proper board specific count of SPI devices could be saved and unambiguously used in jshardware.c.

This works for the nrf52 builds. SPI_MAX should be benign for all other boards. I think fundamentally having hardware definition controlled from two points (BOARD.py and the sdk_config.h files) is ripe for similar contentions. In normal nrf build structures the platform specific sdk_config.h is located in a platform specific config folder. However, this doesn't work well in this multi-platform situation so I'm not sure if there is an ideal solution. Maybe copying a BOARD specific version of sdk_config.h into the gen folder would work, but I'm not sure about the tooling to do this.

Normally DFU is started by holding D0 high while resetting or powering up the Device. Is there a software 'hook' by which an Espruino device can restart into the DFU?

This would make firmware update a lot easier and not require physical access to the board - what OTA is all about...

Tom

FYI, using 2v01.102 and the code in #4 I was able to connect with 4 different devices without a passcode and I'm pretty sure that one of the devices (old Samsung Note 3) had never connected to this Espruino board before. I'm going to let this pass for a while as I have other things to pursue at the moment. This was just a head's up.

Thanks. Looks like I'll update my build later today.

I forgot to add that perhaps if your PC has already paired with the device, that pairing could be stored in memory and so it may not ask you for a passcode. You could try connecting with another device?

Good point, I'll keep that in mind.

Ok, thanks.
Am I using the setSecurity correctly, though?
ie, should I expect the IDE to require a prompt after I load that code and try to reconnect?
Since I have my own build of the Espruino code, I don't want to be arbitrary when I update it...

I tried to use passkey in a simple case:

NRF.setSecurity({passkey:"123456", mitm:1, display:1});

var  on = false;
setInterval(function() {
  on = !on;
  LED1.write(on);
}, 500);

I expected to get a prompt from the IDE when I tried to reconnect, but it reconnected without issue. I did notice this comment:

As of Espruino 2v02 (or 'cutting edge' builds), you can set a static Passkey for Espruino:

I'm currently using 2v01.56 and I don't see any builds that are greater than 2v01. What am I missing?

Thanks for the tips. I'll check them out. As you say

it makes it really easy to get stuff going.

You all may be used to this, but it took me completely by surprise.

As I was progressing on my Thermostat project (currently updating the e-paper display from essentially hard coded data), I began to explore how my home server would send commands and data updates to my device. In this, I found the node.js BLE examples and then suddenly realized that I didn't need to create an 'API' - the fact that the Espruino code essentially runs as an open console interface means that if I want to update any data, I can simply send a javascript command to assign a value to it!

Need to update the forecast? Just send this over the 0x0002 characteristic :

"\x03\x10forecast = ['Mostly cloudy, with','a high near 70.    ','S wind around 7 mph','Chance of rain 20% '];\n";

Now I do have to admit this is a HUGE security exposure, but it sure is easy!

Thanks!

what fonts do you use for your project?
I guess you use Espruino vector font and some images.

Busted! :-)

Other than the time & date, the text in the photo was part of the image put in as background. It may still be done that way for most of the text since the background will be common to all the thermostats in the house and the image can be made and distributed by the home server. The only thing completely local to the thermostat is the temp & rh. You are correct that the date/time used the espruino vector font.

Ok, multiple partial updates works, although images need to be inverted color from my expectation for some reason, but that's probably just a learning thing...
I'll try the Crystalfonz display next, but the attached photo shows the direction I'm going.

but right now all you have to do is remove transparent:0 from the finished JSON.

This won't work as the bits in the B64 text are all black. It's not that big a deal, it's easy enough to convert transparent to white in the image. It's just something that slowed down my testing last night.

As far as I know, there's no getRotation - so yeah, trying to do a new Graphics could be a pain.

It would be easy to add, but I didn't want to mess with the Graphics library. That's a much bigger change than updating a module... I am considering adding rotation the .partial parameter list. Maybe make it an option?

Thanks, I'll check out g.getModified. Right now I have a bunch of testing to do. Will PR the new driver when I'm confident that it's ready. It would be nice if I could query the rotation of the 'g' object (within display.partial()) so I don't have to rearrange the coordinates and sizes when the partial object was created.

Also, I am having a bit of trouble making images for testing. It seems your online tool is treating 'transparent' as black and everything I've tried is Black on transparent... I need to re-'color' the images for White on transparent unless there's a switch I'm missing on your tool.

I've made a new e-Paper Display driver (cloned from SSD1606 driver) that works with newer e-Paper displays that support partial update. It's currently working with WaveShare's 200x200 1.54 inch display and 'should' work with Crystalfontz e-Paper displays (at least the 122x250 CFAP122250A0-213) but I haven't gotten around to testing that display yet.
As far as I can tell, these displays use the SSD1608 chip and, while I'm still testing, I thought I'd let y'all have a glance.

The advantages of partial update are:
Faster update,
only selected region is modified so fixed image background is maintained,
no flicker on update.

With this implementation, each partial region can have it's own graphics object that can be updated independently (in theory, I haven't tested this yet ;-)

In the photo below, the background was erased and the 'standard' Hello World message written. Then a partial region was created and it is updated every ten seconds with the time of day. Boring yes, but if multiple regions can be supported (memory might be an issue) then very useful.

More later, Enjoy...

@Wilberforce, exactly so! Thanks for adding the links.

(Note there isn't software SPI or I2C for the Pico STM chip)

@Robin, are you using MDBT42Q or STM chip???? (I'm not sure why you're mentioning SW SPI or I2C for STM chip in this context.) The subject line says MDBT42Q in which case, as I said in my post, you can assign ANY valid GPIO pin to a Hardware SPI circuit. As Wilberforce's links indicate, the construction of the MDBT42Q Breakout core code will only enable ONE SPI hardware block (the nRF52832 supports more). That one block, however, can be connected to ANY valid GPIO pin.

And, since your application seems pretty clear, you can simultaneously support communications with both your GPS receiver (via SPI, or I2C, or UART, no matter what pins you want to use) and BLE.