chakie
April 3, 2023, 3:30pm
1
So we’ve used UnbufferedSerial for a while and it works fine. However, it would be nice to be able to just throw a buffer of bytes at Mbed and “here, write this and let me know when it’s done”. Basic async stuff. This is all available in SerialBase in the form of the method:
write (const uint8_t *buffer, int length, const event_callback_t &callback, int event=SERIAL_EVENT_TX_COMPLETE)
But for some weird reason I can’t understand it’s privately inherited into BufferedSerial and thus off limits. Any reason why such useful functionality would be taken away from us poor developers? Setting non blocking mode and manually faffing around with the reading/writing is annoying and prone to bugs.
Or perhaps there’s some other way to do async serial communication that’s not apparent from the docs?
chakie
April 4, 2023, 7:29am
2
This seems to be related:
opened 02:37PM - 01 Aug 20 UTC
closed 03:22PM - 20 Oct 21 UTC
type: bug
component: core
priority: untriaged
<!--
************************************** WARNING **********************… ****************
The ciarcom bot parses this header automatically. Any deviation from the
template may cause the bot to automatically correct this header or may result in a
warning message, requesting updates.
Please ensure all sections of the template below are filled in and no changes
are made to the template format. Only bugs should be raised here as issues.
Questions or enhancements should instead be raised on our forums:
https://forums.mbed.com/ .
*************************************************************************************
-->
### Description of defect
Recent updates involving the `Serial` implementations in Mbed-OS have made it impossible to access AsynchSerial methods `SerialBase::read` and `SerialBase::write`. It appears the two replacement subclasses, `UnbufferedSerial` and `BufferedSerial`, do not make use of these transfer methods and instead rely on single-byte transfers.
I am working on a serial bootloader operating at 115200 baud and have found it impossible to use the new public subclasses to receive in-tact data. I believe the cause is that the new `Unbuffered/BufferedSerial` subclasses operate in a manner that is too slow to capture all data properly...
My target is an nRF52840.
Could be related to #13339
<!--
Add detailed description of what you are reporting.
Good example: https://os.mbed.com/docs/mbed-os/latest/contributing/workflow.html
-->
#### Target(s) affected by this defect ?
nRF52840, possibly all targets
#### Toolchain(s) (name and version) displaying this defect ?
GCC ARM:
`arm-none-eabi-gcc --version`:
```
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
```
#### What version of Mbed-os are you using (tag or sha) ?
<!--
For a released version please provide the release tag (this can be found as per the instructions below)
mbed-os version can be found in /platform/mbed_version.h. The tag can be reconstructed as follows:
mbed-os-MBED_MAJOR_VERSION.MBED_MINOR_VERSION.MBED_PATCH_VERSION
Master branch is indicated by 'mbed-os-99.99.99
For an issue found on Master please provide the sha being used.
-->
mbed-os-6.1.0 (a6207cadad0acd1876f436dc6baeddf46c42af06)
#### What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
mbed-cli version: 1.10.4
#### How is this defect reproduced ?
Try to receive more than one byte of serial data at a time...
But the gist of that seems to be “the serial API:s are badly designed so this can never work”, or am I reading it wrong?
