Most recent activity
-
The
nodeMCUresets, because the ESP8266 has a watchdog, and the while loop prevents control returning to the underlying Espressif OS. But I'm pretty sure it would mess up USB and Bluetooth communications as well. Also, even a simple uart buffer - that uses HW uart & buffer - could overflow in a couple of seconds.Almost wrote that there could be a "main loop a'la arduino" thing in Espruino-Blockly, that emulates the expected behaviour. But the purist inside me thinks that kids mind should not contaminated be by seeing a blocking wait call on a microcontroller. Or actually in any code. Even if everybody seem to do that.
Did you know that god kills a kitten when you use blocking wait in any code? :OInstead if the
while(true)block, you can use therun code every X secondsblock I guess. -
AFAIK, on the ESP8266, only some pins are truly general purpose input and output pins. Lots have restrictions either during boot, or don't behave nicely either as input or output. Nodemcu.D8 == GPIO15 might be one of those pins, but not certain about it...
-
Looks like the RMF96 and SX12xx modules have different parameters. The RFM69's connect's first parameter should be the SPI object, not an object with an
spiproperty:// from the docs: rfm = require("RFM69").connect(SPI2, {cs:B10, rst:B1, freq:434}, ... // your code: rfm = require("RFM69").connect({spi:SPI, cs:D8, freq:915}, ... -
Just quickly looking at the datasheet:
Do you set CS to high?
Is your wiring good?
Is the I2C address correct?For example, have a bunch of INA226 modules that don't use the default I2C address, and SDA and SCL markings on the breakout board are swapped...
-
Ouch.
One thing you may try: try to put it into bootloader mode with the DSD6 app. Absolutely no idea whether that clears the watchdog, or what might happen, but may work. Probably wait for you watchdog timeout, before trying to reflash, so it doesn't restart the watch while flashing, and bricks it even more :) -
Suggestion: bold Post your code :)
Another suggestion: highlight the part you feel relevant, but post a full reproduction. There may be a mistake at initialization, or even unrelated parts could interfere. -
If you have an android phone, get nRF Connect by Nordic Semi, and watch the RSSI graph as you walk around. I think it's worth to get an idea what to expect. Was using nRF connect just yesterday to test the range of BLE things.
Of course you can do this withNRF.findDevicesorNRF.setScan, just nRF Connect gives you a graph in a couple of seconds. -
I would say it's not trivial.
Depending on you environment, all kinds of things can affect the signal strength, not just range and TX power: orientation, objects, walls, people in the room.
Probably you should start recording range and RSSI values, and if it's consistent, do some interpolation (maybe even just use excel, and pick one distance value for every 10 dBm difference) -
Oh, that's impressive. NINA B3 on both sides? What antenna did you use?
The poison part meant to be slight joke.
In most languages a delay / wait literally waits at that point, and nothing else can happen simultaneously. This leads to locked-up UIs & CPUs sitting and waiting later. More and more languages include some form of async-await, or already have Future / Promise / Task to help avoid blocking code and callback hell.
If you do that with async-await, it won't block the CPU, it 's just a state machine, that gives the illusion of "sync" code. While allowing the CPU can do whatever it wants. Execute other code, or go to sleep to save energy.
Ok, that's really far from a kid just learning programming, and I have no experience teaching kids. So you are right, it should be as simple as possible.
If someone has never seen programming, I guess the concept of a
whileloop is something new as well.Can you get to the same end result with
run code every X secondsblock?For example: can you easily blink 2 LEDs at different frequency? Have never played with Blockly & Espruino, but I think that would need two "timer" blocks, and pretty much done. It would be much difficult in a while loop.
For interaction (UIs with buttons & leds, or some external chip) an event-driven approach feels better. Honestly, don't know which one would be more easier for kids to grasp. I started with Pascal & C in the school, for and while loops, etc. Those languages don't support async. But what if a kid can start with a language that has async support?