Robot Kit

[PeterF]

@Blitzfx: No... it only broadcasts as an AP when in config mode - which it should only be in when you first power it up, or if it looses it's connection to Particle for a while. Rest of the time, unless your sketch programs it otherwise, it runs as a client only. I don't really think you can brick it by uploading code, unless the code itself bricks it. And Erik is still working on making that foolproof. I've had two fails. First one it recovered and started programming again. Second time, I pulled the power so it failed, and it programmed ok when I reconnected it.

@Russ: yeah... that is a bit of a rude awakening. If we had been programming ESP8266 boards via Arduino, we'd be familiar with it already, but not when coming from plain 'ol Arduino.

[jwhendy]

Well it appears to have worked 

Could you elaborate on your setup? I'm catching the obvious:
- green1: arduino TX -> oak pin3/RX
- orange1: arduino RX -> oak pin4/TX
- blue: looks like ground to pin1 or pin2
- green2: 3.3V arduino -> oak Vin?
- yellow: grounding arduino reset pin?
- orange2: arduino ground to oak ground?

Also, what did you do with this? Did you use it to restore or flash a sketch?

I'm looking to do something similar as I have an Arduino *now*, but my 3.3v UART doesn't show up until Sat

Thanks!

Edit: well, I just took the leap and went for it. After a bunch of errors with esptool.py not finding the board, I took a shot in the dark and switched my tx/rx pins. It worked! Re-looking at your picture, it looks like you're doing the same, actually. Am I right that this is the setup?

Code: [Select]

| arduino | oak         |
|---------+-------------|
| gnd     | gnd         |
| 3.3v    | Vin         |
| TX -> 1 | pin 4/TX    |
| RX <- 0 | pin 3/RX    |
|         | gnd to pin2 |

[DeuxVis]

It makes sense as the arduino µprocessor is not involved in the process : you are just using the usb to serial part of the arduino board.

Just make sure the sketch running on the arduino doesn't do anything with the TX/RX pins.

[Blitzfx]

Well it appears to have worked 

Could you elaborate on your setup? I'm catching the obvious:
- green1: arduino TX -> oak pin3/RX
- orange1: arduino RX -> oak pin4/TX
- blue: looks like ground to pin1 or pin2
- green2: 3.3V arduino -> oak Vin?
- yellow: grounding arduino reset pin?
- orange2: arduino ground to oak ground?

Also, what did you do with this? Did you use it to restore or flash a sketch?

I'm looking to do something similar as I have an Arduino *now*, but my 3.3v UART doesn't show up until Sat

Thanks!

Edit: well, I just took the leap and went for it. After a bunch of errors with esptool.py not finding the board, I took a shot in the dark and switched my tx/rx pins. It worked! Re-looking at your picture, it looks like you're doing the same, actually. Am I right that this is the setup?

Code: [Select]

| arduino | oak         |
|---------+-------------|
| gnd     | gnd         |
| 3.3v    | Vin         |
| TX -> 1 | pin 4/TX    |
| RX <- 0 | pin 3/RX    |
|         | gnd to pin2 |

Yeah I found that I had to swap the TX and RX around. Everything else is the same. You can connect the 3.3V to VCC as well . doesn't make much difference. Do not EVER connect the 5V from the arduino to VCC on the oak.

like deuxvis said, it's just turns the arduino into a simple UART converter and shuts off the micro. in other words, it just piggy backs off the onboard uart converter that would normally be used to communicate with the arduino.

The purpose of the yellow wire is to put it into persistent reset mode.
The blue wire is supposed to put the oak into bootloader mode or something I think. Forgot what he described it as. It's all here: https://github.com/digistump/OakRestore

[PeterF]

Makes you stop and think for a few minutes, doesn't it! Yes, as Blitzfx and DeuxVis commented, the TX & RX are backwards for use this way as the TX and RX on the arduino usually refers to talking to the Arduino chip, not the USB-to-Serial UART that talks to it. So as long as you have the arduino programmed to do something that doesn't use the Serial pins, you can use it as a handy USB to Serial. Even easier, if you have a board like Blitzfx's, is to simply pull the processor out, and it doesn't matter what code it was running.

[jwhendy]

For others who stumble on this, I took my experience and a few hours of head scratching about why in the world TX/TX and RX/RX works for the wiring and wrote up a tutorial. I hope it's useful to someone.

Thanks to @deuxvis for giving some helpful input/feedback in the github issue I posted about this.

[PeterF]

Great write-up jwhendry! Very nice, and well explained!

Just FYI, the reason that other people will haven't had problems with 5v on the IO is probably because the ESP8266 I/O pins are protected by a snap-back circuit. The chip runs at 3.3v, but just like the nrf24L01+, has 5v tolerant I/Os. From the datasheet (bottom of p17):

All digital IO pins are protected from over-voltage with a snap-back circuit connected between the pad and ground. The snap back voltage is typically about 6V, and the holding voltage is 5.8V. This provides protection from over-voltages and ESD. The output devices are also protected from reversed voltages with diodes.

[jwhendy]

@pfeerick: I caught that too when I asked at the github issue I created to inquire about using an arduino for UART. Evidence (also found the datasheet) indicated it was fine, but the official docs say to use 3.3v so it had me spooked. While the ESP8266 has these features, I didn't know if whatever the Oak adds on top of it was? Anyway, I took the gamble and it indeed appears to be fine

Thanks for taking a look at the wiki and for the kind words!

[PeterF]

No worries. I think the idea is to stick with 3v3 generally as it is a 5v part, but if you have just the one annoying sensor that has 5v I/O and you can't be bothered doing level shifting, you can cheat. Or things like the infrequent Serial Tx using a 5v UART. I'd be interested to see Erik's response to this, but I don't think the Oak (or Acorn really, as the Oak is just the carrier board) does anything that would alter the I/O voltage tolerances. The only problem would be that the Oak could accept 5v logic in, but would only be putting out 3v3 logic - so the device on the other side would need to accept 3v3 as being a logic high state. This shouldn't normally be a problem, but there will always be edge cases where it is, and specific sensors/parts that just won't work. Hence the level shifter board.

Hey, no problems! Glad to see someone else putting stuff on the wiki... more the merrier... gotta get all the good juicy info and ideas flowing!