Here's a slightly different approach in stead of a Lua vs. Python shootout:
Six of the most popular ESP8266 "runtimes":
AT Command SET. Popular when the 8266 is paired with another MCU.
Communicates via the serial port. ~64k of 128k RAM available.
MicroPython. A MicroPython script interpreter
with user friendly GUI that can be accessed via the serial
I don't think you really understand what you are talking about here.
"Zigbee", or IEEE 802.15.4, is a protocol. As such, it has no "programming language".
Theoretically, it's completely possible to implement a system which can handle the zigbee protocol in any programming language, assuming that whatever language you're using has adequate hardware support ...
In Python, msg = "255" will make msg a string type using those quotes around 255.
Your Arduino code is making this comparison: if(recv == 255)
This is going to do an integer comparison. A string "255" is not going to equal the integer 255 and I'm not sure how the data is going to be received and formatted on the Arduino using client.read(), it's probably ...
According to the schematic, there is a 10k--6.8k resistor divider in the circuit.
6.8k / (6.8k + 10k) = .4047619
1/.4047619 = 2.470588
Another place to look might be:
__lsb = float(0.0000078125) # default lsb value for 18 bit
7.8125e-6 * 2^18 = 2.048 // full-scale value?
5V / 2.048 = 2.441406
Or maybe some combination of those things.
Sorry I don't ...
One option is to parse the string in python and then send some sort of binary format to the microcontroller. This would be more efficient bandwidth-wise and the MCU code will be much simpler. The link to the microcontroller would still be serial, but you would not be limited to sending printable characters. It's quite easy to do open a serial port with ...
The answer is a guarded "Yes" : it is possible, but probably not commercially worthwhile. Hardware acceleration for OO languages was once a hot topic, but died down about 25 years ago.
One project was the Linn Rekursiv. It coincided with the rapid rise of RISC hardware and didn't last long enough to see their fall back from the leading edge. Probably the ...
It's a performance issue. The first version of setPinValues() is making many calls to String() each time it is called, and this is a nontrivial function. This causes setPinValues() to take much longer than you think to finish, so it isn't too surprising that the Arduino eventually can't keep up with the incoming messages at 57600 bps.
In the second version ...
Plug the Leonardo in to the USB port of the Pi. Open the serial port /dev/ttyACM0 and send the data. On the Arduino receive the data through the Serial object.
Alternatively, connect the Pi's TX pin to the Leonardo's RX pin, and connect the Leonardo's TX pin, through a 5V -> 3.3V level shifting circuit (there's lots of options - google them) to the Pi's ...
If both share the same logic levels (0V-3.3V) and the same ground it shouldn't be a problem. But then you aren't using RS232, just UART. The Serial bridge on the Arduinos works the same way. The FTDI chip uses 0V-5V and the ATmega uses 0V-5V.
To a first approximation, frequency does not matter at all, provided it's fast enough to avoid the appearance of blinking. All that's important is the average power of the LED, which depends only on the duty cycle.
In practice, there are switching losses that increase with frequency. Each transition from high to low requires some amount of energy, such as ...
You selected a microphone board with automatic-gain. This is exactly the OPPOSITE of what you need. You can not measure the actual audio levels when there is something upstream UN-doing all the audio level changes ("auto-gain"). So first, you must use the proper microphone module that will deliver the actual, honest, un-modified audio levels to you.
You're trying to plot in the time domain (ie. the x-axis is in seconds) but your formula is in the frequency domain (s is a complex frequency variable). You would need to perform the inverse Laplace transform to get back to the time domain.
This cannot be done unless you have a s-domain expression for Vin, which is tricky given that you just created it with ...
I was having a similar problem with a Wemos D1 mini board. Erasing and Flashing the firmware worked. However I was getting no REPL prompt, resetting was giving me garbage. I solved it by adding "-fm dio" when writing flash.
esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fm dio --flash_size=detect 0 esp8266-20170823-v1.9.2.bin
I don't think you can generate a txt format directly from the ltspice command line. I recently looked into this and I came across an old discussion which includes the primary author of LTSpice and indicates (at least as of 2003) 1) you can't export text directly from the command line, 2) the binary format is intentionally "secret", 3) there is a separate ...
You should just send the serial commands from C. No need to embed a Python interpreter. For all the information you might need on the topic, see the excellent Serial Programming Guide for POSIX Operating Systems.
Also, this question is off topic for this particular site.
PySerial (and serial libraries in general) have no idea of the concept of a "line".
When you port.read(), you get what is in the serial buffer right then, so if you opened the serial port when the arduino was partway through sending a serial message, you're going to get just the latter half of that message. If you call read() when the arduino has only sent ...
You have the wrong thing, first off
The automatic gain control (AGC) on your existing microphone-board is not what you want here -- a sound level detector is going to get thrown off by the action of the AGC loop changing the gain all over the place as it tries to maintain a constant output level (what else would you expect from an AGC loop?). You might as ...
Your voltage is given in the time domain (voltage values as function of time \$t\$).
Your low pass filter definition is given in the s-domain (transfer function as function of complex frequency \$s\$).
Both defintions don't fit together well (I wonder anyhow where you got the transfer function definition of the filter from if you don't know what to do with ...
The next step is the trapezoidal rule; i.e., approximate the integrand with line segments between the sample points. If you draw it, you see that the correction is graphically the area of a rectangular triangle. Numerically one integration step gives an increment (delta t) x (the average of consequent samples).
The next step is to use Simpson's rule.
As Jon pointed out, your Arduino is only receiving one byte. TCP provides a continuous stream of bytes, so you need to decide how you are going to separate messages.
You can either send a header telling the receiver how long the message is, or you can send a footer with a pre-chosen termination byte.
On the wire, the bytes for a message with a header might ...
You cannot connect a voltage source directly to the USB data lines - USB is a complex digital communications system.
You would require an Analog to Digital converter (ADC) that could interface to USB, and connect your solar panel to the ADC analog input.
Notice that your white cable is connected from SCK from your chip to RPi's pin 22.
But in your code you have:
SPI_CLK_PIN = 23
SPI_SDISDO_PIN = 22 # mosi
So they are reversed. It should be:
SPI_CLK_PIN = 22
SPI_SDISDO_PIN = 23 # mosi
Also, note that the graphic is missing the connection of 3 pins of the digital pot:
Pin 5 goes to GND
Pin 7 goes to Vcc
These kinds of alphanumerical LCD displays have been using the same protocol for decades, so all the controller IC manufacturers make it basically the same way. I'm not sure if you're trying to figure out the protocol to be able to use the LCD or if your question actually is something like how to make a logic analyzer, but in any case it might be easier for ...
Note that the BBB has three hardware quadrature decoders on-chip, and two appear to be accessible via the connectors. Look for eQEP functions. Some support software appears to be available now for these, search for Beaglebone black quadrature, etc.
Ada is certainly feasible. See these articles for example:
Some resources discussed here and available on github including the Ravenscar (real-time tasking designed with reliability in mind) RTS.
This obvious answer is that your code has a bug. I haven't looked at in detail to find it, but real opamps are a clear existance proof that feedback does really work.
That said, stability is a issue even with real opamps. This is probably easier to see by imagining the opamp working in discrete steps, much like a computer simulation. If the output is low ...