WiPy first impressions
WiPy unboxing doesn’t take but a few minutes. The WiPy setup information on http://docs.micropython.org/en/latest/wipy/wipy/general.html is concise, complete and should be your first stop. What you will need to bring along is your WiPy with expansion board and four pieces of software:
Since the usb to serial link is made in an FTDI chip on the expansion board rather than the ARM chip on the WiPy, the uart serial connection doesn’t time out, and stays connected across hard and soft boots, however power cycling the expansion board does of course reset the FTDI chip. To soft reboot the WiPy from the repl, import sys, then type sys.exit(). To hard boot from the repl, import machine, then type machine.reboot(). Hard booting should be the same as pressing the reset button on the WiPy, but sometimes the reset dosn’t fully take, so a true power cycle may be necessary. In docs on other processors, they warn to make the cpu the first thing to get power, and the last thing to get powered down. Whether it's necessary in this case, it's a habit, so I'll always pull both the USB and battery connectors first. Power cycling the expansion board resets the FTDI UART serial to USB converter chip, so it’s necessary to press the connect button in Cutecom. If you make changes that don’t seem to stick, try power cycling.
The output drive capability of the WiPy pins is around 6 mA when configured for maximum strength. That’s not much. To buffer the MCU’s output pins I added a 74HC573 “octal D-type transparent latch” running on its own 3.3V wall-wart.
The WiPy uses pin 28 for safe boot mode and for selecting the micropython version at boot as described in the WiPy general.html link . Safe mode helps you fix a broken main.py or boot.py by causing the WiPy to boot without the startup files. From there you can ftp up a better boot.py, then reset the WiPi to make it effective. It’s a nice feature. My boot.py changes often. Here’s today’s version. It’s pretty bare bones.
-
a telnet session running in a terminal window
-
the filezilla ftp client
-
a serial port terminal
-
a text editor
Cutecom is duplicating the repl running in the telnet session in the terminal emulator window.
The Filezilla FTP client is quite full-featured.
For the true traditional feel of crash-and-burn microcontroller programming, you can edit your python files on your PC then ftp them to /flash on the wipy. Not Pythonic. For admin and testing small stuff, the Python repl prompt works. You can telnet to the WiPy and use the repl there, and/or you can echo the repl to a serial terminal program. The telnet interface to the repl has the advantage of remote access, however the telnet connection will time out after 5 minutes of no activity. Since I often stop repl-ing for more than 5 minutes to read the docs, the timeout means I have to re- log-in more often than I’d like. There are a couple of ways to improve the timeout situation. One way is to reconfigure the WiPy telnet/ftp server to have a longer timeout. Instead, I prefer to connect a USB cable to the laptop and use os.dupterm(uart) in boot.py to duplicate the repl session in a serial terminal emulator. I use Cutecom (Linux) on /dev/ttyUSB0. There is no network login required. Pressing the “connect” button in Cutecom instantly opens the serial port and pressing the return key shows the repl.
Since the usb to serial link is made in an FTDI chip on the expansion board rather than the ARM chip on the WiPy, the uart serial connection doesn’t time out, and stays connected across hard and soft boots, however power cycling the expansion board does of course reset the FTDI chip. To soft reboot the WiPy from the repl, import sys, then type sys.exit(). To hard boot from the repl, import machine, then type machine.reboot(). Hard booting should be the same as pressing the reset button on the WiPy, but sometimes the reset dosn’t fully take, so a true power cycle may be necessary. In docs on other processors, they warn to make the cpu the first thing to get power, and the last thing to get powered down. Whether it's necessary in this case, it's a habit, so I'll always pull both the USB and battery connectors first. Power cycling the expansion board resets the FTDI UART serial to USB converter chip, so it’s necessary to press the connect button in Cutecom. If you make changes that don’t seem to stick, try power cycling.
The output drive capability of the WiPy pins is around 6 mA when configured for maximum strength. That’s not much. To buffer the MCU’s output pins I added a 74HC573 “octal D-type transparent latch” running on its own 3.3V wall-wart.
www.nxp.com/documents/data_sheet/74HC_HCT573.pdf
I picked this chip because had a few laying around my shop. Tying the ‘573’s LE pin high and *OE low, the data passes through transparently. Vcc is 3.3 volts from an external supply. The 74HC573 has a very nice straight-through pinout that makes it easy to see where the ins (Dx) and outs (Qx) connect in your circuit. The ‘573 chip is only being used as a buffer chip, not a level translator.
The WiPy’s Pin 28 is special in that it allows you to intervene in booting. The WiPy allows for up to three resident versions of micropython. One of those is the factory version, which can’t be altered (You can’t brick a WiPy). The user can install up to two other versions of micropython. To choose between them use the heartbeat LED blink codes.
The WiPy uses pin 28 for safe boot mode and for selecting the micropython version at boot as described in the WiPy general.html link . Safe mode helps you fix a broken main.py or boot.py by causing the WiPy to boot without the startup files. From there you can ftp up a better boot.py, then reset the WiPi to make it effective. It’s a nice feature. My boot.py changes often. Here’s today’s version. It’s pretty bare bones.
# boot.py -- run on boot-up
# out of box net setup incl ftp, telnet
# https://docs.pycom.io/wipy/wipy/general.html
from network import WLAN
from machine import UART
import machine
import os
import micropython
# 100 byte debug buffer for broken interrupt code, etc.
micropython.alloc_emergency_exception_buf(100)
# duplicate the repl in the serial terminal
uart = UART(0) # from github wipy tutorials
uart.init(baudrate=115200, bits=8, parity=None, stop=1)
os.dupterm(uart)
SSID = 'REDACTED' # SSID of your home network
AUTH = (WLAN.WPA2, REDACTED') # WPA secret as 2nd param
IP = '192.168.1.99' # Fixed IP the device should get
ROUTER = '192.168.1.254' # IP of your router
DNS = '68.94.156.10' # IP of your DNS server
NETMASK = '255.255.255.0' # Netmask to use
# https://docs.pycom.io/wipy/wipy/tutorial/wlan.html
# Notice how we check for the reset cause and the connection status, this is
# crucial in order to be able to soft reset the WiPy during a telnet session
# without breaking the connection.
wlan = WLAN()
# if last reset was soft, network is still active & in STA mode
if machine.reset_cause() != machine.SOFT_RESET:
wlan.init(WLAN.STA)
wlan.ifconfig(config=(IP, NETMASK, ROUTER, DNS))
if not wlan.isconnected():
wlan.connect(ssid=SSID, auth=AUTH, timeout=5000)
#wlan.connect(ssid=SSID, auth=AUTH, timeout=60)
while not wlan.isconnected():
machine.idle() # save power while waiting
print('WLAN connection succeeded!')
# run this after boot.py
# machine.main('blink-isr-lambda-1.py')
----------
Ed Bennett
ed @ Kinetics And Electronics . com
Leave a comment