I have the Raspberry PI 3A+ working with Python 3 when I use USB to USB. I can use ardSerial.py to send commands. So I know I have the software setup correctly on the Raspberry PI and that the Nyboard responds.
I have soldered the 2 x 5 socket on and when I connect this way, the commands do not work. It seems to upload them, but never comes back from the operation.
minicom connection is similar - no errors - but no response upon connecting.
The Raspberry PI fires up and I can access it when connected this way - so at least the power is working.
Suspecting a possible bad solder job, I have remelted the solder joints to reset them - did not help. I have 1 wire disabled, serial port enabled per the instructions (but I think if I had this wrong it would show up in the USB to USB test?) I bent the 6 pin programming connector 180 degrees to connect both the computer and the Raspberry PI to troubleshoot. When I send commands from the Pi, the serial monitor on the usb port is not seeing anything and it just hangs forever. Things I'm wondering about: Question 1: I have reloaded Bittle's WriteInstinct in the past - is it possible that there is a missing library (even if it works via USB - seems unlikely).
Question 2: Is there any way to diagnose a bad pin from either side? Question 3: Putting a new 2 x 5 on the board would be challenging for my desoldering skills - would anyone here suspect the connector block itself? Question 4: I am using the /dev/ttyAMA0 port - but that port is present even when the Pi is not connected to the Nyboard. Does that sound right or indicate a hardware problem? FYI I have all my code in a Git repo that I will make public. With a single curl command you will be able to download and configure all that I've done. Once it's working I will share!
There's only one hardware serial port on atmega328p, so you can only use one port at one time.
Since I was waiting on the hardware to solder I got started on getting bluetooth working before attempting GPIO - so maybe my path is due to enabling bluetooth? Do you know if the GPIO should work with the miniUART and not have to swap it to Bluetooth (assuming bluetooth is enabled) ?
Thanks for the updates. We never digged that deep and a new Pi always works with our simple configurations.
I guess some undefined serial commands during the reconfiguration caused a bug in the NyBoard's program, thus it requires rebooting.
One other interesting thing. Almost none of the many, many configuration changes I made to the raspberry pi requires rebooting the Nyboard (some do require rebooting the PI). If, however, the raspi-config setting for "Would you like a login shell to be accessible over serial?" is Yes or changed to yes and then changed to No - rebooting the raspberry pi is not enough - the nyboard is unresponsive until it is rebooted as well.
Ok I did a build from scratch and it would not work and had the same behavior where ardSerial would seem to delay for a very long time before failing. I exported installed packages lists and compared them for differences, /boot/config.txt, /boot/cmdline.txt. I compared raspi-configs. Finally, adding either `dtoverlay=disable-bt` or `dtoverlay=miniuart-bt` to /boot/config.txt fixes it. Since I also want a bluetooth audio connection I use the later so that just the UART switches. The weird thing - is my original build does not have `dtoverlay=miniuart-bt`, but it works. I'm wondering if I found another way to configure the UART swap while struggling to get the original working build going.
Even if I did, this seems like the most self-documenting way to do this. I am going to do another build from scratch to verify I know how to go from off the shelf Raspberry Pi to working - including Bluetooth Audio.
It's working now - not exactly sure why - but that's OK because I am prepping other SD cards from scratch to learn exactly what is needed. Thanks for all your help!
I have the controller port bent backwards and use leads to connect it to the usb board when controlling it with usb so that it can be mobile even when usb connected. The controller port pins are protected by tape from shorting on the USB port edge on the Pi.
The pictured configuration is how I've been trying to get the GPIO serial to work.
I was having problems with ardSerial and python so I have python3 configured and I'm using the version of ardSerial from this pull request: https://github.com/PetoiCamp/OpenCat/pull/11 But as I noted it works perfectly this way over the USB interface.