[NEW] Maintainers, changes to the serial driver model

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome.
User avatar
Giovanni
Site Admin
Posts: 10338
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 230 times
Been thanked: 205 times
Contact:

[NEW] Maintainers, changes to the serial driver model

Postby Giovanni » Tue Aug 29, 2017 9:20 pm

Hi,

The serial driver now implements a new API sdControl() that allows to implement custom features. This change requires a small rework in existing serial drivers, matter of minutes, please look at today's changes in STM32 drivers and do the same in other platforms.

This change is limited to trunk code, it is meant for HAL 6.

Giovanni

User avatar
tfAteba
Posts: 422
Joined: Fri Oct 16, 2015 11:03 pm
Location: Chartres, France
Has thanked: 55 times
Been thanked: 29 times

Re: [NOTE] Maintainers, changes to the serial driver model

Postby tfAteba » Sun Sep 03, 2017 4:54 pm

Hi Giovanni,

I have take note and I will do the same change as soon as possible for the AVR platform.

Thanks.
regards,

Theo.

steved
Posts: 456
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 3 times
Been thanked: 34 times

Re: [NEW] Maintainers, changes to the serial driver model

Postby steved » Wed Sep 06, 2017 5:44 pm

Giovanni wrote:The serial driver now implements a new API sdControl() that allows to implement custom features. This change requires a small rework in existing serial drivers, matter of minutes, please look at today's changes in STM32 drivers and do the same in other platforms.

Do you have any thoughts on the sort of features that might be incorporated? (I'm thinking of conventional asynchronous serial ports ATM).

One facility that might be useful is the ability to send a 'break' character (don't think this is possible at all ATM).

Another is the ability to set baud rate, parity etc using meaningful numbers. If implemented, the SerialConfig structure could change to accept these numbers, which would be simpler that having to work out control register settings, but limiting in some ways.

The ability to switch between single drop and multi-drop (i.e. by determining whether RTS is controlled by the UART) would be useful for some, but starts including other information (port assignment for RTS, for example) into the mix.

Its a question of how far to go in simplifying and unifying the API, at the expense of bigger core code size. For some, it wouldn't matter, since it would be moving code from the application to the OS. There could be the ability to enable specific features in the configuration files.

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

Re: [NEW] Maintainers, changes to the serial driver model

Postby Giovanni » Wed Sep 06, 2017 6:56 pm

You mentioned the extensions I had in mind. Code size can be handled by adding switches enabling the single extension features.

Other possible extensions could be EOL detection (event on char match), filtering of chars, event on bit 9 etc etc

Giovanni


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest