Voting resources, early voting, and poll worker information - VOTE. ... Adafruit is open and shipping.
0

8266 Weirdness (was: LUA weirdness)
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

8266 Weirdness (was: LUA weirdness)

by HowardP on Wed Apr 12, 2017 2:34 pm

[EDIT 8AUG2017 : Updated subject again to reflect what's actually being discussed :)) END EDIT]
[EDIT 6May2017:

In all fairness to the good folks at Adafruit, I've updated the subject. Since the OP, this thread's occasional popping back up to the top of the stack with the old subject line is misleading, somehow implying that Adafruit doesn't test their stuff well enough. That was not, and still is not, my intention.

The original problem seemed like it was hardware comm. related. Since then, this thread has meandered / evolved into:

1) OP Comm. problem with LUA and terminal input - SOLVED
2) LUA functions missing - doesn't seem to happen on other vendor's boards using the same LUA version - OPEN.

END EDIT]

In an Ask-an-Engineer video a while back, Ladyada mentioned that Adafruit tests everything before shipping. I reasonably understood "everything" to mean everything that Adafruit makes in-house. The product quality is consistently excellent. So do you all actually burn-in, or test, or do both for all your boards? Thanks! - Howard in Florida
Last edited by HowardP on Tue Aug 08, 2017 3:25 pm, edited 2 times in total.

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Re: How thoroughly does Adafruit test products?

by adafruit_support_bill on Wed Apr 12, 2017 3:04 pm

We do a functional test of all boards coming off our assembly line. Burn-in testing is quite resource intensive and would add quite a bit to the cost of boards.

adafruit_support_bill
 
Posts: 78748
Joined: Sat Feb 07, 2009 10:11 am

Re: How thoroughly does Adafruit test products?

by HowardP on Wed Apr 12, 2017 4:02 pm

Do you happen to know if the test for the Huzzah ESP8266 breakout board (PID 2471) includes checking its serial communications to/from the preloaded LUA interpreter ?

thanks
-H

