Statically initialised RawSerial objects in greentea and utest causes Rxirq handler to be lost

[LiyouZhou]

mbed-os/features/frameworks/utest/source/utest_serial.cpp

Line 21 in 48c1d2e

RawSerial utest_serial(USBTX, USBRX);

mbed-os/features/frameworks/greentea-client/source/test_env.cpp

Line 64 in 48c1d2e

RawSerial greentea_serial(USBTX, USBRX);

These initialisation compete with user define serial objects. Whichever is initialised last get associated with the hardware serial interrupt.

Hence when I register serial interrupt with the user declared serial object, it only works some of the time.

[LiyouZhou]

A good solution for serial would be defining serial configuration at compile time, and at run time, everybody just call get_serial_object to access the singleton serial object.

[bridadan]

@LiyouZhou I have a PR for this in the works, thanks for bringing this up. I'm going to be using the SingletonPtr class to only configure this RawSerial object at runtime if its used. It will also share the same RawSerial object betwen greentea and utest.

[0xc0170]

This is a step forward (PR referenced right above) but does not solve completely the issue we have (there's a pull request unifying baud rate for stdio, that might help). We had this problem in mbed 3 (ARMmbed/mbed-drivers#145). To summarize, there are differences between toolchains when they initalize stdio, plus allowing to do Serial pc(tx,rx) is bad at a first place. Constructor calls serial_init() eventhough stdio might have been initialized (we don't track that, only for stdio that is private variable used only for stdio).

stdio shall be a singleton (we shall use that POD SingletonPtr class), there's only one object that owns stdio serial. Any code should get a reference to it, not creating a duplication.

I would add a new API , we had Serial& get_stdio_serial(). If anyone does Serial/Rawserial for USBTX/RX, we could print a warning that this used is being deprecated and new API should be used.

@bogdanm @sg- @c1728p9

[ciarmcom]

ARM Internal Ref: IOTMORF-438

[sg-]

Should be solved with #2455.

Multiple object and single hardware instance is by design. That can be separately tracked as an enhancement.