Are there other connections that you're not mentioning? There must be.
How are you receiving the serial data? The wiring you describe above would not permit any serial communication whatsoever, since you have TX connected to TX. Serial has TX and RX wired to eachother (since one has to receive what the other transmits).
Do you have some other serial adapter connected or something?
Are there other connections that you're not mentioning? There must be.
How are you receiving the serial data? The wiring you describe above would not permit any serial communication whatsoever, since you have TX connected to TX. Serial has TX and RX wired to eachother (since one has to receive what the other transmits).
Do you have some other serial adapter connected or something?
Sorry, I've forgotten to say: I'm using the Arduino Due as a TTL-USB converter, so (following the internet) I just needed to connect the Arduino Due Reset to GND. Changed in first post.
My ATmega328p TX is connected to the Arduino Due TX0 and with this I'm receiving the 'a' char, but without delay. If I connect to RX0, there is no serial data (maybe TX0 means Transmit to USB and RX0 receive from USB?).
Jack wp: He's connecting the Due's reset pin to ground, not the ATmega328p's reset pin to ground (unless I'm really interpreting it wrong).
Yeah, that's right then - in that case, the wiring is correct (you're wiring the TX of the ATmega328p to the TX pin on the held-in-reset due, and that TX0 pin is connected to RX pin of the serial adapter on the Due)
Could you try a sketch like this that is more informative? That way you know that an "a" is never from a reset event, and "start" always indicates a reset/startup event, and takes the guesswork out.
Also, ffs, TTL serial adapters are like a dollar (2-4 for a nice one) including shipping on ebay, why are you using your big fancy due for such a task?
"He's connecting the Due's reset pin to ground, not the ATmega328p's reset pin to ground "
Will that prevent the Due from sending serial signals, while it is held in reset mode. I may misunderstand.
DrAzzy:
Jack wp: He's connecting the Due's reset pin to ground, not the ATmega328p's reset pin to ground (unless I'm really interpreting it wrong).
You are right.
DrAzzy:
Also, ffs, TTL serial adapters are like a dollar (2-4 for a nice one) including shipping on ebay, why are you using your big fancy due for such a task?
I'm using what I have in hand
DrAzzy:
Could you try a sketch like this that is more informative? That way you know that an "a" is never from a reset event, and "start" always indicates a reset/startup event, and takes the guesswork out.
void setup() {
Serial.begin(19200);
Serial.println("start");
}
void loop() {
delay(5000);
Serial.println("a");
}
Also, ffs, TTL serial adapters are like a dollar (2-4 for a nice one) including shipping on ebay, why are you using your big fancy due for such a task?
I get the following input (using RealTerm terminal):
Do you have the 10k pullup from the '328's reset to Vcc?
Do you have the 0.1uf ceramic decoupling capacitors between Vcc and Gnd, and between AVcc and Gnd on the '328p, as close to the pins as possible? Omitting these caps will result in unexpected resets or worse; they are not optional, despite that some guides omit them. Having the ESP8266 on the same power rails just makes this issue worse.
100uf is not sufficient for decoupling, though it's a good idea when using an esp8266 on he same breadboard.
You must install decoupling capacitors, 0.1 uf ceramic, between vcc and had, and between vcc and gnd, add close to the chip as possible. These are needed for almost every IC.
Well, of course if you are attempting to supply an ESP8266 from the "regulated" output of the DUE, the heavy surge load of the ESP8266 as it transmits packets will not surprisingly, cause power dips. It has nothing to do with suppressing transients that the 0.1 µF caps would manage - though you should still have them.
If the 100 µF causes less frequent resets, then you need to "up the ante" to 470 µF or so - or find a proper regulated 3.3 V supply for the ESP8266.
Paul__B:
Well, of course if you are attempting to supply an ESP8266 from the "regulated" output of the DUE, the heavy surge load of the ESP8266 as it transmits packets will not surprisingly, cause power dips. It has nothing to do with suppressing transients that the 0.1 µF caps would manage - though you should still have them.
If the 100 µF causes less frequent resets, then you need to "up the ante" to 470 µF or so - or find a proper regulated 3.3 V supply for the ESP8266.
That's strange, because before using the standalone ATmega328p, I tested the ESP8266 with Arduino Due, and it worked pretty well. But to be sure, I tested it again and it really works (Arduino Due <> ESP8266).
Another thing is that I'm not transmiting packets in my test program, just trying to setup the module.
I will try both suggestions of 0,1uF and 470uF.
When I was writing this reply I figured out that my Capacitor is 104, which is 100nF = 0,1uF, so I think it couldn't solve the problem.
When I as testing things, I disconnected one by one pin of the ESP8266 to see which were the problem. And it was the pin CH_PD.
I followed the tutorials about wiring the ESP8266, and all of them just said to connect the CH_PD (Chip Power Down) direct to +3,3V.
So, I tried to put a 10k resistor from the pin to +3,3V (pullup) and now my microcontroller doesn't reset anymore. Still strange, because the Arduino Due itself didn't reset a single time (When communicating with ESP8266 and CH_PD direct to +3,3V).
Thanks for all the help!
I will change the title to be more suitable to the problem.
If you really want to do this right, you need to use a separate 3.3V supply for the ESP8266 that has very low impedance; for my projects, I use a DC-DC switcher, under $1 from various vendors eBay/Aliexpress.
Then the V+ that feeds the Arduino 5V regulator can feed the DC-DC switcher which is then set to 3.3V to feed the ESP8266. The ESP can consume over 500mA during transmitting, so the bulk capacitors on the DC-DC switcher are definitely necessary. you should also use the 100nF to decouple directly at Vcc and Gnd on the ESP8266 module.
Using this technique, I have created many stable ESP8266 projects, no reboots and no stability issues. you still must be careful in your code to ensure that you use Delay(0) often to allow the RTOS to service the RF section of the uC.
Actually, I'm trying to power the ESP8266 using 2xAA but it's difficult. I can't get a proper 3,3V regulator (I would use 4xAA and regulate to 3,3V), so I'll look for DC-DC switchers.
Delay(0) would be used like a delayMicroseconds()? Actually I'm sending a command and then waiting for the response before going to the next command. I don't know why and where to use Delay(0).
I'll see your projects, they appear very interesting.
Actually, I'm trying to power the ESP8266 using 2xAA but it's difficult. I can't get a proper 3,3V regulator (I would use 4xAA and regulate to 3,3V), so I'll look for DC-DC switchers.
Delay(0) would be used like a delayMicroseconds()? Actually I'm sending a command and then waiting for the response before going to the next command. I don't know why and where to use Delay(0).
I'll see your projects, they appear very interesting.
Most AA cells have too high of an internal resistance (about 0.15 Ω at room temperature) so a large bulk cap must be used to manage the 500+ mA spikes due to the RF power amp. The Vd is also affected by the total resistance of wiring, switch contacts (cheap), etc.
