Zip created at /tmp/arduino_build_587243/sketch_dec29a.ino.zip
Using library Bluefruit52Lib at version 0.7.5 in folder: /home/alaskalinuxuser/.arduino15/packages/adafruit/hardware/nrf52/0.7.5/libraries/Bluefruit52Lib
Using library nffs at version 1.0.0 in folder: /home/alaskalinuxuser/.arduino15/packages/adafruit/hardware/nrf52/0.7.5/libraries/nffs
Sketch uses 59352 bytes (35%) of program storage space. Maximum is 167936 bytes.
Global variables use 4852 bytes (9%) of dynamic memory, leaving 46220 bytes for local variables. Maximum is 51072 bytes.
nrfutil –verbose dfu serial -pkg /tmp/arduino_build_587243/sketch_dec29a.ino.zip -p /dev/ttyUSB0 -b 115200
Upgrading target on /dev/ttyUSB0 with DFU package /tmp/arduino_build_587243/sketch_dec29a.ino.zip. Flow control is disabled.
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 59764
Sending DFU start packet
Sending DFU init packet
Sending firmware file
######################################################################################################################
Activating new firmware
#
DFU upgrade took 11.5461740494s
Device programmed.

Time out! Well, not really, but it sounds catchy! Timing is really important. And that is what I had to adjust with this commit. I had a 500 ms delay between program runs, which takes about 500 ms to run. So, each run of the program takes roughly 1 second, which is great for setting the timing of the program.

Here’s the interesting part: the relays that I am using are the latching relay featherwings. They only need the power applied to set or unset the relay for 10 ms, then they will hold their last position. This is great for power savings. In my program, I want to capitalize on this power savings by having the outputs off all the time, when they are not specifically latching the relays.

2923-00

To make that happen, at the beginning of the loop of my program, I added a few lines to set all of the output pins low (15, 16, 7, and 11). While this will cut down on the power the board puts out (saving electricity, but also saving wear and tare, as well as making the code cleaner, since the state of the pins will always be known), it may cause me a slight issue. I don’t want it to cut down on the actually needed signal for when the outputs should be high to latch or unlatch a relay.

Confused yet? Well, let me explain. Here is how the program looks functionally:

  1. Set all pins low.
  2. delay 500ms.
  3. run program, like setting some pins high.

As you can see, there is actually no time between running the program and setting all the pins back to low. I needed to ensure there was at least 10 ms after the program sets the pins high before the loop sets them all low again. I thought I could swap 1 and 2, making the delay first, but then there was no time between the setting of low pins and running the program. So I edited it like this:

  1. delay 250 ms.
  2. set all pins low.
  3. delay 250 ms.
  4. run program, like setting some pins high.

Now there will always be at least 250 ms (1/4 of a second) for the relays to latch before given a command to set the pins low. Conversely, after being set low, there is 250 ms before the program runs, allowing me to keep my (roughly) 1 second timing on the circuit. Probably a little overkill for what I need, but at least I know this will work, making the program more robust.

Linux – keep it simple.

Leave a Reply

Your email address will not be published. Required fields are marked *