Re: [Amforth] List of Supported Device Features in Amforth Documentation?

[<fr...@fr...>]

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