Posts made by dclaar

Rshell works pretty well, although the newer M5 releases are a lot harder to get into the correct mode, particularly on the atom.

Uiflow is micropython: I have often written something in uiflow and then switched to the micropython side to see what the python is for a given uiflow thing. And then I can cut and paste into repl.

For long-term debugging (fails once a day or week), I leave the device connected to putty.

I have considered adding code that would catch Exception () in the main loop, do a stack trace, and save it into a file so that I don't need it to always be connected, but have never implemented it.

@medy mostly:

print(dir(wifiCfg))
print(wifiCfg.__dict__())

I'm sure that someone has written a function that formats all this, recurses, etc, but I usually just do it manually, because there are usually only a few things that make sense to try.

Also googling for micropython wifiCfg (or whatever), because micropython is not just for M5, and a lot of the code is on the internet. It's not always exactly the same, but it often is, or is close enough to provide hints for more things to look at.

I'm assuming that you know how to use rshell or some other tool to get to repl so that you can just type in statements as they occur to you, rather than writing a script for every new thing you want to try.

@keesjan With micropython, port 22 works fine, and as expected:

CDS_PIN = 33
TX = 19
RX = 22

As an aside, the idea that the labeling of the pins is "oriental logic" shows an unawareness of the history of rs232 and is a bit insulting. The question of what to label the pins depends on whether the manufacturer thinks of the device as DTE or DCE: StackExchange has a good explanation of the history.

In particular:

'some manufacturers try to "help" by effectively labelling their DTE equipment as if it was a piece of DCE. They mark their data input pin as Tx so that user just connects "Tx" from the external device (which, if it's DTE, will be the data output from there) to the pin marked "Tx" on their equipment (which they know is an input). Thereby allowing them to say "just connect Tx on your device to Tx on our equipment". They think they are trying to help, but such labelling often just adds to the confusion.'

Hmm, OK, get_wifi() works on 1.5.4, so maybe I just guessed wrong back then.

Some time ago, I asked where the wifi config was held.
At that time, the answer was:

 import wifiCfg
      self.ssid, self.password = wifiCfg.deviceCfg.wifi_read_from_flash()

Fast forward to 1.7.0:
I have set the WiFi credentials with M5burner 2.2.2 via "Configuration". But the above returns an empty list, rather than actual credentials.

Apparently the new hotness is:

wifiCfg.deviceCfg.get_wifi()

It's a bit frustrating when this keeps changing, and there's no user-visible notice, just broken code. Can we get some kind of announcement of functionality-breaking changes?

Re: Running code with rshell?

I had rshell working for a while, but now it is failing. I filed https://github.com/dhylands/rshell/issues/138, but I wonder if it is because of the fancy UISHELL ascii logo?

This is on the Atom Mini, so it's a bit tough to figure out!

I'm running v1.6.2-lite on it, and REPL says:

MicroPython 400ff3bbf-dirty on 2020-08-06; M5Stack with ESP32

Thanks, once I got the other computer to see the device (can't flash a device that doesn't show up in device manager), I was able to reflash it.

Then I took it back to my laptop, and it still wasn't seeing it. So I switched USB cables, and it did. Then I switched back to the original USB cable, and it worked with that cable again. (Note that I had hooked up a M5StickC via the original USB cable, and it is working fine with that cable now, so the cable isn't bad).

Gotta love Microsoft Windows sometimes.

