Search results for:

@Robin, the firmware update did indeed solve the problem, so thanks a bunch for the help. I'm going to hijack my own convo thread rather than create a new post...

With both the old 1.93 fw and the current 2.04 fw, I've had intermittent errors loading the module I showed above. I was able to load this module in 1.93 when it was a function rather than an ES6 class. After class conversion and fw upgrade, I was once again able to load the module.

However, intermittently, the load would simply fail with "module potentiometer not found". Screenshot attached, showing load failure followed by load success like 5 seconds later. Note that this is the ONLY file that intermittently fails to load (and that it is last in the require list), the others all load 100%.

Whew! Glad to hear that...because I will have lots more questions coming down the pike.

PS - I've played with NetDuino (but not Arduino), Raspberry Pi, and BeagleBone Black prior to Espruino. Hands down, Espruino is best!

So I'm creating some modules for my project, one of them being a class. This class is in the Modules folder, and is being require'd in. Here's the opening code snippet:

class Potentiometer {
	constructor(config, PID) {
		this.config = config;
		this.PID = PID;
		this.registeredCallbackTimerId = undefined;
		this.setValueTimerId = undefined;
		this.currentValue = 0;
	}
...
}

exports = Potentiometer;

...and of course I'm doing this in the main code:

let Potentiometer = require('potentiometer');
let pot = new Potentiometer(config, PID);

When I run the code, I get the 'constructor' is not defined error. I'm on fw 1.93 if that matters. I could use a little help.

My message payload should be a max of 56 bytes, and often much less. I'll start slow and go from there. Thanks.

@Gordon what is the recommended maximum baud rate for USART communication between a Pico and a Wifi?

Wow, that's awesome, @Gordon, thanks for the help. I actually outlined an ID-based comm idea, but talked myself out of it over the fear that I couldn't control crosstalk between the slave devices. I hadn't considered also using that to control when they communicate. Looks like it's time to get past the theories and start trying something.

@Robin, no problem, I also have several other tasks to complete before I get to multi-microcontroller communication.

@Robin, really interesting information, and again I greatly appreciate the time everyone has been taking to help me. I saw a demo of two Arduinos chatting on I2C, and it looks similar to what you described. But even better, I found this chip, a Cypress I2C Dual Slave Bridge: https://www.cypress.com/documentation/da­tasheets/cy7c65221-dual-i2c-slave-bridge­

"...is an I2C bus bridge. It functions as an I2C slave for two masters, allowing them exchange data."

This chip appears to solve the exact problem I have, and even more, appears to allow me to chain as many as I want, which is really important to my project. I now have a lot of work to do before I move forward with this dual-slave chip, but hey, I have a solution!

@Robin the reference manual for I2C Class says:

This class allows use of the built-in I2C ports. Currently it allows I2C Master mode only.

That sounds like I can't connect one Pico to a second (or third/fourth/etc) Pico and have them communicate via I2C, because I can't put any device into Slave mode. Am I misinterpreting the docs?

Edit: and the doc says the same thing about SPI.

Thanks @maze1980, so I'm gonna have to resort to using I2C. I know I2C can do 1-Master-Many-Slave, but is this supported by the Pico/Wifi boards?

The longer-worded version of my question is...

Can I configure an Espruino Wifi module as a USB Master, and connect multiple Picos as USB slaves, so that the Wifi can bidirectionally communicate with each Slave? I would be wiring these together using USB pins, not using USB connectors/cables (if that matters).

I think I've talked myself out of USART - not because of this conversation, but because I thought I could connect multiple Picos a la RS485 via USART, but I think that wouldn't be very easy to accomplish. So instead of USART, I'm considering other options. I2C or USB perhaps.

@maze1980 I can live with that. Thanks!

@Robin thanks for the reply, and @Gordon thanks for taking the time to help. RE: node event loop, it's not quite like the Arduino loop - I wasn't referring to Arduino's loop(), but rather how I believe the underlying Espruino code works. And even now I'm not sure that this clarification is helpful. Apologies for that.

