ATOM Matrix and UIFLow V1.4.5 extremely unreliable (including behavior with Arduino IDE) / external program needed to get API key
-
a) I did manage to program simple UIFlow / Blockly app into the ATOM Matrix with UIFLow V1.4.5 but i failed to do so consistently and non even one i managed to complete my intended simple application because UIFlow half-froze (both Browswer version and Desktop one) and e.g. in that state i clicked on the Python tab and was not possible anymore to go back to the Blockly tab, nor possible to save the app, so i lost all my work , multiple times!
b) The internal webserver intended for wifi SSID/password configuration to get the API Key as explained in the documentation NEVER showed up and therefore it was necessary to use a console (PuTTY in my case attached to the virtual COM port) to be able to get to the API Key; such simple product is intended to be used by children but requires software engineering know-how to deal with all that "low level" stuff; not good!
c) I also tested the ATOM Matrix with Arduino IDE 1.8.10 and tried some of the about 4 examples given and the behavior was also extremely unreliable, more than one time while or after app firmware download the ATOM Matrix was in an undefined state , nothing shown on the LED Matrix and it was necessary to erase and re-flash the firmware with the Burner. It was not possible to run all examples. -
Hello Juan, I am having the same problem that you experienced it trying to get the API code. How did you do it with Putty? What baud rate? I have connected via Putty on serial coms at both 9600 and 115200 baud and their is no response. My previous M5Stack processors always had the API key printed on the case but not this one - not enough space!
-
in the wifi setup webpage. you can see the API Key in the page head. (or check the serial print).
this link is the ATOM quick start tutorial . you can refer it.
https://docs.m5stack.com/#/en/quick_start/atom/atom_quick_start
-
Here is some feedback about the current version V1.6.3
Quite painful to use:
For instance the first couple hours of playing around:Documents mention python examples of NTP, which is not current/ does not match with the blockly ntp (which does work)
You can use the "online mode" with the flow.m5stack.com online IDE... but probably have to also use the m5burner -> COM port monitor to see all error codes ( i dont think this com port monitor can send the enter key to the serial port?)
If you try to use the desktop-ide : on the Atom, you have to constantly hold the button and reset and boot into "blue" usb-mode. Then you can fiddle around with the desktop-ide to "refresh" then "connect" then load the hopefully latest save of your blockly, then upload the code (dear god dont hit "run" or else who knows if its uploading or running the last code that errored or what)
Then you have to restart the board, can't see any output. Have to close down the desktop-ide, have to open up a third party terminal program such as putty (guess the buad rate since the m5burner says 750000 but that doesnt work, 115200 does seem to work for some reason) Yay I see the error code that ntp doesnt exist.
Ok so now desktop-usb mode is not compatible with any online functionality. I have to add a bunch more code to make sure wifi is connected before I try to set ntptime... i guess i need to do all wifi connectivity manually now, and the built in ntp library doesnt do any error handlingSo its clear the blockly stuff is just a dream and not for practicality, it has no error handling and wont work most of the time without painful amounts of error checking.
It appears none of the development scenarios are designed around the fact you need com-port monitor to see the huge amount of errors that are going to be generated with each new block added
Python is great in theory, but it needs really short feedback loops in terms of error output after every tiny change
-
Here is some feedback about the current version V1.6.3
Quite painful to use:
For instance the first couple hours of playing around:Documents mention python examples of NTP, which is not current/ does not match with the blockly ntp (which does work)
You can use the "online mode" with the flow.m5stack.com online IDE... but probably have to also use the m5burner -> COM port monitor to see all error codes ( i dont think this com port monitor can send the enter key to the serial port?)
If you try to use the desktop-ide : on the Atom, you have to constantly hold the button and reset and boot into "blue" usb-mode. Then you can fiddle around with the desktop-ide to "refresh" then "connect" then load the hopefully latest save of your blockly, then upload the code (dear god dont hit "run" or else who knows if its uploading or running the last code that errored or what)
Then you have to restart the board, can't see any output. Have to close down the desktop-ide, have to open up a third party terminal program such as putty (guess the buad rate since the m5burner says 750000 but that doesnt work, 115200 does seem to work for some reason) Yay I see the error code that ntp doesnt exist.
Ok so now desktop-usb mode is not compatible with any online functionality. I have to add a bunch more code to make sure wifi is connected before I try to set ntptime... i guess i need to do all wifi connectivity manually now, and the built in ntp library doesnt do any error handlingSo its clear the blockly stuff is just a dream and not for practicality, it has no error handling and wont work most of the time without painful amounts of error checking.
It appears none of the development scenarios are designed around the fact you need com-port monitor to see the huge amount of errors that are going to be generated with each new block added
Python is great in theory, but it needs really short feedback loops in terms of error output after every tiny change
