if you're talking about nodemcu, do you mean implementation for lua?
isn't it so, that on the D1 Mini the CH340 ( USB2TTL ) is connected to the 3.3V? It could work.
However, if the USB is connected care must be taken as the 3.3V pin is used as output in this case.
I think on the D1 Mini Pro the situation is different, as the CP2104 is powered from the USB. I'm not sure what happens if only the 3.3V are applied as input voltage.
Hello @deshipu ,
I followed your explanation this morning and re-programmed successfully one of my motor shields. Haven't tested it with real software, yet. But the I2C scanner runs without problems, which is at least a very good indicator. Thanks again for your help!
If you set this board to work with 3.3V and RTS on the R/C pin you would expect that it works immediately as programming adapter for the motor shield. Under Linux this is not the case! Very likely there is an issue with the parity support in the Linux driver for CH340/CH341. Finally I used a FTDI adapter. I have not tested it under windows or on a mac.
Hello @camilozk ,
I think I got your point now, but I believe, even it might be possible technically, it makes no sense this way.
The neopixel libraries deals with the hardware, e.g. pins directly. You have no access to the bitstream send to the led strip from within your design. One possibility could be to use one microcontroller as "generator". This one will use the neopixel library and generates the bitstream. Instead of connecting a led strip to pin 23, you connect a Wemos D1 mini to it as "listener and master". This micro listens to the bitstream and distributes it via wifi to the other D1 mini, which are configured as "slave and generator". These slaves will take the wifi stream and convert it back to a bitstream for the led strip connected to the slaves. I don't know if this works and, as said I would not recommend it.
Instead I would use one device as "master" to use a simple command/answer protocal over wifi with the slaves. The slaves itself, connected to a led strip each, will take the commands and use the neopixel library running on them to generate the appropriate bitstream.
The only work you have to do is to implement the protocol. Probably another term for "master" and "slave" could be "client" and "server".
According to my understanding you need to have one of the devices on the I²C bus to be the master and the others to be the slaves. Most implementations assume that the Arduino or Wemos is the master. In your case you must implement a slave protocol in one of them. Did you do this?
Does it need to be I²C? UART might be better for this.
if I understand it correctly the driver has an optocoupler input interface.
In general, 5V is not good with the Wemos device.
You should either use a simple open collector interface from Wemos to the driver, similar to the description of "Connections to open-collector signal (common-anode)"
Or it might even work with the 3.3V.
Connect DIR- and PUL- to GND, connect DIR+ and PUL+ to the "+5V". Please double check before, if my assumption of the input is correct. It would be similar to the "Connection to PNP signal (common-cathode)" description.
Hello @KappaTsemg ,
please keep in mind that the ESP8266, used on the Wemos D1R2 is a 3.3V device.
In short you can't use the combination you mentioned !
The sensor is a 5V device with a 5V digital output. If you connect this to a 3.3V device, the device or at least this input pin can be destroyed. Switching from 5V to 3.3V on the base shield does not help, as the sensor will not work correctly anymore, even the output signal might be in the 3.3V range now.
What you need is a level shifter or at least a voltage divider.
Similar is true for the analog input. The maximum input voltage for the A0 is about 3.2V. If you are using a 5V sensor with an analog output that has 0V to 5V output swing, you can damage the device or at least the input pin. Please use an additional resistor of 220k in series.
Looks like your connection to WEMOS Forum was lost, please wait while we try to reconnect.