Trying to use my Oak's [Finally]

[PeterF]

Hm, I'll have a look at that in the morning. You're obviously getting closer... now the output is looking like it simply isn't talking to the ESP8266... as I'm pretty sure the last two lines are the same error you'll get if the ESP8266 isn't plugged into the usb-serial.

But I think you were probably right, in it was initially a problem with the boards.txt from that other article, as that was needed for pre ESP8266 Arduino 2.4.0, as 2.4.0 includes the DigiStump Oak board option as standard. I'm wondering if there is something still not quite right, as I didn't need to modify the boards.txt on mine at all, so perhaps there is still something boards.txt related wrong, or perhaps some other part of the configuration messed up.

[nefarious]

Are you using windows or linux?

if you look in the file ~/.arduino15/packages/esp8266/hardware/esp82266/2.4.0/boards.txt

is there a property?
oak.upload.resetmethod

[nefarious]

I miraculously got it to work this morning.  Sometimes I wish I wasn't so stupid .  You said it looks like arduino wasn't connected to the oak so I thought, what do I have to loose, so I just switched Rx,Tx and it uploads the script. 

Trouble is, it doesn't seem to work consistently, more then likely not an oak problem.

 Archiving built core (caching) in: /tmp/arduino_cache_451701/core/core_esp8266_esp8266_oak_CpuFrequency_80,FlashSize_4M1M,LwIPVariant_v2mss536,Debug_Disabled,DebugLevel_None____,UploadSpeed_230400_87c8508b9b5cd798698478194118aa71.a
Sketch uses 255243 bytes (24%) of program storage space. Maximum is 1044464 bytes.
Global variables use 33328 bytes (40%) of dynamic memory, leaving 48592 bytes for local variables. Maximum is 81920 bytes.
/home/ray/.arduino15/packages/esp8266/tools/esptool/0.4.12/esptool -vv -cd ck -cb 230400 -cp /dev/ttyUSB0 -ca 0x00000 -cf /tmp/arduino_build_942862/TrialOne.ino.bin

the arduino hangs here with Uploading... in the green bar between the sketch window and the output window.

I press Upload again and again and it hangs same place.  If I unplug the usb I unable to connect to ttyUSB0.  To get it to work I have to unplug usb for about half minute.

Anyway I have my DS1820B demo program working..

[PeterF]

He he... it happens to everyone ... at least it's working now Gets even more interesting when you have USB to serial devices that note the pins as RXD and TXD, and you have to remember if the TX 'Device' is the UART or the device on the other end :-O :-/

I work on both Linux and Windows, so when you said Linux I switched over to that for consistency. I just realised on my Linux install when updating the Arduino IDE and checking everything was up to date that I was running the RC2 pre-release of v2.4.0, for which the Digistump Oak setting worked just fine, but the release 2.4.0 gave the same error message for which you edited boards.txt for...

Code: [Select]

Arduino: 1.8.5 (Linux), Board: "DigiStump Oak, 80 MHz, 4M (1M SPIFFS), v2 Prebuilt (MSS=536), Disabled, None, 921600"

setting board to {upload.resetmethod}
error: unknown board: {upload.resetmethod}
known boards are: none ck wifio nodemcu
the selected serial port known boards are: none ck wifio nodemcu
 does not exist or your board is not connected

I then added to the following to the boards.txt to resolve it. I set it to none, instead of ck, because the oak doesn't have an auto-reset-for-programming option, which is why you have to have P2 connected to ground when powering it up (you can release the jumper once it's powered up, so I usually put a momentary press button on my builds connected to P2 to make serial programming easy, and also use the switch once a program has booted up if it has any user interaction.

Code: [Select]

oak.upload.resetmethod=none
I'll do a PR against the ESP8266 and get them to fix that (edit: it was fixed in a commit three days ago, so will be there in the next release), and also change the case of the board name... it's supposed to be Digistump, not DigiStump...

Oh, and I see why the pin mapping is out... when Christopher added the mapping, he stuck with the P1, P2 naming... so if you use the P1 for the blink sketch, it will properly map to that pin on the Oak (ESP8266 GPIO 5). The full list of pin definitions you can use is here.

I'll link a full compile and upload log (verbose output) of the un-modified blink sketch for comparison (too long to include in post).

For the intermittent upload issues, try lowering the upload speed to 115200, although AFAIK that only needs changing if uploads fail during the upload process... transferring too fast for UART device or noise present. Otherwise, if you need to unplug it for a while, maybe there's a problem with your USB port or the UART device... Anyway, as you said, it's working now...