So, you’re not using a x64 processor but a Arm64 one (x64 refers to Intel/AMD 64 bit processors.)
I doubt the devc-ser8250 driver fits this chip.
You get a QNX BSP for nvidia delivered with QNX7.
There must be some documentation explaining how to run a serial driver.
Can you post the build file delivered with the BSP ?
The build file should be in something like xxx\src\hardware\startup\boards\yyy\zzz
I’ve been reading the discussion here. To begin with, I don’t know of any serial driver that works with generic GPIO pins. There may be one but it would surprise me. You could create your own driver, but I suspect there is an inherent problem. If the GPIO pins have an interrupt that fires on level changes you could write an interrupt handler to receive data, however it would be rather unusual in that you would have to process an interrupt on every bit. You would also have to deal with when to timeout to recognize a frame error. An alternative would be to have a periodic interrupt that would sample the GPIO. I believe there’s an theorem that says you can run that interrupt at twice the baud rate and not miss data. The same interrupt could be used to output data. Without using interrupts you would need to dominate the processor while sending and receiving data which is very un-qnx and un-realtime like. All this sounds rather hacky and unnecessary. I would think a better solution would be to connect a UART of some kind, even one with serial interface of some kind.
You would generally write a QNX driver such as this one using the Resource Manager framework. This is not a simple task the first time through, but there is sample code around and two references on the subject, the QNX guide and Robert Krten’s book. I think the source to the 8250 driver is available somewhere, although it will only be useful on the OS side. The hardware it supports is a UART.
I have written the odd QNX6 and QNX4 serial driver. In fact am putting the finishing touches on to a QNX7 driver (for x86_32 and x86_64).
I have had the luxury however of dealing with hardware UART’s that furthermore had the appropriate driver and receiver hardware required to get RS232, RS422, and RS485 signal levels.
This talk of using two GPIO pins that are presumably TTL (3.3V or 5V?) and to be used as TxD and RxD got me thinking about what I suppose could be referred to as a virtual UART. I know nothing about the hardware named above but if a suitable timing source (clock) was available, my initial thoughts are that it might be possible. A UART is essentially a glorified parallel → serial shift register.
For serial I/O (even asynchronous) the timing requirements are pretty tight so it might not be possible in a traditional computing environment. But I think I might give this idea some further thought - for want of something different to do.
In a decent FPGA environment it would be relatively simpleto implement a “virtual” UART but am I correct in assuming that there is no FPGA in the system detailed earlier on in this thread?
