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
[NEW] Maintainers, changes to the serial driver model
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
- tfAteba
- Posts: 547
- Joined: Fri Oct 16, 2015 11:03 pm
- Location: Strasbourg, France
- Has thanked: 91 times
- Been thanked: 48 times
Re: [NOTE] Maintainers, changes to the serial driver model
Hi Giovanni,
I have take note and I will do the same change as soon as possible for the AVR platform.
Thanks.
I have take note and I will do the same change as soon as possible for the AVR platform.
Thanks.
regards,
Theo.
Theo.
Re: [NEW] Maintainers, changes to the serial driver model
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.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [NEW] Maintainers, changes to the serial driver model
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
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 30 guests