Hello Frank, and welcome to the list.
fra...@fraber.de writes: > Hi! > > > Summary: I believe you could greatly increase the > number of Amforth users with little effort providing > one Wiki page per hardware device. There you would > provide fuse settings, name of a suitable binary, > parameters for the flasher etc. in order to reduce the > frustration of a rookie to see the first Forth prompt. > It's only 20-50 devices, that's not much compared to > the list of devices in Arch Linux for example (I found > my specific laptop model there...). > SourceForge offers a Wiki very suitable for that! * wiki pages: Well, maybe. However man- or woman-power is the key resource to this. I will certainly not start such a thing on my own. Moreover, I'm convinced that reading a datasheet and having "control" over your board is worth more than writing more documentation --- which will be outdated sooner than you wish. > In Detail: > > I'm a fellow open source guy, running a project > here on SourceForge for a living: > https://sourceforge.net/projects/project-open/ > Also, 30 years ago I wrote a Forth for Inmos > Transputers... Cool! I have not written my own Forth, and I have resisted the urge for over 10 years. I just try to keep this project alive after the original author had to abandon it. > So: Congratulations to your work on Amforth! > I managed to get it running on a barebone AtMega > 328 for a hobby project (a tracked robot with my > son...). > > I implemented drivers for both stepper motors > and DC motors with angle coders without too much > trouble and to send Forth commands over SPI. > > However, I got some trouble trying to connect > multiple 328s to a single RasPi and finally serious > trouble with spikes from the DC motors affecting > the SPI bus :-( You absolutely must provide separate power supplies for the controller and for the DC motors. I would not even share the same ground. Use opto couplers and appropriate diodes and capacitors to filter the effects of the motors. Other projects have solved this sort of thing, just hunt for them. https://roboternetz.de/ is one. > For the next iteration I'd like to decouple the > various I/O subsystems electrically and use UART > over USB for communication in order to address the > issues both with multiple devices (USB hub as PI > HAT) and noise (USB has differential signaling...) > > So, I'd like to use a 32U4 or Mega 2560 or similar > for each subsystem and a RasPi Zero W as a base, > but I haven't yet purchased anything. > Here some information on the supported features > would come in handy. I've spent several hours > trying to understand if/how Amforth supports > USB/UART in these model. 6.9 doesn't seem to > support it at all, correct? > > > There isn't much space in a robot, and USB cables > are surprisingly bulky. And now imagine that I'd > somehow need to have 2x USB for each Atmega... * USB is, well, not cool. I would never even try to build something on USB, should my life depend on it. I have seen way too many difficulties with industrial anything on USB. Keep it simple! If you come up with patches to make usb on the 32u4 work, I shall look into integrating them. And I'm sure there are more readers on the list, who would try them. > I wonder if I'm the only one trying to build a more > complex system using Amforth or if others had > similar problems... > > I have also found very few postings in the Internet > from people connecting multiple Arduinos to > a RasPI or to build bigger projects in general. > That's precisely where I see the value of Amforth, > because it introduces a protocol layer that is > easy to debug and decouples the subsystems. * robot or other complex system: If you play with software (no matter which one exactly), you are not dealing with software alone. Never. You are dealing with hardware (printed circuit board, components, chips, cables! and connectors!), power (there is much to be learned about power supplies), signals and impedance (like it or not), a programmer, an assembler, and finally the software system itself. You cannot run this software in empty space. I myself have a modestly complex setup with atmega32 controllers on a RS485 bus. The software I wrote using AmForth 4.6 is running since maybe 10 years with very few hiccups. However: I have failed miserably to recreate this system with AmForth 6.8+ on nice and shiny boards with atmega644pa controllers. And I have no idea, why. It works for some time and then all of a sudden the controller stops dead in it's tracks and blocks any access. Very interestingly: a reset or power cycle does *NOT* help. So I'm currently completely out of ideas. The essence of this is: start very simple. Try to make your project run for extented periods of time. And see where it gets you. If you tend to use an ARM controller, do not hesitate to try Mecrisp (Author Matthias Koch). Mecrisp is a native Forth and not an indirect threaded one. I have no experience with arm controllers, so others on the list may have a say. Yes, I know, the initial hill is steep. Should you decide to climb it, the mailing list is there to help. The Archives harbour lots of hints, too. The fuse settings can be found in appl/arduino/Makefile. Did you see them? Using forth itself as a protocol to talk to other controllers has been tried in at least 2 places, one is not public, the other is this: Vierte Dimension 2016/1 page 9ff Salvatore Gaglio et al. -- Use of Forth to Enable Distributed Processing on Wireless Sensor Networks (english text) https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf and references therein. Happy forthing! Erich > Cheers, and keep up the good work! > Frank _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
