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!
I am having this exact issue with my setup. I am able to control Bittle with the Pi through usb connection, but not GPIO pins. What was the ultimate solution to getting communication through the GPIO pins?
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.
I am trying to follow this to the "T" https://bittle.petoi.com/4-configuration#4-4-raspberry-pi-serial-port-as-an-interface I have it exactly as pictured - and initially followed the RASPI config instructions exactly.
Like how you are connecting everything, the hardware; and explain where you except to send and receive data.
When I disable BT and try ttyS0 I am getting exceptions when running ardSerial.py. Makes me wonder if it is really talking to the BT adapter when BT is enabled? I wish there was a simple way from the PI to get definitive evidence. Where would you like a picture from? (FYI When I SSH into the PI and try ardSerial, I can't have ardruino IDE running.)
It should not be that complex. Do you have a picture to show your connection state?
Based on https://www.raspberrypi.org/forums/viewtopic.php?t=178079 I followed the below out of /boot/overlays/README Name: miniuart-bt
Info: Switch the onboard Bluetooth function on Pi 3B, 3B+, 3A+, 4B and Zero W
to use the mini-UART (ttyS0) and restore UART0/ttyAMA0 over GPIOs 14 &
15. Note that this may reduce the maximum usable baudrate.
N.B. It is also necessary to edit /lib/systemd/system/hciuart.service
and replace ttyAMA0 with ttyS0, unless using Raspbian or another
distribution with udev rules that create /dev/serial0 and /dev/serial1,
in which case use /dev/serial1 instead because it will always be
correct. Furthermore, you must also set core_freq and core_freq_min to
the same value in config.txt or the miniuart will not work. And then trying ttyAMA0 for GPIO and it does not enable communications.
This guide seems to imply that I BlueTooth needs to be disabled? https://www.petoi.com/forum/hardware/how-to-setup-raspberry-pi-for-programming-nybble-without-ftdi-module Disabling bluetooth for using GPIO is also mentioned here: https://www.raspberrypi.org/forums/viewtopic.php?t=178079 I was hoping to use it for audio - but could test that way if needed.
I got this to work - but can't select anything but the USB or BT ports: https://www.arduino.cc/en/Tutorial/getting-started-with-ide-v2/ide-v2-serial-monitor
Yes I disconnected the raspberry pi when using USB to access the nyboard. I'm wondering if in this state i can test the GPIO port without being connected to it? Also in the past I have had both USB to ardruino and the Pi connected (and ssh'ed into) is there a way to test when connected that way?
When I am in ardruino UI connected with the USB port - I only see the usb and bluetooth serial ports available for selection - does that tell me anything about the status of GPIO serial port? Is there a way in the serial monitor I can test if the GPIO serial port is working?
@Rongzhong Li - the only way I have to connect my robot to ardruino IDE is through the usb port which connects to the programming connector instead of the GPIO. Does your test require that I am connected via GPIO serial port? If so, can I wire the USB module into it somehow?
@Rongzhong Li - thank you for that! While I can't be sure I had done that in past testing - I am doing it with the testing I feeding back into this thread. I've been trying the information here: https://www.raspberrypi.org/forums/viewtopic.php?t=153514 which advised adding enable_uart=1 to the /boot/cmdline.txt (which was not there) - it did not help, so I'll back that out. Those instructions are pretty old. minicom seems to hang a really long time - which ardSerial.py response seems normal as though it is connecting.