(PS the reason I'm asking is because I'm pulling my hair out over an issue both you and Mike have replied to, but - despite multiple approaches - the problem is unresolved and I'm at a loss what to do next. https://forums.adafruit.com/viewtopic.php?f=19&t=115099)

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Re: How thoroughly does Adafruit test products?

by adafruit_support_bill on Wed Apr 12, 2017 4:13 pm

I will check with our QA department to see what tests are done on that module.

adafruit_support_bill
 
Posts: 78748
Joined: Sat Feb 07, 2009 10:11 am

Re: How thoroughly does Adafruit test products?

by adafruit2 on Wed Apr 12, 2017 4:20 pm

yes in fact we run a little lua sketch on each huzzah to do the GPIO and wifi tests. it runs on a raspberry pi 3. for your enjoyment, here's the script we use :) it wont run for you without our jig but it gives you a sense of how/what we test


Code: Select all | TOGGLE FULL SIZE
import sys
import glob
import serial
import argparse
import time
import os
import re
import subprocess
import sys
import time
import uuid
from clint.textui import colored
import RPi.GPIO as GPIO
from m0helper import *

starttime = 0
serialport = ""
startingpots = []

BUTTON = 17

RESETPINRESET = "Jan  8 2013,rst cause:2, boot mode:(3"
CHPDPINRESET = "Jan  8 2013,rst cause:1, boot mode:(3"
BOOTLOADRESET = "Jan  8 2013,rst cause:2, boot mode:(1"
LUABOOT = "NodeMCU 0.9.5 build 20150318  powered by Lua 5.1.4"
INPUT = 0
OUTPUT = 1
LOW = 0
HIGH = 1

VERBOSE = False

ser = ""

def esp_adc():
    cmdstr = "print(adc.read(0))\r\n"
    ser.write(cmdstr)
    reply = ser.readline()
    if VERBOSE:
        print("<-",reply)
    if cmdstr not in reply:
        return False
    reply = ser.readline()
    if VERBOSE:
        print("<-",reply)
    try:
   return int(reply)
    except:
        return False


def esp_pinMode(p, mode):
    cmdstr = "gpio.mode(gpiolookup[%d]" % p

    if (mode == INPUT):
        cmdstr += ", gpio.INPUT, gpio.FLOAT)\r\n"
    else:
        cmdstr += ", gpio.OUTPUT)\r\n"

    ser.write(cmdstr)
    reply = ser.readline()
    if VERBOSE:
        print("<-",reply)
    if cmdstr not in reply:
        return False
    return int

def esp_digitalWrite(p, val):
    cmdstr = "gpio.write(gpiolookup[%d]" % p

    if (val == HIGH):
        cmdstr += ", gpio.HIGH)\r\n"
    else:
        cmdstr += ", gpio.LOW)\r\n"

    ser.write(cmdstr)
    reply = ser.readline()
    if VERBOSE:
        print("<-",reply)
    if cmdstr not in reply:
        return False
    return True


def esp_digitalRead(p):
    cmdstr = "print(gpio.read(gpiolookup[%d]))\r\n" % p
    ser.write(cmdstr)

    reply = ser.readline()
    if VERBOSE:
        print("<-",reply)
    reply = ser.readline()
    if VERBOSE:
        print("<-",reply)
    val = int(reply)
    return val

def esp_testTwoPins(a, b):
    print("Testing %d & %d" % (a, b))

    if not esp_pinMode(a, INPUT):
        return False
    if not esp_pinMode(b, OUTPUT):
        return False
    if not esp_digitalWrite(b, HIGH):
        return False
    if not esp_digitalRead(a) == HIGH:
        return False
    if not esp_digitalWrite(b, LOW):
        return False
    if not esp_digitalRead(a) == LOW:
        return False
    if not esp_pinMode(b, INPUT):
        return False
    return True

def esp_sendline(x):
    ser.write(x)
    reply = ser.readline()
    if VERBOSE:
        print("<-",reply)
    if x not in reply:
        return False
    return True

def esp_wifiAP():
    if not esp_sendline('cfg={}; cfg.ssid="ESP_"..node.chipid(); cfg.pwd="abc"; wifi.ap.config(cfg);\r\n'):
      return False
    if not esp_sendline('cfg={}; cfg.ip="192.168.1.1"; cfg.netmask="255.255.255.0"; cfg.gateway="192.168.1.1"; wifi.ap.setip(cfg); wifi.setmode(wifi.SOFTAP);\r\n'):
      return False
    if not esp_sendline('print("ID: "..node.chipid());\r\n'):
      return False
    reply = ser.readline()
    print(colored.magenta(reply.rstrip("\n\r")))
    searchObj = re.search(r'ID: ([0-9]+)', reply)
    ser.readline()  # eat extra line
    if not searchObj:
   return False
    return searchObj.group(1)

def esp_getMAC():
    if not esp_sendline("print(\"MAC: \"..wifi.ap.getmac());\r\n"):
        return False
    reply = ser.readline()
    searchObj = re.search(r'MAC: ([A-F0-9]+-[A-F0-9]+-[A-F0-9]+-[A-F0-9]+-[A-F0-9]+-[A-F0-9]+)', reply)
    ser.readline()  # eat extra line
    if not searchObj:
        return False
    mac = searchObj.group(1)
    mac = mac.replace("-", ":")
    print(colored.magenta("MAC: "+mac))   
    return mac

def esp_wifiScan():
    if not esp_sendline("wifi.setmode(wifi.STATION) aps = \"\"\r\n"):
        return False
    if not esp_sendline("function listap(t) for k,v in pairs(t) do aps = aps .. \" \" .. k .. \" \" .. v .. \"\\n\" end end wifi.sta.getap(listap)\r\n"):
        return False

def esp_getScan(p):
    if not esp_sendline("print(aps)"):
        return False
    return ser.readline

##################################################

def runtest():
    global ser

    starttime = time.time()
    startingports = serial_ports()
    serialport = ""

    serialport = get_new_serialport()
    if not serialport:
   return False
    print(colored.magenta("Opening ")+serialport)

    try:
        ser = serial.Serial(serialport, 74880, timeout=1)
    except:
        print(colored.red("Couldn't open serial port"))
        return False
    ser.setRTS(True)  # RTS Low
    ser.setDTR(True)  # DTR Low

    # attempt reset (testing RTS and RST)
    print (colored.magenta("Resetting by twiddling RTS...."))
    ser.setDTR(False) # DTR High
    ser.setRTS(True)  # RTS Low
    time.sleep(0.01)
    ser.setRTS(False) # RTS High

    foundreset = False
    for i in range(0,5):
        line = ser.readline().rstrip("\n\r")
        if line:
     print line
        if (RESETPINRESET in line):
            foundreset = True
       break
    if not foundreset:
   print(colored.red("didn't reset properly?"))
   return False
    print(colored.green("Reset OK"))
    ser.close()
   
    # attempt bootload reset (testting DTR & GPIO0)
    print (colored.magenta("Resetting into bootloader by twiddling DTR/RTS...."))
    # we're just gonna use esptool-ck since python's not fast enough

    if sys.platform.startswith('darwin'):
        esptool = "./esptool"
    if sys.platform.startswith('linux'):
        esptool = "./esptool_linux"
    if sys.platform.startswith('win'):
        esptool = "esptool.exe"

    cmd = [esptool, "-vvv", "-cd", "nodemcu", "-cb", "115200", "-cp", serialport, "-ca", "0x0000",  "-cf", "foo"]
    process = subprocess.Popen(["timeout", "3"] + cmd,
                           stdout=subprocess.PIPE,
                           stderr=subprocess.STDOUT)
    returncode = process.wait()
    #print('esptool command returned {0}'.format(returncode))
    ret = process.stdout.read()
    if (returncode != 0):
        print ret
   return False

    print(colored.green("Bootloader OK"))
   
    print (colored.magenta("Checking Lua version...."))
    try:
        ser = serial.Serial(serialport, 9600, timeout=0.5)
    except:
        print(colored.red("Couldn't open serial port"))
        return False

    ser.setRTS(True)  # RTS Low
    ser.setDTR(True)  # DTR Low
    ser.setDTR(False) # DTR High
    ser.setRTS(True)  # RTS Low
    time.sleep(0.01)
    ser.setRTS(False) # RTS High
   
    foundlua = False
    for i in range(0,5):
        line = ser.readline().rstrip("\n\r")
   if not line:
     continue
        print line
        if (LUABOOT in line):
       foundlua = True
            break
    if not foundlua:
   print(colored.red("Couldn't find Lua?"))
   return False

    print(colored.green("Lua OK"))
    ser.readline() # eat lua: cannot open init.lua
   
    ser.write("gpiolookup = {[0]=3,[1]=10,[2]=4,[3]=9,[4]=1,[5]=2,[10]=12,[12]=6,[13]=7,[14]=5,[15]=8,[16]=0}\r\n")
    ser.readline()

    nodeid = esp_wifiAP()
    if not nodeid:
      print(colored.red("Failed to make AP"))
      return False

    apname = "ESP_%06X" % int(nodeid)
    #print(colored.blue(apname))

    macaddr = esp_getMAC()

    while True:
   while ser.readline():
     pass
        vcc = esp_adc()
        R1 = 51.0
        R2 = 10.0
        vcc = vcc * (R1+R2) / R2
        vcc /= 1024
        print ("3.3V: %f" % vcc)
        if ( (vcc > 3.7) or (vcc < 3) ):
            print (colored.red("3V3 weird, retrying"))
            continue
        if not esp_testTwoPins(2, 4):
            print(colored.red("Failed to test pins #2 & #4, retrying"))
            continue
        if not esp_testTwoPins(15, 14):
            print(colored.red("Failed to test pins #15 & #14, retrying"))
            continue
        if not esp_testTwoPins(16, 13):
            print(colored.red("Failed to test pins #16 & #13, retrying"))
            continue
        if not esp_testTwoPins(12, 5):
            print(colored.red("Failed to test pins #12 & #5, retrying"))
            continue
        break
    print(colored.green("Pins OK!"))

    wifiok = False
    for retry in range(0,10):
      print(colored.magenta("Checking wifi!"))
      os.system("wpa_cli scan > /dev/null")
      process = subprocess.Popen(["wpa_cli", "scan_results"],
              stdout=subprocess.PIPE,
              stderr=subprocess.STDOUT)
      returncode = process.wait()
      ret = process.stdout.read()
      if (returncode != 0):
         return False
      #print ret

      # print("Looking for "+macaddr.lower())
      # search for a mac address
      searchObj = re.search(macaddr.lower()+"\s+[0-9]+\s+(\-?[0-9]+)", ret)
      if (not searchObj):
   time.sleep(1)
    continue
      print colored.magenta(searchObj.group(0))
      print colored.green(searchObj.group(1))
      sigstr = int(searchObj.group(1))
      if ((sigstr < 0) and (sigstr < -40)) or ((sigstr > 0) and (sigstr < 80)):
        print(colored.red("WiFi too weak?"))
        return False
      wifiok = True
      break
    if not wifiok:
      print(colored.red("WiFi Check failed"))
      return False
    print(colored.green("WiFi OK!"))
    while True:
        line = ser.readline()
        if not line:
            break
        if len(line) == 0:
            break
        #print line,

    esp_pinMode(0, OUTPUT)
    esp_pinMode(2, OUTPUT)
    esp_digitalWrite(0, LOW)
    esp_digitalWrite(2, LOW)
    return True

if __name__ == '__main__':
    # Parse the input arguments
    GPIO.setmode(GPIO.BCM)
    GPIO.setup(BUTTON, GPIO.IN, pull_up_down=GPIO.PUD_UP)
   
    starttime = time.time()
    while True:
        print(colored.yellow("------ PID 2821 ------"))
        print(colored.yellow("Waiting for button #17"))
   while GPIO.input(BUTTON):
     time.sleep(0.01) # wait for button to be pressed
   while not GPIO.input(BUTTON):
     time.sleep(0.01) # wait for button to be released

        starttime = time.time()
   success = runtest()
        if success:
                print (colored.green("********* PASSED *************"))
                print (colored.green("********* PASSED *************"))
                print (colored.green("********* PASSED *************"))
      print(colored.green("Time elapsed: "+str(time.time() - starttime)))
        else:
            print(colored.red("********* FAILED *************"))
            print(colored.red("********* FAILED *************"))
            print(colored.red("********* FAILED *************"))

adafruit2
Site Admin
 
Posts: 19375
Joined: Fri Mar 11, 2005 7:36 pm

Re: How thoroughly does Adafruit test products?

by HowardP on Wed Apr 12, 2017 5:53 pm

Thanks, Adafruit2 - that does help and gives me more confidence that the devices are OK, but the problem is just so bizarre. -H

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Re: How thoroughly does Adafruit test products?

by HowardP on Wed Apr 12, 2017 6:13 pm

OK great ... I've temporarily solved the problem (which I'll document in the appropriate open thread).