This was the super-frustrating "windows doesn't recognize a device. But a different windows computer does". :(

I hooked up a 10K resistor and a CDS cell (resistance 50k-1M) in series from 3v3 to GPIO36. I set the pin to ADC mode, and was reading between 3000 & 4095.

But now the gray isn't working. It doesn't show up as a serial port on the PC. If I try playing the built-in rock/paper/scissors, it goes black as soon as I push a button (https://claar.org/gray.mp4).

So, did I kill my gray? If so, what did I do wrong? I don't want to repeat with another piece of hardware!

Google suggests that 10K should be plenty as a pullup, and an ohm meter shows that the resistance goes between ~60K to 1+M, so I didn't use the wrong resistor (and the CDS is 50K in any case).

I guess I misunderstood what support said: "If you are connecting through 3.96 terminal, 12V DC is required" seemed to say that I needed 12V to use the serial pins.

The http block you are using is for talking to a web site, not for being a web site. Or in more technical terms, it is a client, not a server. If you had a web server on your laptop, it could talk to that.

Looking at the other options, it looks like EspNow can listen for data, but I don't know if there's a laptop client.

mqtt is a client that needs a cloud-based server.

There's a p2p option under network, but that seems to be for talking between 2 devices.

Finally, there's remote, which it says "Remote control M5Stack via devices such as mobile phone or computer." I think that's your best bet.

I'm not patient. :) I broke down and bought this, although I don't know what I'll do with the other 4 units.

I was really excited about the new rs232 Atom kit, but unfortunately it requires 12V to power it, which it converts to 5V to power the Atom. I can see how that could be cool if you had full serial and could use one of the control lines. But I only have the minimum 3: Tx, Rx, Gnd.

So what are folks using to talk to "real" (full 12V) serial devices? I have some max232 chips laying around, but they're 5v, and the ESP32 spec sheet shows a max of 3.6 for pin input. I may have a level shifter somewhere, but that seems like overkill.
I guess I could get a 3.3V max232, but I'm kind of surprised that there's no ENV or HAT for this.

Hmm, but I can connect with the M5Stack extension in VSCode, although the Pymakr Console won't connect. I must just be missing something.

Ooh, in putty, if I type control-c, then I get to repl! So maybe rshell needs to do that.

I'm on windows. I've tried putty as well: It prints the banner and stops. Maybe I have the wrong baud rate (I'm using 115200) or something, but one would think that the display of the banner would fail then as well. For example, with M5Burner Beta's "COM Monitor" (button in the upper right-hand corner), typing os.listdir() and hitting Send gives me a crc error2k. This is only with 1.5, 1.4 worked fine.

I used the M5stickC to display air quality information from a Purple Air sensor. You can read my blog post:
https://seeingclaarly.blogspot.com/2020/05/seeing-airquality.html

And the code is on github:
https://github.com/dclaar/purple_air

This new setup makes it incredibly difficult to get to repl, e.g. with rshell: It works maybe 1 times out of 20.
M5Burner Beta com monitor doesn't work. The pymakr console extension to VSCode doesn't work. They all seem to get stuck at:

AutoConnect enabled, ignoring 'address' setting (see Global Settings)
Searching for PyCom boards on serial...
Connecting to COM7...

       _  __ _
 _   _(_)/ _| | _____      __
| | | | | |_| |/ _ \ \ /\ / /
| |_| | |  _| | (_) \ V  V / 
 \__,_|_|_| |_|\___/ \_/\_/  

APIKEY: 6<numbers>

OK, I found it, but the amount of time that I have to hit the button is really short.
It is really hard to hit the button fast enough, particularly if I have had to "hold down A and press power" to reboot! Can we have an option back in settings as well?

I posted this in M5stickC, so I thought that was implied: I have the M5stickC. With 1.4.5.1, one goes into settings and chooses "USB Mode".
With 1.5.4, Settings doesn't show a USB mode, just
Startup hold (which seems to do nothing), New Apikey, Wi-Fi Select, WiFi via-ap, and Reboot.

Also, I was unable to go back to 1.4.5.1 with the new firmware burner: It says that the firmware is too big. The old burner does just fine however. I did erase between.

=================
Start Burn
=================
--chip esp32 --port COM7 --baud 750000 --before default_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x400000 C:\Users\dougm\Downloads\UIFlow-Desktop-IDE\packages\fw\other\wifi.bin 0x1000 C:\Users\dougm\Downloads\UIFlow-Desktop-IDE\packages\fw\stickc\UIFlow-v1.4.5.1.bin
=================
esptool.py v2.5.0
Serial port COM7
Connecting...
.
.

Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse
MAC: d8:a0:1d:57:55:e0
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 750000
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB

A fatal error occurred: File C:\Users\dougm\Downloads\UIFlow-Desktop-IDE\packages\fw\other\wifi.bin (length 100) at offset 4194304 will not fit in 4194304 bytes of flash. Use --flash-size argument, or change flashing address.
=================
 Burn Failed 
=================

Old:

Command:
--chip esp32 --port COM7 --baud 750000 --before default_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 application_0x10000.bin 0x1000 bootloader_0x1000.bin 0x210000 fatfsImg_0x210000.img 0x8000 partitions_0x8000.bin 0xf000 phy_init_data_0xf000.bin 0x3ff000 wifi_0x3ff000.bin
===================================================
esptool.py v2.5.0
Serial port COM7
Connecting.......
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse
MAC: d8:a0:1d:57:55:e0
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 750000
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 1970368 bytes to 1380945...
...
Writing at 0x00160000... (100 %)
Wrote 1970368 bytes (1380945 compressed) at 0x00010000 in 23.5 seconds (effective 669.8 kbit/s)...
Hash of data verified.
Compressed 22720 bytes to 14210...

Writing at 0x00001000... (100 %)
Wrote 22720 bytes (14210 compressed) at 0x00001000 in 0.2 seconds (effective 759.4 kbit/s)...
Hash of data verified.
Compressed 2027520 bytes to 125710...
...
Writing at 0x0022c000... (100 %)
Wrote 2027520 bytes (125710 compressed) at 0x00210000 in 2.6 seconds (effective 6144.1 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 125...

Writing at 0x00008000... (100 %)
Wrote 3072 bytes (125 compressed) at 0x00008000 in 0.0 seconds (effective 1540.2 kbit/s)...
Hash of data verified.
Compressed 144 bytes to 69...

Writing at 0x0000f000... (100 %)
Wrote 144 bytes (69 compressed) at 0x0000f000 in 0.0 seconds (effective 72.2 kbit/s)...
Hash of data verified.
Compressed 100 bytes to 37...

Writing at 0x003ff000... (100 %)
Wrote 100 bytes (37 compressed) at 0x003ff000 in 0.0 seconds (effective 50.1 kbit/s)...
Hash of data verified.

It doesn't seem to allow for USB programming!