I am trying to interface Wemos D1 Mini to Atmega16 and have communication between them using TX and RX pins.According to the datasheet, the maximum allowed current for the Wemos mini is 3.3V for all IO pins while the Atmega 16 is giving 5V at it's IO terminals.For this problem, I could come up with just one solution and that is to use a voltage regulator. But this solution will require three voltage regulators, 1 for powering Wemos D1 mini and 2 for TX and RX lines. This solution seems to complicate the design. So is there an elegant solution for converting 5V to 3.3V?
I am completely novice to the field of electronics and this is my very first project so there might be a mistake in my understanding of basic concepts.So if that's the problem then please let me know.
Thank you.
Electrical – How to convert 5V to 3.3V for all pins of wemos D1 mini when interfacing it with Atmega16
atmegaavrwifi
Related Solutions
In my [in]experience, 99% of serial communication errors are due to timing mismatches; the other* 99% is due to wiring hoopla.
- It works for short wire but not a 30ft CAT-5 cable
- It works for normal serial wire upto 10ft but not more than that.
CAT-5 cable is twisted pair (also, all of what I have used is also shielded, but apparently this is not common); I assume the "normal serial wire" is two loose wires. As wiring gets longer, your nice digital rise times stretch out, effectively shrinking the available window for sampling incoming data. Twisted pair helps this a bit. What this really means is that your UART clock must be prescaled more accurately to the baud rate being used. System clocks for perfect USART communications should be multiples of 1.8432MHz. Short-range communications can tolerate a few percentage error, but as your sampling window shrinks it must be more accurate. What your prescaler (int), and baud error?
prescaler = (int)(F_CPU / (USART_baudrate * 16) - 1)
actual_baudrate = F_CPU / (prescaler * 16)
baud_error = 100% * (1 - actual_baudrate / USART_baudrate)
- It works for 6V battery but not for 12 volt battery or a 12V adapter.
This sounds fishy! This may be a completely different problem, perhaps causing your widget to reset due to a dirty supply or poor regulation. There are stability issues with LDO linear regulators and varying capacitive loads; there may be dissipation issues from a 12V supply; if one isn't using a LDO regulator, then a 6V battery will really be giving you 4.5V to 5V, and won't be well regulated. Power supply issues are in a class all their own, and must be rectified before peripherals can be effectively debugged.
Other than this, there is always the issue with environmental interference, or EMI. RS-485 is made for this, but should be used with twisted pair[, shielded wire,] like the CAT-5 cable you've used.
**(What, my math is wrong? Do you know who I am!? ;)*
If your encoder doesn't pulse too fast I'd do it without the HCTL-2020. There's nothing in it a microcontroller can't do.
The HCTL-2020 is a parallel output device, for interfacing with an 8-bit microprocessor bus (probably from the Crimean War period). Data is on D0-D7 if the OE input is low. Since you have 12/16 bit of data you'll have to use the SEL input to select whether you want the HOB (High Order Byte) or the LOB (Low Order Byte). Use the RST input to reset the counter.
So OE, SEL and RST are outputs from the microcontroller, D0-D7 are inputs.
The HCTL-2016 outputs 2 square wave signals in quadrature, which is needed to tell the rotation direction. These go to the CH A and CH B inputs of the HCTL-2020. If you want to connect the 2016 directly to a microcontroller (saves you 9 I/O pins) you'll want them on pins which can give interrupts on changes.
Best Answer