After spending literally days using five different terminal programs across three different OS'es, I can say with high confidence that there are show-stopping omissions in the Huzzah ESP '8266 Breakout page. I would be happy to detail these to assist others in avoiding the landmines. Where should I post that? An email to someone, or one a forum page?

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Re: How thoroughly does Adafruit test products?

by adafruit2 on Wed Apr 12, 2017 6:21 pm

you could post here

adafruit2
Site Admin
 
Posts: 19375
Joined: Fri Mar 11, 2005 7:36 pm

Re: How thoroughly does Adafruit test products?

by HowardP on Wed Apr 12, 2017 8:55 pm

OK ... mainly filling in or clarifying essential details. (EDIT: added more results from trying sample code)

Hardware: Huzzah ESP8266 and CP2104, connected directly with supplied headers. (Some issues would be the same regardless of USB-to-Serial converter used.)

Refer to: Huzzah ESP Breakout learn page, NodeMCU section @ https://learn.adafruit.com/adafruit-huzzah-esp8266-breakout/using-nodemcu-lua?view=all#using-nodemcu-lua

Overview: The initial approach implied in the flow of the learn page, using PuTTY, CoolTerm, or Tera Term, is to just copy the example code (via "copy code") then paste that into a terminal. However, this has issues.

Along with me, two other people with the same set up experienced:

  • the random injection of a char which LUA interprets as a CRLF, thus jumbling the code (example follows).
  • a file of just comments sent to LUA (via file send in CoolTerm, for instance) causes the ESP to reset every 8 to 12 lines. (Supplying external additional 3.3v has no effect)