At any rate, what I hope the code will be able to accomplish is this:

1) Read a pot's value every 10ms using setWatch
    a) Send that pot's value on Serial1 at the next serial message setInterval (every 10ms)
2) Read a button press every 20ms using setWatch
    a) Send the button state on Serial1 at the next serial message setInterval (every 10ms)
    b) Enable/Disable the button's LED
3) Receive a series of messages, totaling 100-ish bytes, on Serial1 from a sender, every 10ms
    a) if the message is present, move the pot's fader (motorized fader)
    b) if the message is present, send LED on/off commands to LED strip via SPI
    c) if the message is present, enable/disable that button's LED (from #2 above)

That's the entire project. One setWatch(10ms), one setWatch(20ms), and one setInterval(10ms), each doing a small task or three and then getting out. With all that going on, my question was essentially "will the button's LED light immediately, when I press the button?", and "when I yank the fader back and forth, will the messages get sent with a real-time feel? Or will the messages stack up and have more of a burst-y feel?" I think I may have to write it all to find out, but any tips that helps minimize latency would be awesome.

@maze1980, no, it's a legit pot, power, ground, third pin for resistance. https://www.sparkfun.com/products/10976

The setWatch() documentation says this, regarding the 'options' field:

// Advanced: If the function supplied is a 'native' function (compiled or assembly)
// setting irq:true will call that function in the interrupt itself
irq : false(default)

Does that mean that the compiled code would NOT be executed by the node event loop?
And as a result, instead of the event being put in an event queue, and possibly held up by other javascript code running, the code would run immediately?

Could that be a better way to handle the pot (as compiled code)?

Thanks everyone for taking the time for thoughtful replies.

I have a little-more-than-basic understanding of js and node, which is what prompted the questions. Of course, I've never run this on a microcontroller, where there is no mouse, hard drive, display, etc to manage at the same time -- which gives one hope! Because I have no plans for any code to be long-running (just "get in and get out"), I'm hopeful that the js code will be able to perform with a real-time feel to it.

The USART will be communicating with another microcontroller, sending and receiving messages at -- hopefully -- 10ms intervals. It will never be a stream of data, just a message payload sent at a pre-determined interval. The payload would be less than 1kb always, and frequently be less than 100 bytes. So I doubt I'll have problems overloading the buffer (unless I do something in the code that's long-running). BUT, there are commands in that buffer which the javascript will be executing: perhaps turning on/off an LED, bits like that. So there IS work in there, I just don't think I'm I/O constrained.

At the moment, I have no code that needs to run every XX milliseconds "just because"; I'll only have code that will run as a response to external stimuli (button press, that darn slider pot), and to commands from the USART. So I chose setWatch.

Yeah that slide pot is the big worry, because the code to handle a change in the pot would be something like:
potCallback() {

receive_pot_value();
send_56_byte_message_to_USART();

}

If the user is just reaming on the slider, generating tons of these callbacks, while messages are coming IN to the USART, that's where I worry about latency becoming a concern.

I could also slow down the watches and USART to 15ms to allow for more breathing room - that's still 66 updates per second.

I'm working on a project idea for the Pico that will have a slide potentiometer and a couple buttons. I intended to use setWatch to watch for the pins that are connected to the pot and buttons, but I'm wondering how responsive my code will be, especially regarding the pot. I plan on setting the watches for 10ms, but I don't know if having 3 separate 10ms watches on 3 input pins will create unpredictable latency (i.e. will my code get called at unpredictable intervals, ruining the real-time feel to the user).

And of course, the code will be acting on these timers, sending data out a USART, receiving commands on that USART...so quite a bit going on. I'm also wondering if all that other activity could impact the determinism of the watches.

Any thoughts on that? Suggestions for improvement?