1

I want to develop a program for MCB1700 evaluation board. Client software of PC reads a picture from HDD. Then it sends the picture to MCB1700 evaluation board through socket (Ethernet). Server of MCB1700 receives pictures from PC through Socket-connection and displays it on LCD.

Also server must perform such tasks:

  • To save picture to USB-stick;
  • To read picture from USB-stick and send it to client through socket;
  • To send and receive information through CAN
  • COM-logging.
  • etc.

Socket connection can be implemented with help of CMSIS and RL-ARM libraries.

But, as far as I understood, in both cases sofrware has to listen for incoming TCP-connection and handle network's events in an endless loop - All examples of Keil are based on such principle.

I always thought, that it is a poor way for embedded programming to use endless loops. Moreover, I read such interesting statement

"it is certainly possible to create real-time programs without an RTOS (by executing one or more tasks in a loop)"

I think that it is better to handle all events by interrupts.

Is it possible to use socket conection of CMSIS and RL-ARM libraries and organize all my software by handling of interrupts? My server (on MCB1700) has to perform a lot of tasks. I guess, I should use RTOS RTX in my software. Isn't it so? Is it better to implement my software without RTX?

Lucky Man
  • 1,488
  • 3
  • 19
  • 41

1 Answers1

3

Simple real-time systems often operate in a "big-loop" architecture, with some time critical events handled by interrupts. It is not a "bad" architecture, bit it is somewhat inflexible, scales poorly, and any change may affect the timing of and or all parts of the system.

It is not true that RL-TCPnet must work this way, but it is designed to run stand alone, and the examples work that way so that there are no dependencies on other libraries for the widest applicability. They are only examples and are intended to demonstrate RL-TCPnet and nothing else. In that sense the examples are not realistic and should be adapted to your requirements.

You might devise a system where all your application code runs in interrupt handlers and the network stack is services in an endless-loop in the thread context, but architecturally that is probably far worse than the "big-loop" architecture, since you may end up with very long interrupt handlers, with the higher priority ones starving and affecting the real-time response of lower priority ones. You end up with a system that is difficult to schedule satisfactorily. Moreover not all library routines are suitable for execution in an interrupt handler, so it would be rather restrictive.

It is possible to service the network stack in a low priority thread in an RTOS. The framework for such operation is described in the documentation in the section: Using RL-TCPnet with RTX kernel.. This will require you to understand and use the RL-RTX kernel library, but given your reservations about "big loop" code, and the description of tasks your system must perform, it sounds like that is what you want to do in any case. If you choose to use a different RTOS, then RL-TCPnet can work in a similar way with any RTOS.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • My task looks like: 1) Server (on MCB1700) reads data package. 2) If server doesn't perform any command, a special function parses this package (like an array of char symbols) and defines what command must be performed. In another case program reads packages within certain command and define what to do with them. 3) The command finishes. Return to (1). Another tasks: events from CAN, ADC may be handled by interrupts (the handlers have few lines of code), the saving of picture to USB-stick and displaying it on LCD performs immediately after the reading of package (so it looks like one task). – Lucky Man Jan 08 '12 at 16:15
  • The simultaneous performing of two tasks is ruled out. As I understood a "big-loop" architecture is acceptable in my case? Are the other types of embedded software architecture exist? Is the "big-loop" architecture the most suitable in my case? – Lucky Man Jan 08 '12 at 16:15
  • 1
    @Lucky Man: No, an RTOS is the most suitable architecture IMO. You said you could use the RL-ARM library, so why are you now ruling it out!? You moved the goal post somewhat! Looking at your requirements, I would suggest that there are at least 4 or five tasks. The CAN and USB stacks will require regular servicing too. If you do not have a multi-tasking kernel of some sort, you must have a never ending loop of some sort since if main() terminates your system will stop. In an RTOS tasks are typically individual indefinite loops scheduled to run by the executive. – Clifford Jan 08 '12 at 17:20