At this point, I'm guessing the LUA interpreter's buffer is too small, or is not processing the chars fast enough, or both.

A fourth person said it worked fine for her/him. (So maybe they're way smarter than the three of us :))


1) Solution: Add a transmit delay between each char. (See "resolution link" below for additional details.)

Suggestion: describe how to download a LUA file into the Huzzah using a terminal, or a tool chain.

2)
Also make sure you have line endings set to CRLF "\r\n"


Good luck finding that critical setting in PuTTY - I went through every possible option, read the manuals, searched extensively on StackExchange, etc., to no avail. Tera Term does have it. (See resolution link below). I also didn't find it in CoolTerm (but didn't dig deep). If it does exist in Screen, down in the bowels of the TTY configs, that one's also tough to find. I have yet to try the Arduino IDE's terminal for this.

If most terminals default to just CR or LF, noobies won't necessarily recognize this (mis)behavior. As you know, but just hint at above, without CRLF set, the LUA interpreter treats the incorrect line ending with either a space or no char at all, jumbling up the code. This is obvious once you understand the problem, but not so much for newcomers as terminals were born and set in another age ... This copied:
Code: Select all | TOGGLE FULL SIZE
while 1 do
  gpio.write(3, gpio.HIGH)
  tmr.delay(1000000)   -- wait 1,000,000 us = 1 second
  gpio.write(3, gpio.LOW)
  tmr.delay(1000000)   -- wait 1,000,000 us = 1 second
