For the A035 (https://docs.m5stack.com/en/unit/neopixel), what voltages should I use if I''m not using the grove connector, both for power and signal? I've seen some indication that maybe 5v for power is needed; would connecting a 3.3 signal work in that case? Don't want to let out the magic smoke!
From https://cdn-shop.adafruit.com/product-files/1138/SK6812+LED+datasheet+.pdf, it looks like--with a 5V supply--Vih is 3.4V, and 3.3V isn't going to hit that. But all those are "typical".
I'm trying to get file, function and line number to display in a message. I found a technique here (https://forum.micropython.org/viewtopic.php?t=7811), and tried to adapt it. It seemed to be working for a bit, but then somehow it stopped. The idea was to force an exception, which should dump a stack trace, then rummage through that. But for some reason, it is only showing the current function:
Traceback (most recent call last):
File "lib/logging.py", line 46, in log
ValueError: foo
'Traceback (most recent call last):\n File "lib/logging.py", line 46, in log\nValueError: foo\n'
line= Traceback (most recent call last):
line= File "lib/logging.py", line 46, in log
INFO:Traceback (most recent call last)::ShowError (2000-1-1 0:0:14): error='WiFi connected'
Here's my code (borrowed in part from https://github.com/m5stack/M5Stack_MicroPython/blob/master/MicroPython_BUILD/components/micropython/esp32/modules/logging.py). Note that I also tried the seek(0) readline() thing from the example I'm copying, but it doesn't matter. In fact, just throwing a straight sys.print_exception(err) and letting it print out still doesn't show the stack.
def log(self, level, msg, *args):
if level >= (self.level or _level):
redirect = io.StringIO()
try:
raise ValueError('foo')
except ValueError as err:
sys.print_exception(err, redirect)
print('%r' % redirect.getvalue())
caller = 'unknown'
for new_line in redirect.getvalue().splitlines():
print('line=',new_line)
if 'logging.py' in new_line:
break
caller = new_line
if caller != 'unknown':
caller = caller_re.sub('[\\1:\\2](\\3)', caller)
_stream.write("%s:%s:" % (self._level_str(level), caller))
if not args:
print(msg, file=_stream)
else:
print(msg % args, file=_stream)
I know from other code that I have that sys.print_exception(err) normally prints the stack, so I'm a bit flummoxed!
Any ideas where the stack trace went?
It there a more recent version of the micropython source than https://github.com/m5stack/M5Stack_MicroPython, which appears to be fairly old? (last updated on Aug 11, 2019). Or is that what's being used currently?
I found https://github.com/m5stack/micropython, which is more recent (Oct 31, 2021), but it doesn't seem to be as complete: For example, the tft code doesn't seem to be there.
On the m5stickc, uiflow's brightness is converted to axp.setLcdBrightness(level). This appears to be between 0 and 100, although 20 is barely visible in the dark.
The core gray doesn't have axp, but one can use lcd.setBrightness(level): This appears to be 0-255 from the doc, but realistically, it doesn't seem to matter above 25 or so. Is this documented anywhere?
@robalstona pin 0 is the clock, not ws, according to the sticker on the back. Don't know if that helps.
Thinking about how to test it: the M5StickC has no speaker.
OK, I have the Core Gray: It has a speaker! But no mic.
Maybe I could hook both of them together...
This is getting way too complicated for the idea I had in mind, which was some responsive blinky lights for Halloween. (Yes, it's next week. Your point?) :) I think I'll use the accelerometer instead.
Thanks! Going off that, I found this post, which points to the M5GO blob, which has
from machine import I2S
Going into REPL:
from machine import I2S
>>> dir(I2S)
['__class__', '__name__', 'read', 'start', 'stop', 'write', '__bases__', '__dict__', 'CHANNEL_ALL_LEFT', 'CHANNEL_ALL_RIGHT', 'CHANNEL_ONLY_LEFT', 'CHANNEL_ONLY_RIGHT', 'CHANNEL_RIGHT_LEFT', 'DAC_BOTH_EN', 'DAC_DISABLE', 'DAC_LEFT_EN', 'DAC_RIGHT_EN', 'FORMAT_I2S', 'FORMAT_I2S_LSB', 'FORMAT_I2S_MSB', 'FORMAT_PCM', 'FORMAT_PCM_LONG', 'FORMAT_PCM_SHORT', 'I2S_NUM_0', 'I2S_NUM_1', 'MODE_ADC_BUILT_IN', 'MODE_DAC_BUILT_IN', 'MODE_MASTER', 'MODE_PDM', 'MODE_RX', 'MODE_SLAVE', 'MODE_TX', 'adc_enable', 'bits', 'deinit', 'init', 'nchannels', 'sample_rate', 'set_adc_pin', 'set_dac_mode', 'set_pin', 'volume']
>>> import wave
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: no module named 'wave'
So at least part of it is there! I found a listing of the class, but no documentation.
Then I found some examples, but they say Micropython after June 2021, so may not apply??
That talks about a "WS" pin, which I found described here.
The schematic shows only 2 pins however: SCL & SDA. The Unit unit :) appears to have WS tied to ground. Mouser indicates that the pin is tied low internally, and that is the left channel, but the arduino code sets it to I2S_CHANNEL_FMT_ALL_RIGHT.
Here's an I2S tutorial.
So, time to play I guess!
The posts are very confusing! Half say that it is i2s, and the Arduino code seems to support that. But the other half say that it is just an adc on port 34, and the micropython examples seem to support that!
I'm interested in using micropython.
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?
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.