[Open_electroporator] pyflex_f401 v0.6 prototype #2 turn on -- USB mass storage problems
john at cibolo.com
Sat Aug 4 19:52:30 UTC 2018
On 08/04/2018 01:09 PM, Nathan McCorkle wrote:
> Can you give steps to reproduce? I've said in the past, I've not experienced using the usb mass storage as affecting much in a
> negative way aside from running out of space due to the recycle bin hidden files.
Sure, but on the new hardware. So you may not be able to reproduce it until you've rewritten it, and it would be better
use of your and my time to have some new hardware of your own.
I can't see supporting it being easy with stuff like needing to know to delete hidden files, and/or forced to upgrade MCU
to larger memory, and occasional intermittent failures. A couple of others corroborate this from micropython: dhylands and
pythoncoder. I've asked about this and Damien George is silent on it. Maybe he likes the adafruit sales
and simplistic uses of micropython and has moved on from there, leaving others to self-help.
Damien's posts to announcements forum lately are
Thu Jul 23, 2015
Tue Oct 20, 2015
Thu May 05, 2016 12:03 pm
Wed May 24, 2017
Wed Feb 07, 2018
The rest of the 20 news items are by pflacon, torwag, deshipu, mostly.
deshipu once said the USB mass storage is too good for beginners to lose, even if problems.
Not much is happening by Damien George anymore, so no big changes to micropython, so need to learn how to use it as is
without changes or do them yourself, and that kind is out of the scope of my culture shock project.
It needs to be dependable and I don't see how using rshell to update programs is so bad. Rshell cuts
out all the rendomness caused by USB mass storage failings.
The way the micropython USB mass storage causes a pop up on a linux computer attached to its USB after 10 or 12 seconds
is slow and lame for development. I'm convinced to go back to disabling USB mass storage so rshell is needed.
I want to skip that problem and get on to economic survival selling hardware with working dependable software soon.
> I will note that calling pulse() at the end of reset (I think hard or soft) never successfully worked for me (to initiate a pulse
> train right, i.e. after plugging in)... I had to manually call pulse() from the REPL (didn't try calling based on say an external
> button push).
> Maybe that issue is somehow related to what you're seeing.
Yes, it could be the 10-15 second delay of USB mass storage, and it doing something that upsets the GPIOs...
Is there something in pulse() we need to call once after reset, outside
> of the pulse() function?
Yes, pulse() needs looking at.
More information about the open_electroporator