end

... turns into this when pasted (into PuTTY, CoolTerm, and Tera Term when CRLF is not set):

> while 1 do gpio.write(3, gpio.HIGH) tmr.delay(1000000) -- wait 1,000,000 us = 1 second gpio.write(3, gpio.LOW) tmr.delay(1000000) -- wait 1,000,000 us = 1 secondend
>>

BTW, I think this is not a good early example because the jumbled LUA read will sometimes start the while loop, and "lock up" the device while providing no output. A tad unnerving.

3) Which leads to another problem: the CP2104 and Huzzah together seem fiddly. When something goes amiss, it can take many tries to get the OS and terminal to sync to the devices again. (I don't think I'm being whinny as I've worked with hardware for decades and at several points became concerned that I'd damaged the devices.) Using Windows as an example OS, I'd recommend saying something like:

" If the device misbehaves, do this:

  • Remember or save your session settings at set up time
  • unplug the USB port - on the computer / hub end, not the CP2104 side
  • fully close the terminal
  • plug the USB port in again
  • look in the device manager to make sure it's there [BTW weirdly, the "new device found" popup doesn't always happen on Win 7 or Win 10],
  • fire up the terminal again and reload / restart the session.
"
Though a PITA, this method works consistently.

Note that unplugging the ESP from the CP2104 while the CP is connected to the computer does gnarly stuff - even when resetting the ESP after reconnecting the two. Unplugging the USB on the CP side *seems* like it should be the same as doing so on the computer / hub side - but lo an behold, it is different. (No clue why - but I've replicated that fiddly behavior many times.)

EDIT: Additional problem when using "copy code" and directly pasting into a terminal. This happens even when inter-char and line delays are used. I'm pretty sure it's caused by the known ESP8266 "yield" issue. Processing WiFi commands gobbles up processor time LUA needs ...
If you just past this into a terminal:
Code: Select all | TOGGLE FULL SIZE
wifi.sta.config("accesspointname","yourpassword")
wifi.sta.connect()
tmr.delay(1000000)   -- wait 1,000,000 us = 1 second

It will frequently fail because the connect() is still at work and won't return in time for LUA to get the input buffer cleanly. You'll get a result similar to:
Code: Select all | TOGGLE FULL SIZE
> wifi.sta.config("ATT666","zippitydodah_isnt_really_my_password")
> wifi.sta.connect()

tmr.delay(>> 1000000)
p>> rint(wifi.sta.status())
stdin:3: '=' expected near 'rint'


____________
Resolution Link - for 1) buffer overflow problem: https://forums.adafruit.com/viewtopic.php?f=19&t=115099&p=576643#p576643


This was a real long haul for something that should be simple!

thanks for your attention
- Howard in Florida

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Re: How thoroughly does Adafruit test products?

by adafruit2 on Thu Apr 13, 2017 5:04 pm

hiya, yes lua is not good for copy-and-pasting, thats part of why, in house, we never use lua for esps

the tutorial has been updated to indicate that its best if you type out the commands.
it has also updated to indicate that we don't recommend it, arduino IDE is better for most people

adafruit2
Site Admin
 
Posts: 19375
Joined: Fri Mar 11, 2005 7:36 pm

Re: How thoroughly does Adafruit test products?

by HowardP on Fri Apr 14, 2017 1:54 pm

Appreciate that you've incorporated this into the tutorial. Those two seemingly subtle changes might have saved me a fair amount of hacking. :))

Although using LUA is now clearly less preferred, it would be helpful to add short clarifications in the "Scanning & Connecting to WiFi" and "Web Client" sections.

There is enough of a LUA lag in processing the wifi.sta.connect() call that the
tmr.delay(1000000) -- wait 1,000,000 us = 1 second

line is moot.

If you copy and paste quickly, or do what we now know is wrong and paste both of those lines at once, the return from connect() is so slow that it will jumble the tmr.delay() line. (It is probably needed if this were saved in a file, say "TryWifi.lua" then calling dofile ("TryWifi.lua"). But file IO is not mentioned in, and certainly is more advanced than, the LUA section. )

