Raspberry Pi 3b GPio with FreeBasic, ongoing issues.

[aurbo99]

This is most likely the right place to post as I am lost.

I have successfully installed FreeBasic under Linux (bullseye) on multiple Raspberry Pi 4 and 3B units trying to sort my issue.
Raspi-config has Serial Console disabled, Serial enabled, /boot/config.txt has enable_uart=1 and dtoverlay=disable-bt

using a USB to Serial dongle, my code works as intended sending data to a led matrix message board. The command

Code: Select all

put #comport,,content

is nothing special or unique

I am trying eliminate the USB to Serial dongle and use a TTL to RS232 converter connected to GPio pins 14 and 15 (uart_Tx, uart_Rx)

The target device uses only Gnd and Tx lines so I actually need a single Gpio pin configured (GPIO 14) to allow /dev/ttyAMA0 to pass the data

My problem is that I know little to nothing about wiringPi or PiGpio and how to activate the pins properly.

The more online tutorials I read or watch, the more confused this becomes to me.

Using FreeBasic;
what #include <filename> do I use?
what directory do I place the <filename> in?
how and where to configure/setup/declare the (GPIO14, Output)

[aurbo99]

Progress!

I removed the RS232 to TTL UART Interface MAX232 from the GPio pins and mounted a Serial HAT (RS232)

and without making any additional changes other than

Code: Select all

sudo nano /boot/config.txt

And add the following line:

dtoverlay=pi3-disable-bt

Then run the following command:

sudo systemctl disable hciuart

Reboot your Pi and Bluetooth should be disabled, and serial will be mapped to GPIOs 14 & 15.

which I had performed for the first adapter, The display started up on command and displayed my "Hello World" message.

The baffling part to me is I used 3 different RS232 to TTL UART adapters during this test and they all failed.

[aurbo99]

It turns out that I burnt out one unit by connecting 5vdc it the power pin. dumb mistake,

The two matching converter boards are OK, but tracing the pinouts with a continuity tester shows the Tx out and Rx out pins to be crossed when compared to the working serial hat. As the crossed pair are part of the pcb trace and DB9 soldered pins, it results in Rx on pin3 and Tx on pin2

rewiring the db9 to rj45 adapter solved that issue.

The original code reads an xml file and parses out the <frame> data </frame> info and sends it out the serial Tx pin to the led display, that process has not failed for decades on the Win32 platform.

Porting to Linux shows all the data is correctly parsed from the file and the put command is sending it out, however, the data either get cut short or is too fast and while some of the text appears on the display, the letters and numbers are messed up visually and scrolling text is all malformed/glitchy.

-How can I monitor the uart baud rate while transmitting data?
-could this be an Raspberry Pi clocking issue?
-is it something else?

[aurbo99]

More research = more answers

Recompiling and running off a Win64 computer shows no issues with the hardware or software, at least in a Windows environment.

Recompiling and running off an aarch64, Linux/Raspberry Pi 3 and 4 and even a 5, the PUT issue returns where the message board malforms the text message and/or becomes chunky with scrolling

I have narrowed the trouble to this section of code, the delay-sleep loop after the PUT command

Code: Select all

 	    put #comport,,content
                     
            tdelayms=(timer-lastmark)*1000
            delay=framedelay-tdelayms
            if delay>0 then
                    for x=1 to delay/2
                    sleep 2
                    next x
            else
                    'print"!";
            endif
            lastmark=timer
             

Does anyone see anything out of place for a Linux environment?
Do I need something like #include stdio or other file to manage/regulate the serial port?

[St_W]

Is the issue specific to Linux on aarch64 or does it affect x86/am64 Linux as well?

(I unfortunately don't have an appropriate hardware setup here at the moment to test this :-/ )

[aurbo99]

It affects Linux on both aarch64 and arm64

I think I am missing a file (#include) like stdio that might account for the issues. OR, the uart on the RPi uses a different OSC crystal compared to Windows PC.