Hi Erich,
Thanks for welcoming me to your community. Thanks to everybody for the constructive feed-back and the good pointers!
reading a datasheet
In my case I first found Amforth and then I read the datasheet. I believe that's true for 95% of potential users. Is being able to read datasheets a precondition to using Amforth? This would keep out 95% to 98% of potential users... Actually, we are doing something similar at ]project-open[, we call it "customer self-selection" :-) Only users with experience in SAP / ERP understand our system. But in our case it's not intended... We use a Wiki to document our internal procedures because it is so little effort... George Herzog wrote:
USB is to some extent proprietary, where as RS-232, SPI, and I2C are easier to deploy.
I mentioned that SPI failed for me completely in a bus- like setup (a stack of multiple PCBs with connectors on one side). I guess that's because it requires a common GND between all components. Also, debugging via SPI didn't work. There were several debugging sources in Amforth that sent stuff directly to the UART so that I needed a serial port anyway :-( And in my setup I'm not ready to replace the RasPI with anything else, because it's great for WiFi and we plan to run some AI functions.
If you come up with patches to make usb on the 32u4 work
Tristan Williams wrote:
AmForth 6.9 does not support a connection to the USB controller of the ATmega32U4 or any AVR8 as far as I know. This is something I, and quite a few other people I believe, would like - but it is not there yet.
No 32u4! I just bought 5 pieces of CP2102 / FT232 based USB to UART converters for EUR 1.00 / pcs in order to connect my good ol' 328s to USB. So I'm going to skip any experiments with Leonardo or Mega 2560: USB Advantage and Disadvantages: + Cheap and proven: The protocol even does re-sends in case of noise in the line and reports failures. + USB has differential signalling: (RS-422 and RS-485 also have, but sooo much overhead...) + Just one cable to each subsystem for both data and power (space for cables is critical in my setup). Plus a second cable for motor power, obviously... + 3.3V and 5.0V output from FT232: The FT232 provides 3.3V, that should be enough for my 328s + USB is fast + I can connect as many devices as I want using an USB hub as RasPI HAT. I will use a HUB with extra 2.5A 5V power connector. + For debugging I can take the subsystem and attach it to a laptop. + No common GND anymore: I would like to locate my 328s close to the motors, because there is some space. USB comes with it's own GND, but it's OK if that is not perfect because of the USB differential drivers. + Linux drivers available Downsides: - USB may not be as reliable as a electrically stable RS232 or similar? Any references? - Did I miss something?
I would never even try to build something on USB, should my life depend on it.
OK, it's just a robot, no life depends on it. Thank you very much Erich for sharing your Amforth 4.6 vs. 6.8 experience. I'll definitely proceed with caution and make sure there's a watchdog and/or central reset button :-)
The essence of this is: start very simple. Try to make your project run for extented periods of time.
Thank you! Very good advice! I'll let you know about my USB experience. I will definitely make sure DC motors and Atmegas won't share common GND!
Should you decide to climb it
I'm pretty much on top already, I believe... As I said, I even had a SPI driver for Amforth running, allowing my RasPI to send commands to the various 328s via SPI and my angle encoders for the DC motors work using interrupts. I guess that's getting close to the core, isn't it? George Herzog wrote:
More appropriate than a Raspberry Pi with Linux.
The RasPi Zero W is great to handle WiFi communications etc. I also plan to deploy a camera and some AI functions there. The USB Hub HAT can distribute separate 2.5A power, so that should be enough for the logic part. Thanks for pointing to the pitfall, though.
Use of Forth to Enable Distributed Processing on Wireless Sensor Networks
Thanks, read! Right, this is the type of system I was thinking about, just using a wireless protocol. Actually, I read this paper already a year ago and used it as one of the "inspirations" for the SPI driver code. Cheers! Frank _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
