I think my problem was simply overfilling the small amount of ram on this
controller. I don't get any warning about that from the Arduino IDE at
compile-upload time, but,
* All the example sketches still worked fine, just this one version of my
own sketch caused the problem, same laptop, without even rebooting to
re-init the kernels usb stack or systemd or udev etc. So, that
inconsistent with a hardware or OS issue anywhere in the chain.
* One of the main facets of my most recent changes was I added a whole lot
of debugging output. I think I just used up too much space with
static/literal strings in all those Serial.println("lots of verbose
stuff...")
quoted literals.
The compiler only said board was only 70% used, but maybe the quoted
literals all have to come from some specific chunk of the total space.
I went through and left all my other recent changes, including sleep
behaviour and some sring/array manipulation for dmeLabel() during other
operations, but just #ifdef'd out about half of the debug prints, and it
started working again.
I now have *other* problems, because the stuff I was trying to work on
doesn't actually work yet.
... yeah the web site says it has 32k of flash but only 2k of ram,
meanwhile, the now-running-again version compiles saying:
"
Sketch uses 19260 bytes (67%) of program storage space. Maximum is 28672
bytes.
Global variables use 2318 bytes of dynamic memory.
"
So, I guess it still can't be really working fully with 2318 bytes used out
of 2048! even though at least it gets through setup(), and loop() loops,
and Serial works again.
Aside from reducing ram usage by just removing stuff, I guess I now care
about tricks like the F() macro which compiles static data into flash
rather than ram.
On Thu, Sep 20, 2018 at 8:12 PM Kevin Becker <ke...@kevinbecker.org> wrote:
> I’ve got a max232 I was using to talk to the GPIO pins on a raspberry pi
> that I was planning to use with this. I’ll most likely use Linux for the
> programming but I have a few Macs I can use too. No windows though.
>
> On Sep 20, 2018, at 7:12 PM, Brian White <bw.al...@gmail.com> wrote:
>
> I'm continuing to hack on it, but now my own current local version isn't
> working any more. I'm *this* close to having the top-right corner of ts-dos
> display the current working dir instead of the static string "SDTPDD". But
> the version currently posted on github still works and does at least have
> the disk activity led and pretty good working sleep so it idles at 3ma, yet
> wakes back up as soon as ts-dos does anything. The al32u4 branch remember
> not master. master is Jimmy's version untouched. That works too, just no
> sleep so it draws more power, and no led activity. Do you have a rs232
> level shifter? you need that too. and you have to bridge dsr & dtr on the
> M100 side (I would also tie in dcd to those on general principle but I
> don't think ts-dos cares, and it doesn't care about rts/cts either. You can
> ignore those and leave them open or short them. Only the M100 needs to see
> the dtr/dsr short, not the arduino, so you do it on the rs232 side of the
> rs232 tranceiver.
>
> The sleeping current draw is pretty dependant on the sd card. If you have
> 10 different sd cards, you'll have 10 different sleep currents.
>
> So far these Adafruit 32u4 boards seem to have alot more delicate boot
> loader than the Teensy. The Teensy just about always works. When I hit the
> reset button, their special programmer pops up and it's practically a
> guarantee that it will program. The adafruit boards keep disappearing from
> the bus and depending on what code is currently loaded in the board, I
> sometimes have to retry programming 50 times to get it to go. I'm on linux
> though not windows so maybe the windows version of everything works better.
> (I've already googled up,the stuff about removing modemmanager and
> installing udev rules to set group perms on the dev nodes etc, but there
> could still be systemd crap going on. Or it could just be the kernel du
> jour. I haven't tried booting back to something like 4.16.x or the distro
> official kernel yet.
>
> So, if you have trouble programming, don't give up. It was a bit finnicky
> to get it working initially, but then once it was working, it was working
> more or less fine for me for a week or more straight. Then just in the last
> day or so something changed. I even got another of the same board just see
> if maybe I fried my original one. (There is a store within driving distance
> that has them right on a peg board, like Radio Shack should have had
> instead of cell phones) The new board behaves exactly the same as soon as I
> flash my current buggy code on it. It seems to depend on the code running
> on the board. Even though the reset button kicks out of your code tonthe
> bootloader, your code still kicks back in after a few seconds, and it seems
> like some code is worse than other about what happens next, whether the
> /dev/ttyACM# device will disappear or stay.
>
> On Thu, Sep 20, 2018, 4:49 PM Kevin Becker <ke...@kevinbecker.org> wrote:
>
>> My adafruit logger arrived today. Not sure if I'll get a chance to try
>> this out tonight but sometime in the next few days I hope to give it a try.
>>
>>
>> On Mon, Sep 17, 2018 at 1:04 PM, Stephen Adolph <twospru...@gmail.com>
>> wrote:
>>
>>> If I were going to mount this inside the M100, I would
>>> 1) retask the modem port to be directly connected to this
>>> 2) use a patched main rom to allow modem port to run at 19.2
>>> 3) directly wire it to the battery voltage (after the on/off switch)
>>>
>>>
>>>
>>> On Mon, Sep 17, 2018 at 11:37 AM Kevin Becker <ke...@kevinbecker.org>
>>> wrote:
>>>
>>>> This is pretty cool. I think I might have to check it out. It might
>>>> be an excuse to finally get a 3d printer too.
>>>>
>>>> On Sun, Sep 16, 2018 at 10:35 PM, Brian White <bw.al...@gmail.com>
>>>> wrote:
>>>>
>>>>> There's the entire kit for SD2TPDD on an Adalogger 32u4.
>>>>>
>>>>> https://photos.app.goo.gl/N2v6iB45pePNFQNA8
>>>>>
>>>>> Bam. Couldn't be sweeter.
>>>>>
>>>>> On Sun, Sep 16, 2018, 9:56 PM Brian White <bw.al...@gmail.com> wrote:
>>>>>
>>>>>> SD2TPDD works without modification on an Adafruit Adalogger 32u4
>>>>>> Your original code not my hacked up version I mean.
>>>>>> Even the chip select is already correct out of the box.
>>>>>> https://www.adafruit.com/product/2795
>>>>>>
>>>>>> This board doesn't have the cpu, ram, or other hardware to do some of
>>>>>> the other facy ideas you could do with the Teensy 3.6 like cassette files
>>>>>> and rtc, but it's perfect for tpdd-on-a-stick.
>>>>>> What's cool about it is:
>>>>>> * It runs your code just as it is.
>>>>>> * usb programming/charging port built-in.
>>>>>> * sd card reader built in.
>>>>>> * lithium battery charger circuit and standard battery pack connector
>>>>>> built-in, so you can power it from a little lipo battery, connected by a
>>>>>> standard plug so it's removabel/replaceable, charges by the same built-in
>>>>>> usb port as used to program it. There's an extra led on the board that
>>>>>> shows when the battery is charging. Goes out when done charging.
>>>>>>
>>>>>> With the rs232 module connected and an sd card inserted, it draws
>>>>>> about 12.7 ma @ 3.7v
>>>>>> That's about 27 hours from a 350mah battery pack which is still
>>>>>> pretty tiny battery.
>>>>>> And to recharge the battery, just plug in any usb charger to the usb
>>>>>> port. You could run off the usb port indefinitely too, with or without a
>>>>>> battery.
>>>>>>
>>>>>> Unlike the Teensy, this board also has
>>>>>> * card detect pin. You can use this to detect when a card has been
>>>>>> removed/inserted and re-init the card automatically.
>>>>>> * extra led near the card reader on it's own pin, aside from the
>>>>>> regular arduino pin 13 led.
>>>>>> * card reader socket is push-in push-out type.
>>>>>>
>>>>>> Teensy card reader just holds the card by friction, has to stick out
>>>>>> a little to leave something to grab to get back out, and there is no
>>>>>> card-detect pin.
>>>>>>
>>>>>> I'm already doctoring up a version of the code to take more advantage
>>>>>> of this board, like using the cardreader led and hopefully getting sleep
>>>>>> mode to work and the card detect pin.
>>>>>> But it's already a functional tpdd right out of the box.
>>>>>> --
>>>>>> bkw
>>>>>>
>>>>>> On Mon, Aug 20, 2018 at 4:31 PM c646581 <c646...@gmail.com> wrote:
>>>>>>
>>>>>>> I have a project that uses an Arduino Mega to emulate a TPDD.
>>>>>>>
>>>>>>> https://github.com/TangentDelta/SD2TPDD
>>>>>>>
>>>>>>> I have plans to eventually sell easy-to-use shields that provide the
>>>>>>> RS232 level shifting and SD card interface.
>>>>>>>
>>>>>>> On Mon, Aug 20, 2018, 16:02 Brian White <bw.al...@gmail.com> wrote:
>>>>>>>
>>>>>>>> A tpdd emulated in low level basic hardware in line with the tpdd
>>>>>>>> itself really appeals to me.
>>>>>>>>
>>>>>>>> I would love to try to make it work on a tinyduino, or maybe a
>>>>>>>> gotek. Tinyduino may not seem "basic" being so small and modern, but
>>>>>>>> it's a
>>>>>>>> microcontroller not a PC. It doesn't run linux and systemd and bash and
>>>>>>>> getty and python and a tcp stack and ssl and X and gnome etc etc etc.
>>>>>>>>
>>>>>>>> The fact that an entire pc fits in a tiny space and uses no power
>>>>>>>> and costs $5 today thanks to the plain advancement over the passage of
>>>>>>>> time, is sort of beside the point. Sure it's practical, but it's not
>>>>>>>> *elegant*, in some intangible abstract mental way.
>>>>>>>>
>>>>>>>> You could run dlplus or laddie from an init script on an Omega2 and
>>>>>>>> stuff the entire thing inside of a db25 connector shell, and probably
>>>>>>>> even
>>>>>>>> scavenge enough power right from the usb port with charge pumps, and
>>>>>>>> the
>>>>>>>> entire thing would be small and cheap and relatively easy to do, since
>>>>>>>> it's
>>>>>>>> just sticking a few existing things together like legos. Outwardly this
>>>>>>>> makes all the sense in the world. But it's just such a brute-force
>>>>>>>> kind of
>>>>>>>> solution. I'd rather spend all kinds of time and effort to do the same
>>>>>>>> thing with a controller in place of the computer.
>>>>>>>>
>>>>>>>> Though, you can sure get a lot more functionality out of a
>>>>>>>> computer, like that virtual modem in mcomm. And the computer is
>>>>>>>> infinitely
>>>>>>>> more end-user hackable. It would be neat to play with hacking together
>>>>>>>> some
>>>>>>>> sort of front-end dispatcher script, kind of like inetd for serial or I
>>>>>>>> guess that would just be an amped-up getty, maybe even with an
>>>>>>>> interactive
>>>>>>>> menu that you can access via TELCOM, and the front end runs a tpdd
>>>>>>>> server
>>>>>>>> or a dos injector or ssh client or lynx or virtual modem or something
>>>>>>>> else
>>>>>>>> and hooks it to the tty. It could stay in the loop monitoring the tty
>>>>>>>> for
>>>>>>>> special escape commands to break out into a command mode just like
>>>>>>>> modems,
>>>>>>>> telnet, ssh, cu etc all do, so you could always switch between
>>>>>>>> functions
>>>>>>>> from the M100 even after starting one.
>>>>>>>>
>>>>>>>> gahh ideas are sure easy to throw around :)
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> bkw
>>>>>>
>>>>>
>>>>
>>
--
bkw