In the Wifi Section, when something went wrong, I had to reset the device then redo the Wifi connection and the entire net.createConnection() to sk:send("GET ... block. Otherwise, the sk:send() just does nothing, returning to the LUA prompt. ( Connection limits / "Connection: keep-alive" ? )

And there's this:
Code: Select all | TOGGLE FULL SIZE
sk:connect(80,"54.242.246.241")
sk:send("GET /testwifi/index.html  ...

I was unable to make that work in LUA, but the URL itself had previously worked directly in browser via the same router:
http://54.242.246.241/testwifi/index.html
Ping now shows that IP unresponsive.

Doing the DNS version, sk:connect(80,"wifitest.adafruit.com"), does work as expected. However, trying the IP then the DNS version in immediate sequence is an instance where you have to go through the reset and recode mentioned. (Otherwise it looks like it's working - until you try the send() and get only the LUA prompt.)

Hope you can translate all that into a one-or-two liner :))


cheers
- Howard

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Re: How thoroughly does Adafruit test products?

by adafruit2 on Fri Apr 14, 2017 2:01 pm

hiya we've updated the IP address, its now 104.236.193.178

adafruit2
Site Admin
 
Posts: 19375
Joined: Fri Mar 11, 2005 7:36 pm

Re: How thoroughly does Adafruit test products?

by HowardP on Fri Apr 14, 2017 5:36 pm

thanks, you might be interested in the post mortem I wrote related to this.

https://forums.adafruit.com/viewtopic.php?f=19&t=115099&p=577230#p577230

PS Looking forward to my next batch of Adafruit goodies :)) (Seriously)

- H

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Re: How thoroughly does Adafruit test products?

by d1g1t4Lnrg on Sat May 06, 2017 7:45 am

Hello, Dave from Canada here.
Also, you might want to know that the CP2104 64 bit driver has problems and is flakey with 64bit o/s... from the companies site.
I am using Linux Mint - Mate ver 18.1, 64bit. Which I must say works so much faster than my windows 10 64bit o/s image.

This is on a Dell Optiplex 780, 4gb ram (it does accept up to 16gb though) with Intel Vpro quad core cpu.
If you get a chance to buy one of these definitely do it. Very good system and small form factor with very good power management and low wattage draw.
Have a great day.

d1g1t4Lnrg
 
Posts: 7
Joined: Fri Feb 03, 2017 12:00 pm

Re: How thoroughly does Adafruit test products?

by HowardP on Sat May 06, 2017 2:35 pm

Hi Dave, thanks for the reply and the computer suggestion (looks nice, but I already have too many computers :). I'm fairly certain this particular problem is not in the device driver versions for the CP2104 because I've tested it on Windows 7 (64 bit), Windows 10 (64 bit), Mac OSX (64 bit), and four flavors of Linux (1@64 bit, and 3@32 bit <-- very challenging) --- ALL behave the same way. The problem and it's resolution is described in my longer post & links above. It's the LUA interpreter's inability to consume the in-streaming chars fast enough, so they have to be paced in at a slower rate.

If you think the "companies site" shows otherwise, *please* post a link to that info here so that others can follow up if needed. thx

LUA, it turns out, is quite buggy.

And the 0.9.5 LUA version Adafruit preloaded on the ESP's I have is missing functions from modules that are preloaded. (Weird, but I don't think this is Adafruit's fault. I don't understand the problem yet - see note *1 below ) There's an 0.9.6, but I'm dropping LUA entirely in favor of the Expressif SDK, with concept testing first via the Arduino IDE, as Adafruit suggests. Many people online have had good results with the Arduino set up. And more experienced users say using the SDK is the best route to go, primarily because it eliminates all the extra fluff and crudge of other people's code layered on top of the Expressif base. Yes, there's MicroPython (and Circuit Python?), but those, like LUA, are layers. Yes, the libraries of the interpreter languages look tempting and time saving - until you actually try to do something serious - and then you might waste a lot of time debugging something that's not the fault of your own code!

cheers
-H
____________
Note (*1) - the "tmr" module was last updated in Dec 2012 so all the functions in that module I would think would be available in Ada's 0.9.5 version. But here's where it gets weird: tmr.delay() works, for instance, but local foo = tmr.create() is undefined. Strange. (To replicate the problem, try the OO example located here: http://nodemcu.readthedocs.io/en/master/en/modules/tmr/#tmrcreate)

HowardP
 
Posts: 91
Joined: Fri Apr 03, 2015 6:42 pm

Please be positive and constructive with your questions and comments.