On 7/12/21 7:23 AM, Brian Brindle wrote:
I agree on the risk with the USB ports, you wouldn't typically design
something like this. But I appreciate the out of the box thinking that
got me past that. The current limiting etc can easily be done in the end
device, and that's what I choose to do. In reality, only one person is
likely ever going to use this thing and we are already plugging USB
ports into DB9s so.. Brian did at least consider the M100 user group and
instructed everyone to use plastic DB9s so I think that is sufficient.
Jim - congrats on the new gig. Hope you find some time to play soon. I
used both your code and Brian W's to get my PDDuino going. Found the
re-org of the code very helpful in figuring things out and
appreciated all the documentation. I was chasing a few bugs that it
looks like you guys both sorted out, or moved, in the latest master
branch.
master actually? or latest default branch which is not master but 0.4.1?
I didn't have master marked as default currently because I thought I had
made it worse, you know like the partly-broken point mid-way in a
refactor, so I made the last-known at least basically-minimally-working
version default.
But if you're actually using the master branch that's great and I'll
switch that to default. That is where I started porting Jim's main loop.
I didn't simply merge Jim's whole version because I don't know if I
agree with all of it (mostly just in some details not in the essence),
and I'd rather merge in a bunch of smaller more incremental changes that
each express a specific job or idea, even if it means I have to do it
manually, even if it means in the end I do end up in the same state as
if I just merged the whole thing. If nothing else it makes me understand
everything better.
Biggest thing I saw was the PDDuino would wander off looking for
label information and not respond to drive commands. Like when trying to
load TS-DOS from the UR2 it would fail unless you could force the
PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory,
then it would happily go on to the load step. It is somewhat working now
so I took a break from it, although my M0 still doesn't work and I'm not
100% sure why but I think it's the guy from SdFats fault..
I'd love to know the fix for that. I wrote a whole paragraph in the
front page readme about it just as a bug description to be figured out
sometime.
Bill Greiman says the M0 problem is Adafruit's fault and I think I agree
with him.
You can build it for the Adafruit M0 board without the Adafruit board
support libraries just generic M0 support. Based on what both Bill and
Adafruit said in different support forums, I thought I had a working fix
that addressed the Adafruit libs wrongness while otherwise still using
them, but I think it turned out not to fully fix it, so I was probably
going to give up on the Adafruit libs and just change the code and the
directions to specifically avoid building with the Adafruit board
support files.
So far, actually the lowly 32u4 feather board is actually my favorite.
The teensy's have gobs more power obviously, but for this task the 32u4
does the job so the extra power doesn't matter until we start adding
features beyond straight tpdd. Either feather is better than the teensy
(until you start needing the horsepower) for the sake of:
* asymmetrical pin headers for polarity enforcement,
* built-in lipo manager
* card detect switch,
* ...which an interrupt can be assigned to
* extra on-board led for the card slot
And between the two feather boards the 32u4 feather works more reliably
than the M0 version at least until we fix it, like maybe with different
board support libs or some sort of surgical override within the code
like I tried to do with the SPI clock parameter.
--
bkw
