Do you have an embedded example?
Does a smartphone count as an embedded application?
A real application from circa 25 years ago.
M&S introduced hand held stock control units into their stores. The units used radio (not cellular or blue tooth) connections to a server attached reciever in the stockroom. They had an 8 line LCD display, a numeric keypad, a 5 positon cursor pad, a barcode reader, RS422, and a radio module that acted like an RS232 connection. The terminals were built by an american company whos name I do not remember, used NEC V80 processor and a RTOS called RX-UX.
M&S were big on specifying and managing the development of all the software their systems used, and so an event driven Control Program was designed and specified by the M&S mainframe software team using the Waterfall method, and implemented off-site by the terminal supplier's software guys with monthly progress review meetings. It took 10 or 12 guys, 18 months of iterations to develop and (eventually) functioned perfectly in the test lab at M&S.
As soon as it went into the field it was a disaster. The terminals would freeze up and have to be manually reset by an engineer. In the real world with lift motors in adjacent shops, freezer and chiller motors cutting in and out at random, flourecent lighting buzz etc. etc. Instead of getting 9600baud bidirectional comms, they were lucky to get 300 baud one way.
I was brought in to rewrite the server end. The original server program was another behemoth event loop running under DOS that was designed to talk to up to 16 terminals at a time, either via hardwired RS422 or RS232 over radio. It also had to download data from the terminals and upload it to the companies network; and download pick lists, price lists and stuff from the network and upload them to the terminals.
I rewrote the server sofware as a suite of 10 separate programs that ran under OS/2. Several of the programs would have one instance running for each terminal that was being talked to.
Each was a very simple, linear flow: make connection, transfer data; disconnect from terminal; set a work item (upload or download) for the network comms program to pick up when it was ready; end.
Another program would run constantly round robin over the comms ports, and if one of the terminals was attempting to connect, it started a new instance of the appropriate program to handle that; and went back to round robin.
The network comms program ran constantly, periodically polling a directory on the server for the presence of work item; and periodically checking a directory on the network for work items generated at the mainframe end. When it detected either, it started an instance of a single file transfer program to take care of the work item. and went back to watching.
The beauty of the system was that each of the programs was entirely stand alone and could be modified entirely independantly of each other. It took me 2 months to design and implement the entire suite.
Another independant specalist was brought into re-write the terminal software. Whilst I didn't have any part in writing that software, I had to work closely with him for an extended period. He did almost exactly the same thing. Instead of a single, monolithic, time critical loop that attempted to juggle all the sub routines in a timely manner using cooperative methods as the original did, he wrote a bunch of inependant tasks and used the RX-UX scheduler to manage them. I can't go into any details because I don't know them. I do know that he had his stuff working before I was ready. 1 man and 2 months.