Doubt regarding drivers implementation

Discussions and support about ChibiOS/HAL, the MCU Hardware Abstraction Layer.
0x3333
Posts: 57
Joined: Thu Mar 07, 2019 10:19 pm
Has thanked: 7 times
Been thanked: 6 times

Doubt regarding drivers implementation

Postby 0x3333 » Wed May 01, 2019 3:23 am

Hi!

I'm working in a project that needs more uart than available. As the requirements are for 9600 baud and 6 devices, low bandwidth, I'll implement a software uart, the same concept as the classical "generic software uart" by Colin Gittins(IAR).

I'm thinking creating a SoftUart driver, so far so good, but I'd like o use GPT as timer and EXT as interrupt for RX.

The question is, would it be useful to add to Chibios? if so, is that possible to use a driver inside another one? I couldn't find a similar usage.

If not useful to Chibios, I'll write it more "Savage"...

Thanks.

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: Doubt regarding drivers implementation

Postby faisal » Wed May 01, 2019 3:56 am

If you make it a buffered driver, you can use the hal_serial.h abstraction, as it uses virtual method tables for the implementation. If you need per character interrupts, that would be more like hal_uart - and that is tied to a specific lld file.

0x3333
Posts: 57
Joined: Thu Mar 07, 2019 10:19 pm
Has thanked: 7 times
Been thanked: 6 times

Re: Doubt regarding drivers implementation

Postby 0x3333 » Wed May 01, 2019 5:10 pm

My use case is more like a UART, chat based than serial. That is what I was thinking about, using virtual methods and the same interface. The doubt is if is possible/allowed to use another driver inside it.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Doubt regarding drivers implementation

Postby Giovanni » Wed May 01, 2019 6:33 pm

Hi,

We have a soft (fallback) I2C already, it would be possible to create a similar UART implementation but it would be difficult for the reason Faisal mentioned, the serial driver is meant to be asynchronous and buffered, it would be hard to create a SW UART operating asynchronously at decent speeds.

It would require some kind of state machine sitting on top of a timer, may be a GPT instance.

A stand-alone UART library would be easier.

Giovanni

0x3333
Posts: 57
Joined: Thu Mar 07, 2019 10:19 pm
Has thanked: 7 times
Been thanked: 6 times

Re: Doubt regarding drivers implementation

Postby 0x3333 » Thu May 02, 2019 4:09 am

You're right. I'll create a standalone implementation, and eventually see how it performs. I'll let you guys posted.

Thanks.

0x3333
Posts: 57
Joined: Thu Mar 07, 2019 10:19 pm
Has thanked: 7 times
Been thanked: 6 times

Re: Doubt regarding drivers implementation

Postby 0x3333 » Sat Aug 03, 2019 10:43 pm

Hi! Sorry to dig up this post, but I started creating the driver for the software serial after finally made it work.

I created a pseudo-driver in my app, that uses PAL and GPT to create multiple software serials. I use PAL line events to detect start bit(PAL_EVENT_MODE_FALLING_EDGE) and GPT in continuous mode 3x baud rate to read the bits.

Basically, I have a counter which gets incremented every GPT interrupt, when I receive the start bit, I store the current counter + 4(3x baud + 1 to stay in the middle of the bit). Every irq I check if counter is equall stored counter, which state is the serial and read the bit, yada yada yada. It is working.

Now, I want to write a driver per se, my doubt is that I need PAL and GPT in this driver, is this allowed(A HAL using another HAL)? Where to store information about current bit received, index, etc, SoftSerialDriver?(I created this based on SerialDriver) Should I enable the PAL line event(palEnableLineEvent(SSD_LINE_RX, PAL_EVENT_MODE_FALLING_EDGE)) and callback(palSetLineCallback(SSD_LINE_RX, rx_pin_callback, 0)) or this must be done by the user?

Sorry, if the questions sound silly, but I'd like to create it the "right" way and I'm not that familiar with Chibios internals.

Thanks.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Doubt regarding drivers implementation

Postby Giovanni » Sun Aug 04, 2019 7:00 am

In ChibiOS HAL there is the concept of "complex driver", it is a driver sitting on top of other drivers that does not touch HW directly. Your driver would fall in this category.

I think it is better if you don't try to implement it as a "serial driver", a complex driver is fine. Giving it a "channel" interface would also make it compatible with chprintf() and any other stream/channel function.

Giovanni

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: Doubt regarding drivers implementation

Postby faisal » Mon Aug 05, 2019 5:40 pm

0x3333 wrote:Hi! Sorry to dig up this post, but I started creating the driver for the software serial after finally made it work.

I created a pseudo-driver in my app, that uses PAL and GPT to create multiple software serials. I use PAL line events to detect start bit(PAL_EVENT_MODE_FALLING_EDGE) and GPT in continuous mode 3x baud rate to read the bits.

Basically, I have a counter which gets incremented every GPT interrupt, when I receive the start bit, I store the current counter + 4(3x baud + 1 to stay in the middle of the bit). Every irq I check if counter is equall stored counter, which state is the serial and read the bit, yada yada yada. It is working.

Now, I want to write a driver per se, my doubt is that I need PAL and GPT in this driver, is this allowed(A HAL using another HAL)? Where to store information about current bit received, index, etc, SoftSerialDriver?(I created this based on SerialDriver) Should I enable the PAL line event(palEnableLineEvent(SSD_LINE_RX, PAL_EVENT_MODE_FALLING_EDGE)) and callback(palSetLineCallback(SSD_LINE_RX, rx_pin_callback, 0)) or this must be done by the user?

Sorry, if the questions sound silly, but I'd like to create it the "right" way and I'm not that familiar with Chibios internals.

Thanks.


Are you able to share your code? Got something on Gitlab/hub/etc .. ?

0x3333
Posts: 57
Joined: Thu Mar 07, 2019 10:19 pm
Has thanked: 7 times
Been thanked: 6 times

Re: Doubt regarding drivers implementation

Postby 0x3333 » Mon Aug 05, 2019 7:42 pm

I don't have it working as a driver yet, but in my fork, on Github(alex31 mirror) you can see in the softserial branch, basically os/hal/lib/complex/soft_serial folder.

https://github.com/0x3333/chibios_svn_m ... oft_serial

This is not tested and is probably broken, I'm just building the pieces together as a driver and will test in the hardware this week.

@Giovanni, if you could validate the driver as a whole just to guarantee it is in the right direction, I'll appreciate it.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Doubt regarding drivers implementation

Postby Giovanni » Mon Aug 05, 2019 7:53 pm

I can give few suggestions:

1) It should only touch OSAL and other drivers, no "ch" functions.
2) Avoid making a set of fixed instances SSD1... etc. Let the application do ssdObjectInit() on any number of instances. Other complex drivers avoid to do this, they behave purely as classes with a constructor (xxxObjectInit()).
3) Put references to other drivers into the configuration structure so each instance can use different pins (as PAL lines), different GPTs etc.
4) Try to not have dependencies that can be avoided, for example you could have a function to be called from outside for timings and not refer a GPT at all. The outside application would initialize a GPT, some other HW timer or even a VT for very low baud rates. The fallback I2C driver, for example, relies on an externally-provided delay function.
5) Avoid random static variables, everything should be part of the class (the driver structure).

KISS

Giovanni


Return to “ChibiOS/HAL”

Who is online

Users browsing this forum: No registered users and 7 guests