Hi
The V1.3 introduction documents remains relevant for V1.4 - V1.4 has more features but no change to basic operation.
When the opportunity arises all references to the version will be removed when not relevant.
The uTasker operating system, is a state-event driven scheduler. It is not pre-emptive (I think that this is often also called co-operative).
There are pros and cons of co-operative and pre-emptive as with everything else in life. There is some background to the decision to use this strategy here:
http://www.utasker.com/forum/index.php?topic=413.0 (and in its links).
To your question 2 - the second task would indeed run 10ms late. Tasks in the uTasker project are designed to respond to events and should generally complete their work as fast as possible. When larger amounts of work need to be performed this can usually be achieved by running a task in polling mode for a period of time, whereby it performs chunks of work each time that it is scheduled - giving the feel of a background task (eg. the LCD task and SD card tasks make a lot of use of this technique; the LCD task will poll LCD readiness while working and limits the amount to work done in a single pass; the SD card task will detect cards during slow polling the mount them and format them in polling mode so that the task's operation is effectively time sliced.
Drivers make use of interrupts for any critical I/O and the same can be used for many time critical applications level jobs too.
3) The advantage of co-operative scheduling is indeed simplification in many respects. Memory only needs to be protected against interrupts and not (generally) other tasks. Tasks don't need their own memory and the result is very efficient use of RAM resources, often allowing more to be done with smaller foot print chips.
There is a UDP echo activated by setting the define
DEMO_UDP in
application.c - search for this define to see the code.
There is also a TCP reference here that responds to a certain received text - it can be modified to simply echo all data back:
http://www.utasker.com/forum/index.php?topic=25.0It may also be an idea to simply connect via TELNET to the demo project. This will echo input back which is not recognised by the command line interface. Since TELNET uses TCP windowing it will generally achieve higher data rates for bulk data too. In
debug.c (this contains the TELNET socket's application call back
fnTELNETListener()) the command line interface can be removed by modifying the following case:
case TCP_EVENT_DATA:
if (fnCommandInput(ucIp_Data, usPortLen, SOURCE_NETWORK)) { // collect data input and try to interpret if a LF is found
return APP_SENT_DATA; // we will always have sent an answer
}
break;to
case TCP_EVENT_DATA:
if (fnSendBufTCP(Socket, ucIp_Data, usPortLen, (TCP_BUF_SEND | TCP_BUF_SEND_REPORT_COPY)) != 0) { // echo back
return APP_SENT_DATA; // we will always have sent an answer
}
break;
In fact this will send a double echo since TELNET will usually be in echo mode and the application interface will be sending a second echo too! The TELNET socket can also be set to raw data mode, which is generally the simplest method for using buffered TCP [the TELNET layer performs most of the dirty work, taking it from the application layer]. As the links explain, buffered TCP mode can also be used directly (the application call back has to do a bit more work to handle all of the possible cases) or else simple TCP mode can be used if bulk transfer is not important, which is usually the simplest to handle. You shouldn't however notice any real difference in reaction time in any of the modes when just testing echos - TELNET/buffered TCP will just take a few us longer since it passes through an additional output buffer.
Regards
Mark
