I'm playing with Teensy 3.5 and 3.6 myself right now. They have sd slot built in and, and of course serial minus the max232, and seemingly gobs more cpu and ram than needed for this task, considering what a real tpdd itself has to do almost the same job. And unlike Tinyduino, the io pins are all accessible directly, no extra breakout board shield needed to hook up the max232-alike. And the "SdFat" add-on library now has native support for the teensy 3.5/3.6 special sd reader.
It seems like these controllers should not have any problem supporting full normal fat32 filesystem and serial and tpdd server, but for lower-spec controllers, it might be an interesting option to just forgo any filesystem or even partition tables and just treat the sd card as raw space the same way the tpdd itself does, like M1SE & M3SE do on Model I/III. It's a lot less convenient for interoperability with other OS's, but it's still interesting and potentially useful compared to an actual tpdd, without requiring a full pc just to run a normal tpdd server. Another challenge is power. Teensy 3.5/3.6 definitely draw way too much power to scavenge from the serial port. But maybe not... Maybe it's possible to have a tiny lipo that charges at 5 or 10ma while the M100 is turned on and the tpdduino is connected but idle? Teensy 3.6 draws 80ma, plus the sdcard itself draws more but only very briefly while operating, and a tiny drone lipo is 150mah, so it could run the teensy for almost 2 hours of continuous use without even getting any power from the M100. That already probably tranlates into days or weeks of normal use between recharges, where the tpdd is really only active for 1 second and then idle for 1800 seconds. So even without parasitic trickle charging, just having a tiny built-in lipo and a microusb port to charge up would already be good enough, but with that kind of extreme duty cycle ratio like 1:1800, charging at even 5 or 10 ma in between transfers is probably enough to keep the lipo charged all the time forever, other than going dead on the shelf while turned all the way off for 6 months. I know modern max232 alternatives can power themselves entirely from the serial port, have their own charge pumps & caps built-in, and power themselves off when there is no serial activity, so the 3.3v or ttl to rs232 would seem to be no problem, in terms of parts or power. On Tue, Aug 21, 2018 at 5:49 PM Brian White <bw.al...@gmail.com> wrote: > This looks great! > > 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
