Bitbanged UART?

[artus9033]

Very nice project, but it lacks the bitbanged (software) serial read and write function, which the c and python libraries have. This is a very helpful feature which makes it possible to connect more UART devices to the rpi on normal gpio pins. Is there any chance it will be implemented?

[fivdi]

Duplicate of #3

[AnthonyMyatt]

Implementation of the waveform functions is being discussed in #38. I'm happy to look at implementing the gpioSerialRead* functions once I'm done with waveforms.

[fivdi]

@AnthonyMyatt This would be fantastic. A pull request for this would be excellent. Perhaps a second PR rather than together with the waveforms PR?

[AnthonyMyatt]

I agree, will do them as seperate PRs.

[fivdi]

Given that the Raspberry Pi 4 supports up to 6 hardware UARTs, the need for adding bitbanged support for UARTs is not necessarily what it was in the past.

[schoero]

@fivdi I have included all the necessary functions as I was working on the wave functions. Because I need the serial functions in some projects on a Raspberry Pi 3B+, I would finish the work anyway in my fork. Would you still be interested in merging even though it's no longer as important?

[fivdi]

@Rogerrrrrrrs

Would you still be interested in merging even though it's no longer as important?

Sure :smile:

[tkurki]

Bitbanged serial would solve access to 9 bit Raymarine Seatalk 1 data very nicely - @Rogerrrrrrrs how far is your work?

[schoero]

@tkurki I'm sorry I kinda forgot about this one. I have implemented all serial related methods in my fork and used them for quite a while now. I just had one problem for which I could not come up with a good solution. To make life easier for the users of this library, I intended to create a gpio.on("serialdata") event. If I remember correctly, to avoid missing any serial data, the pigpio C library requires to frequently call gpioSerialRead and retrieve the read data and free up the buffer which is internally used. However the pigpio C library does not offer a callback function when the buffer is full or when serial data is received. In my personal use case I know that every 500ms serial data is received, so I can use an interval to frequently read the received data. But I don't think an interval would be a good solution for this library. I have also tried to create something with the alert and interrupt events but I think there where other problems so I discarded these ideas.

The other option would be to just implement the serial methods as they are in the pigpio C library, but in order to live up to the high standard of this library, I think this library needs something like a gpio.on("serialdata") event if the serial methods are implemented, otherwise we would just pass this problem to the user.

I don't think that I have time to take a look at this again in the near future, but if someone has an idea to solve this problem please let me know.

@fivdi what are your thoughts about this?

[tkurki]

One extremely blunt solution would be to make the interval part of the library and allow configuration as to how often it is run.

[fivdi]

@fivdi what are your thoughts about this?

I haven't worked with the serial functions available in the pigpio C library and can't say what could be used to avoid polling at a high rate. I would have thought that alerts could be used but if you have already tried it and they don't work then I guess you're right.

I think this library needs something like a gpio.on("serialdata") event if the serial methods are implemented, otherwise we would just pass this problem to the user.

I agree with this statement. I also think that polling at a high rate will not make users happy.

@tkurki you could try @Rogerrrrrrrs fork to see if it works for you.

[fivdi]

I'll go ahead and close this as the Raspberry Pi 4 supports up to 6 hardware UARTs and the need for adding bitbanged support for UARTs is not necessarily what it was in the past.