Hi,
I bought the Grove AI HAT for Edge Computing product and make some tests with Arduino IDE (on my Macbook Pro) and the AI HAT.
In this AI HAT - standalon mode It works fine.
After that I setup the Grove AI HAT (the switch in the correct position) on top of the Rasberry Pi 3 model B.
Both systems are running.
What is the intented workflow model in situation where the AI HAT sit on top of Rasberry Pi 3 B ?
I tried to access the AI HAT over Serial (using UCB-C - like before in the standalone situation) but this does’nt work (no usb - serial port is available).
Is there a way to program the AI HAT in a combined mode (AI HAT sit on top of the Rasberry Pi) or can the AI HAT only programed in the standalone mode ?
Some hints would be nice.
Best regards
Andreas
I’m no expert.
When programming using another device via USB-C while the HAT is still on the Pi, I think the switch needs to be set to off to decouple the Pi 5v source from the HAT.
Hi,
I think the switch needs to be set to off to decouple the Pi 5v source from the HAT.
Yes I had set the switch off, but on my MacBook the usb.serial port was not available (USB-C connected to MacBook).
Best regards
Andreas
Oh! That’s odd. I have zero experience with Mac OS > 9. The CHG320 is a common USB UART chip so it should appear. Is there a chance the USB port doesn’t support enough current?
I spent some time looking at the schematic today and it also appears that the USB C cable can only be used for flashing. Just using a UART it looks like the options are the UART connector on the board or the UART pins on the GPIO port which are in the the RPi standard locations.
I apologise for some misinformation. There was a problem in my configuration. The USB C cable does act as a UART. I had it outputting to the Arduino console last night during a test. Honestly I’m a little confused now after what I saw in the schematic didn’t match what I expected to see.
Another fun fact I discovered today. The Grove AI HAT and Pi (or compatible) use the same TX and RX UART pins on the GPIO header. This means the boards cannot communicate with each other via GPIO UART. In its own way it makes sense, but it also rules out the easiest method of communication without extra wiring. IIC probably wouldn’t be too bad for low bandwidth comms and SPI for higher bandwidth.
Some items in the standalone SDK seem to ignore the toolchain location passed to the build. The quickest way to get around it is to create a symlink from the original toolchain to the other directory it was looking for.
Loboris’ micropython can’t seem to build using an aarch64 host. From what I can understand it’s a known gcc code emitting bug.