Topics

271

µTasker general / Working with tasks

« on: August 03, 2007, 11:38:11 AM »

Hi All

One question which is often asked is about how to create new tasks. The basics to this are in the document about the operating system basics but it would be interesting to have various examples so here are some:

1. Every task requires first a unique name. For example the watchdog task has the name "Wdog". This string is quite useful when working in debug mode in the tasking part of the code since the name can be displayed. However the actual scheduling works only with the first letter of the name - this is since it is much more efficient to compare just the first letter than a string and keeps with the goals of the uTasker which are to achieve a high level of code size and speed efficiency but still keep a useful degree of comfort.

2. In order to work with the task a simple define is required:
#define TASK_WATCHDOG           'W'                                      // watchdog task
which corresponds to the first letter of the name.

3. In order to add a new task, simply define a name with unique first letter or number, or any other sign. Try to match the name to the tasks job but still do this without colliding with an existing name - capitals and small letters are of course not equal.

#define TASK_MY_NEW_ONE           'n'                                    // my new task task
"new task.."                      // the name we will give it

4. Every task requires a function which is called when it is scheduled

Code: [Select]

#include "config.h"

#define OWN_TASK  TASK_MY_NEW_ONE

void fnMyNewTask(TTASKTABLE *ptrTaskTable)                                // task function
{
}
but before it can actually be used it must be defined in the task table as well as in the node list.
Note that the task table entry defines the properties of the task (at least when it first starts) but it doesn't cause the task actually to be created. It is only created when its reference is ALSO in the node list. The idea behind this is that various node lists can be defined (eg. one for each node in a distributed system) which then create only the tasks which are actually needed for it's own work.

const UTASK_TASK ctNodes[] = {                                           // we use a single fixed configuration (single node)
  DEFAULT_NODE_NUMBER,                                                   // configuration our single node
  TASK_MY_NEW_ONE,
  0,                                                                     // end of single configuration

  // insert more node configurations here if required
  0                                                                      // end of configuration list
};

extern void fnMyNewTask(TTASKTABLE *);

const UTASKTABLEINIT ctTaskTable[] = {
  { "Wdog",      fnTaskWatchdog, NO_QUE,   0, (DELAY_LIMIT)( 0.2 * SEC ),  UTASKER_GO}, // watchdog task (runs immediately and then periodically)
  { "new task..",fnMyNewTask, NO_QUE,   0, 0,  UTASKER_STOP},                           // new task not doing much yet
};

When the system starts, the resources for the new task will now be created. In this case the task will have no input queue and no timers associated with it. In fact it will not do much and never be scheduled by the tasker.
It could however be activated from another task in the system when it calls uTaskerStateChange(TASK_MY_NEW_ONE, UTASKER_ACTIVATE);

This will cause the new task to be scheduled once before it is set back to the UTASKER_STOP state.

If it is started using uTaskerStateChange(TASK_MY_NEW_ONE, UTASKER_GO); it will cause the task to be scheduled every time the tasker cycles. This will then convert the task into a polling task.

However it can of course also be immediately started as a polling task by already defining it like that in the task list.
  { "new task..",fnMyNewTask, NO_QUE,   0, 0,  UTASKER_GO},

5. Now it may be that you have some code which you would like to add to the project which looks something like this:

Code: [Select]

int main(void)
{
    fnInitialiseSomeThings();

    while (1) {
        if (event1 != 0) {
            fnHandleEvent1();
        }
        if (event2 != 0) {
            fnHandleEvent2();
        }
        if (event3 != 0) {
            fnHandleEvent3();
        }
    }
}
SUch code don't assume any operating system and is build around polling for events to take place, which may be flagged from interrupt routines or by other events. The question is how to allow this code or may be several similar modules which are constructed like this to operate in a way that all receive processing rources and all can live along side the uTasker demo project (or similar) with its TCP/IP resouces?

The answer is in this case thankfully very simple. Since it is based on polling anyway we simply add each module to a polling task:

Code: [Select]

void fnMyNewTask(TTASKTABLE *ptrTaskTable)
{
    static iTaskState = 0;

    if (iTaskState == 0) {
        fnInitialiseSomeThings();
        iTaskState = 1;
    }

    if (event1 != 0) {
        fnHandleEvent1();
    }
    if (event2 != 0) {
        fnHandleEvent2();
    }
    if (event3 != 0) {
        fnHandleEvent3();
    }
}

Now we have these modules and the complete demo project working along side each other.

6. If for some reason one of the modules needs to start delayed this can be achieved by defining the task characteristics accordingly:

  { "new task..",fnMyNewTask, NO_QUE,   (DELAY_LIMIT)(5.10 * SEC), 0,  UTASKER_STOP},

Now this task will be started after a delay of 5.1s. However it will only be started once but it can turn itself into a polling task by simply making the following change:

Code: [Select]

    if (iTaskState == 0) {
        fnInitialiseSomeThings();
        iTaskState = 1;
        uTaskerStateChange(OWN_TASK, UTASKER_GO);                        // switch to polling mode of operation
    }

7. If the polling rate of the task, which is presently as fast as the task list is being worked through, is not needed to be so fast it could be set to a user-defined rate by changing the task definition again (and removing the uTaskerStateChange(OWN_TASK, UTASKER_GO); command):
  { "new task..",fnMyNewTask, NO_QUE,   (DELAY_LIMIT)(5.10 * SEC), (DELAY_LIMIT)(0.10 * SEC),  UTASKER_STOP},
Now the first time the task is scheduled is after 5.1s and afterwards it will be scheduled (polled) every 100ms.

8. The polling is in fact using a monostable task time which was created according to the task configuration. The task still has no input queue, but this if OK because the monostable task timer wakes the task for scheduling without needing to place any messages into its queue. The disadvantage of this is simply that it is only possible to have a single timer event. If the different event should be polled at different rates we could do this by using a different technique. (Note that when using GLOBAL_TIMER_TASK support a single task can also have several timers associated to it - this is described in the corresponding document!).

  { "new task..",fnMyNewTask, SMALL_QUEUE,   (DELAY_LIMIT)(5.10 * SEC), 0,  UTASKER_STOP},

Code: [Select]

void fnMyNewTask(TTASKTABLE *ptrTaskTable)
{
    static iTaskState = 0;
    QUEUE_HANDLE        PortIDInternal = ptrTaskTable->TaskID;           // queue ID for task input
    unsigned char       ucInputMessage[SMALL_QUEUE];                     // reserve space for receiving messages

    if (iTaskState == 0) {
        fnInitialiseSomeThings();
        iTaskState = 1;
        uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(1.5*SEC), E_TIMER_EVENT1 );
    }

    while ( fnRead( PortIDInternal, ucInputMessage, HEADER_LENGTH )) {   // check input queue
        switch ( ucInputMessage[ MSG_SOURCE_TASK ] ) {                   // switch depending on message source
        case TIMER_EVENT:
            switch (ucInputMessage[ MSG_TIMER_EVENT ]) {
            case E_TIMER_EVENT1:
                fnHandleEvent1();
                uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(0.1*SEC), E_TIMER_EVENT2 );
                break;
            case E_TIMER_EVENT2:
                fnHandleEvent2();
                uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(0.05*SEC), E_TIMER_EVENT3 );
                break;
            case E_TIMER_EVENT3:
                fnHandleEvent3();
                uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(1.5*SEC), E_TIMER_EVENT1 );
                break;
            default:
                break;
            }
            break;
        default;
            break;
        }
    }
}
Now the task is controlling its own delays on an event basis [1.5s, 100ms, 50ms]. It needs now an input queue so that it can distinguish between the timer events. Its task definition still has a 5.1s delay before it is first scheduled and this causes it to also to be defined with the appropriate timer resources.

9. If there is no start delay required, the following can be used:
  { "new task..",fnMyNewTask, SMALL_QUEUE,   (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0,  UTASKER_ACTIVATE},

This will cause it to immediately be scheduled once at start. It is however created with the required timer resources which it will use later.


Using these simple techniques quite interesting things can already be performed.
In the next part of this series of examples I will show how the operating system support and its drivers can enable a more modular software design of a project which is easier to maintain and expand. These features will allow the simple reconstruction of projects which are using less efficient polling techniques to become fully event driven. Tasks will only operate when there is really work to do.

Regards

Mark

272

µTasker general / Using TCP in the uTasker project

« on: July 20, 2007, 10:18:51 PM »

Hi All

The uTasker demo project uses TCP for several services. These include HTTP, SMTP, FTP, TIME SERVER and TELNET, to name the ones which initially spring to mind.

The demo project enables these services to be easily studied and own services to be written (usually termed clients and servers) based on these example. There is, at the time of writing, no 'official' document which contains a definitive guide.

This is logically the reason why the use of TCP is a frequent question and frequent discussion topic in private mails. It is also a reason why this document, which is long overdue, should soon be made available.

Therefore this thread is designed to be an introduction to the subject to answer the first burning questions and to give first practical examples, as well as more detailed insight into how it works, how it can be used and why it all works like that. If all goes well, the thread comntent can be moved to a more structured document at a later point in time.

TCP is in fact a very simple protocol - in its simpest form. But in order to allow it to perform with the speed and reliability which has enabled it to become originally the standard in the Internet and eventually the standard in almost all networks it does need a few additional frills which can then make it quite complicated indeed.

If you would like to discuss standard TCP details please feel free to create your own topic to get a discussion going. I have always found it very difficult to find any really meaningful discussions about the practical aspects in the Internet so it would be nice to be able to find some good ones here!


A simple TCP server example. (The HTTP service is a good source for reference).

First we get a socket from the TCP socket pool. The size of the socket pool is defined in config.h, where the define USER_TCP_SOCKETS can be incremented for every additional socket which user code (as opposed to standard services like HTTP) will need.
The following configures a socket with the defined characteristic (minimum delay as opposed to maximum throughput or maximum reliability - these are router parameters), a timeout of 10 seconds (after this length of time with no activity it will close the connection. A value 0xffff means no timeout!), and a callback routine called fnTestListener() which will be doing the work later.

Code: [Select]

static USOCKET Test_socket = -1;                                          // declare a static socket variable
...
    Test_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, (unsigned short)10, fnTestListener); // from task or sub-routine code
The socket is not in the listening state (which is needed for it to act as a server) so we start it in this state by calling

Code: [Select]

static unsigned short usTestPort = 0x9999;                               // declare a static socket variable (the value could also be fixed)
....
    fnTCP_Listen(test_socket, usTestPort, 0);                             // after getting the socket, bind it to a listening port
Now the socket is listening on port 0x9999, which means if you have a test client (eg. Telnet on this port) send a connection request to it it will start a connection process.
Note that the parameter 0 when setting the listening state is the maximum windows size which the connection can receive - a zero defaults to the standard LAN TCP pay load size of 1460 bytes. For some applications with special buffer restrictions this can be used to improve flow control in the rx sense (CONTROL_WINDOW_SIZE needs to be enabled in config.h) but this won't be described here just yet.

The simple server listener looks something like this.

Code: [Select]

#define TEST_BUFFER_LENGTH 10
typedef struct stTCP_MESSAGE
{
    TCP_HEADER     tTCP_Header;     // reserve header space
    unsigned char   ucTCP_Message[TEST_BUFFER_LENGTH];
} TCP_MESSAGE;

static int fnTestListener(USOCKET Socket, unsigned char ucEvent, unsigned char *ucIp_Data, unsigned short usPortLen) {
   TCP_MESSAGE test_message;

    switch (ucEvent) {
    case TCP_EVENT_CONREQ:                                             
    case TCP_EVENT_CONNECTED:
    case TCP_EVENT_CLOSE:
    case TCP_EVENT_ACK:
    case TCP_EVENT_ARP_RESOLUTION_FAILED:
    case TCP_EVENT_PARTIAL_ACK:
        break;
    case TCP_EVENT_REGENERATE:
    case TCP_EVENT_DATA:
        if ((ucEvent == TCP_EVENT_REGENERATE) || (!uMemcmp((CHAR*)ucIp_Data, "TEST" , 4))) {
            uStrcpy((CHAR*)test_message.ucTCP_Message, "Hi!!");
            if (fnSendTCP(Socket, (unsigned char *)&test_message.tTCP_Header, 4, TCP_FLAG_PUSH) > 0) {
                return APP_SENT_DATA;
            }
        }
        break;
    case TCP_EVENT_ABORT:
    case TCP_EVENT_CLOSED:
        fnTCP_Listen(Socket, ++usTestPort, 0);                    // go back to listening state on next port number
        break;
    }
    return APP_ACCEPT;
}
As you can see it receives events from the TCP layer, some with other details such as a pointer to data.

This is a list of the events which can arrive:

• TCP_EVENT_ABORT               TCP connection was closed (due to error or a reset from peer)
• TCP_EVENT_CONNECTED        TCP connection has been successfully established
• TCP_EVENT_ACK                   Data which we sent have been successfully acknowledged (for all sent data, with outstanding acks)
• TCP_EVENT_DATA                 Data frame received with data content for us to treat
• TCP_EVENT_CLOSE                Peer is starting a close of the present TCP connection
• TCP_EVENT_CLOSED              The TCP connection has been fully closed
• TCP_EVENT_REGENERATE       The last data frame was lost and must be resent!!!
• TCP_EVENT_CONREQ              A peer wants to establish a TCP connection (SYN received)
• TCP_EVENT_ARP_RESOLUTION_FAILED  Generally only when working as client and sending a connection request or data after a longer period of no activity. It means that the the SYN or the data could not be sent by the IP layer since the address of the destination could not be resolved (destination powered down or network problem, or just doesn’t exist). In this cause the application is informed that the connection is either not possible of the connection has broken down due to this.
• TCP_EVENT_PARTIAL_ACK       This is only used when Windowing is in operation. Presently only TELNET uses it. It means that an ACK has been received for a part of the data which has been sent (rather that all data that has been sent). This is used to acknowledge that only a part of the data has been successfully delivered rather than all outstanding data. This has to be treated differently to a normal ACK event since the ack number has to be used to calculate which outstanding data acks are still open and expect their own ack later.

Now if you are new to TCP, enter in the above test program - best in the simulator - and you can see your first simple TCP server in operation. It won't do a lot but it will at least do the following.

1. When the client requests a connection to port 0x9999 the event TCP_EVENT_CONREQ will be received. Here it would be possible to deny the connection to a black-listed IP for example but our server always allows connections.
2. The TCP connection will be established and the event TCP_EVENT_CONNECTED is received.
3. If the client sends any data it will arrive with the event TCP_EVENT_DATA. The server will only respond to the message "TEST" in which case it will send the string "Hi!!" as answer.
4. After 10s with no activity, the server will close the connection (it is actually TCP that does this after the idle timer fires but the server receives the event TCP_EVENT_CLOSED when the connection has successfully closed).
5. The lister socket is not active after the connection has been closed so the code sets it up as listener again, this time with port number 0x999a.
6. If the connection is repeated, the port number is always incremented each time and the connection always times out after 10s.

Note that when the server sends data it returns APP_SENT_DATA. This informs TCP that the application has just successfully sent something and TCP doesn't have to acknowledge the received data - the ack has already been piggy-backed with the transmitted data.

If the transmission were to fail and need repeating, the server has to handle the event TCP_EVENT_REGENERATE. Since we only ever send one message it is obviouse that this has failed and so it is simply resent. The event TCP_EVENT_ACK will be received when the transmitted message actually has arrived safely.
It is in fact a great shame that messages can and do get lost (but it is not a perfect world and so we have to be ready for it) because regeneration of previously sent messages is probably the most complicated and/or RAM consuming parts of TCP implementations. This example has it real easy, but this is also a real simple example!

Here is a list of all possible return codes from the listener.

• APP_ACCEPT             This is normal return when no data has been sent. The TCP level will then acknowledge the received frame and the connection will continue
• APP_SENT_DATA       The listener is informing TCP that it has sent data (be sure that data was really sent when returning this, it should not be returned if a transmission attempt failed)
  The TCP level will therefore not send an ACK of its own since the data will have had a piggy-back ack of its own. If there is a mistake and data is sent and APP_ACCEPT is returned it is not serious – there will simply be an unnecessary ACK sent which doesn’t actually hurt anything (just not so efficient)
• APP_REJECT             This is used to reject a connection (for example if the IP address is on a black list…) It causes TCP level to return a RESET rather than perform the TCP connection sequence
• APP_REQUEST_CLOSE    The application informs TCP that the application has just actively started the close of the present TCP connection.
  It is returned after the application calls fnTCP_close(socket); 
• APP_REJECT_DATA       This is a special case where the application doesn’t want to accept data at the moment. It doesn’t cause the connection to be broken down but TCP will not ACK the data. The peer will then be forced to repeat the data – resulting in a delay (using the peer as a queue, possibly until data can be received).
• APP_WAIT                Same as previous but delay on TCP connection establishment.

Our example has made use of very few features up to now and there is much more to be explained. However this should allow first steps to be taken and also the servers in the project (HTTP, FTP etc.) to already make a lot more sense.

I will continue the topic later with a first simple client example. If you already have confusions or questions, or corrections etc. please feel free to comment.

Regards

Mark

273

ST^TM STM32 and STR91XF / STR91XF Pre-release

« on: July 13, 2007, 11:51:09 AM »

Hi All

Please note that the state of the STR91XF project is pre-release but any one who would like to use it and/or help to complete final tests and fine tunings is welcome. Simply fill out the standard application form to get a link and password to it.

Please use this thread for feedback and I will be using it to inform of patches and other details during the last phase.
Note that a couple of updates are included from the past to ensure than anyone watching is up to date.

Regards

Mark

274

NXP^TM M522XX, KINETIS and i.MX RT / Using Eclipse and open source tool chain with M5223X

« on: July 13, 2007, 12:10:02 AM »

Hi All

There has been quite a lot of interest recently about the possibilities of using open source tools - especially Eclipse - for M5223X developments.

The lastest service pack for the M5223X (SP4) includes also a GNU project build and the makefile is also suitable for use with Eclipse.

One test I made was to compare the generated code of a particular project build with Codewarrior 6.3 and the results were surprisingly positive:

Code: [Select]

GNU   FLASH    56'848 bytes / RAM 1'728 bytes (including 1024 bytes for vector RAM)
CW6.3 FLASH    59'492 bytes / RAM 1'680 bytes (including 1024 bytes for Vector RAM)
This was performed with CodeSourcery G++ Lite 4.1-32 (GCC 4.1.1)

There is an important note about the latest CodeSourcery 4.2-15 (or 4.2-8 Lite) versions since we have found that it has a bug in it. If you use -O1 all works but higher levels of optimisation, including -Os don't work. The reason is that the IRQs are compiled as normal functions with RTS rather than RTE!!


Here are some notes and CodeSourcery has confirmed that they can reproduce the problem:

> There are some uTasker users who's projects are based on CodeSourcery
> GNU. Some registers users have 4.2.15 and found that the project would
> no longer run but immediately crashes due to an address error.
> Therefore I have just downloaded the 4.2-8 Lite (which is probably
> 4.2.15
> like) to see what happens and it is the same on my M52235 board - the
> reference project doesn't run.
> The reason that I see is that the interrupt routines are trying to return
> using RTS (rather than RTE) which result in instant death.

 

Here is a quick step guide on how to configure the uTasker project in Eclipse.

1. See the tutorial from Paul at Cambridge Imaging: http://www.cambridgeimaging.co.uk/downloads/Coldfire%20IDE.pdf This explains how to find the software, how to install it and how to start working with Eclipse.

2. Start Eclipe and set the working directory any where you want it to be.

3. File | New | Project…
Choose standard make C project

4. Continue Set project name eg. uTaskerV1.3
Uncheck “use default location” and then set the uTasker directory as location.

5. Continue setting standard set up according to the C/C++ developers user guide until finished (I don’t think that there is anything critical – just defaults).

Afterwards you will see the uTasker project structure including document folder etc.
WARNING: Do not delete anything from the project shown in Eclipse because it will also delete the files from the hard disk!!!!!!!

6. Click on the project (highest level in the C/C++ perspective) and right click the mouse. New | File. Add a file called “makefile” which will then be created in the highest uTasker directory.
Copy the contents of the make file in the uTasker project to it and save.

7. Put the file “m52235evb-rom.ld” – also in the uTasker project– in the directory \Applications\uTaskerV1.3\GNU_ColdFire
This assumes that you have already added the SP4 to your project.

8.  Add a make target in the target window (on the right) and then double click on the green ALL circle.

The project should build and afterwards you have uTaskerV1.3.s19 / uTaskerV1.3.elf and uTaskerV1.3.map in the file \Applications\uTaskerV1.3\GNU_ColdFire and all compiled object files in \Applications\uTaskerV1.3\GNU_ColdFire\Build

Note that you can also compile the project by double clicking on Build_M5223X.bat in \Applications\uTaskerV1.3\GNU_ColdFire.

 
9. It is also possible to put the make file in the application target directory – the position of the make file has then to be set in the project (target window on right). This is in fact the prefered method since it allows several build projects in the same Eclipse project.


One last note. If you are using a CodeSourcery version above 4.1-32 you will need a slighty revised linker script file. This can be found on the service pack page - http://www.utasker.com/software/V1.3/m52235evb-rom.zip

If anyone has additional notes or would like to offer some tips for using the debug functions in Eclipse then please include them here.

Regards

Mark

275

NXP^TM LPC2XXX and LPC17XX / LPC23XX - Welcome

« on: July 09, 2007, 10:38:09 PM »

Hi All

The NXP LPC23XX was announced quite a long time ago. I think that it was originally foreseen for Q1 2006. Around Q3 2006 there were still no signes of it and there was a report of it being delayed until 2007.
But suddenly it was indeed available in Q3.

So I didn't delay in ordering my own eval board, which I also finally received in December 2006. I had been closely watching the NXP reports and the Yahoo forum where NXP has done a poll of members in an attempt to define the perfect chip including Ethernal (needs external PHY), USB (device) and a good balance between other peripherals, fast I/O, good operating speed and even external bus capabilities. Some rumours say that it is also the best ARM7 in its class. On the other hand there seem to be some nasty bugs in the first silicon.

But I don't really know the full details - the reason is that I had such a lot of work with the STR91 development and several projects using it, that I got totally behind with the NXP. Now it is time to catch up and work is now in progress to get to know the full details, port all drivers and get the uTasker project up and running in a stable state. The simulator has already been abapted and progress is being made. I do like what I have seen up to now...

I am using the Keil MCB2300 with LCP2378 device together with IAR embedded workbench and J-Link ARM debugger. Of course a GNU based project will also be made available.

So if you know more than me - which is not that difficult - then here's your chance to help us out. Or else if you are interested in participating in its development just let me know. On the other hand you can watch this space for updates as the development shapes up and decide if and when you may like to give the package a try.

Please use this forum section for anything to do with the NXP LPC23XX.

I look forward to reading your topics.

Regards

Mark

By the way. I did work quite intensively with the LPC210X a few years ago and found it a really nice chip. Unfortunately it doesn't have Ethernet but once the LPC23xx package is completed it may be worth while making a back port to this device. No promises but who knows...

276

ST^TM STM32 and STR91XF / STR91XF - Welcome

« on: July 09, 2007, 10:12:50 PM »

Hi All

The ST STR91XF is quite a beast.
It clocks at up to 96MHz (ARM9) has up to 544k FLASH and 96K SRAM, with fast I/Os, Ethernet (needs external PHY) and USB (device).
And being a beast it needs to be tamed, which can take some time.

The uTasker is presently in the pre-release project phase with most difficulties solved and a reliable project just waiting for more users to jump on board. It also supports the STR910 and STR911 parts.

The Ethernet controller is incredibly easy to use and works very reliably - at the time of writing I have one connected at http://84.75.9.2/ which has been running for the last 11 days in a DMZ. Some parts of the chip are powerful but rather complicated to get working. Some things are simply buggy and so all night sessions are necessary to get the smallest amounts of progress (check out the errata on the ST web site and check which revision you are working with before starting). But with its whopping memory and interesting price it can be worth having to take a few hurdles to get there.

A boot loader is already operational, allowing software updates via Ethernet while booting from FLASH bank 1. Full speed operation at 96MHz is fully supported in the project set up and various tricks have been learned on the way enabling support for those with the courage to roll up their sleeve and get stuck in.

Please use this forum section for everything to do with the STR91XF.
I look forward to reading your postings.

Regards

Mark

277

ATMEL^TM AT91SAM7X and AVR32 / SAM7X - welcome

« on: July 09, 2007, 09:28:22 PM »

Hi All

The ATMEL SAM7X became available early 2006 (some people managed to get samples earlier but they had some sort of export problem due to encryption algorithms used in one of the parts). The first time I learned about it was at a seminar where some Atmel representatives were demoing the ATMEL evaluation board. I was very impressed but had to wait quite a long time to actually get my hands on one of my own.

It combines Ethernet (although it does need an external PHY) and USB (device) with an interesting amount of internal FLASH and SRAM (128k or 256k FLASH - I think that there may be a 512k version now - and 64k SRAM). Its small FLASH granularity (256bytes) and ease of FLASH programming are nice, although the programming times are not necessarily the shortest.

Strangely this part seems to be preferred for educational work rather than industrial projects, although my own data based on the uTasker community may not be representative. I do wonder whether ATMEL themselves may be partly to blame (if it is true) by not giving it the promotion that it may deserve. The ATMEL forum was never really the best and general cooperation with developers just can't be compared to the likes of Freescale (for example).

But returning to the technical details; the SAM7X is not to be overlooked. It may not be the best chip in the world but is flexible and very capable in a lot of projects - its fairly large memory and interesting price, coupled with USB/Ethernet mix (also USB Boot program included) can not be ignored.

Please use this forum section to discuss anything to do with the SAM7X. Maybe we can help some others to discover a potential pearl among the embedded Internet enabled devices supported by the uTasker.

I look forward to reading your topics!!

Regards

Mark

278

Freescale^TM MC9S12NE64 / M9S12NE64 - Welcome

« on: July 09, 2007, 09:09:09 PM »

Hi All

The M9S12NE64 is an HCS12 derivative which first became available towards the end of 2004.
In fact this is exactly the chip which I was looking for to start a new embedded project with Ethernet support and fortunately it turned up at the time that I started looking.

The uTasker software was developed initially for this chip and with this chip. This was an interesting experiment since I wanted to see whether it would be possible to develop a TCP/IP stack from scratch using a new chip and the GNU compiler with my own debugging tools (which also had to be developed). It is fortunate that the DEMO9S12NE64 which I bought is delivered with a serial monitor program installed and that this program is documented in an application note from Freescale; it allowed a simple PC program to be written which could load code to FLASH, read and write memory and registers as well as set a break point before single stepping. In addition to that, it was necessary to understand the operation of the chip and its instruction set, but this forces learning quite a few important details.

Using a PSA (Pseudo-Assembler) file generated by the GNU compiler together with simple assembler level code stepping it was possible to get first simple programs to run but it was clear that this would be inadequate for more complex debugging jobs so this is where the uTasker simulator came in. In fact the simulator was not something completely new since I did have a forerunner of it which was pieced together for use in various projects, for example for the 8051 and for the LPC2106 to name a couple, but it was time to pull it together as a part of a new development environment. The dream that I had was to be able to get advanced information on new chips (specifically Ethernet controllers) and program up the simulator so that the not-yet-existant part could be programmed for. And indeed, working with data from Ethereal recordings, first steps were made to develop a TCP/IP stack integrated closely with the uTasker operating system.

The simulator worked well enough to enable the development of the first uTasker version for the NE64 with its drivers, file system and TCP/IP stack, using nothing more that the simple downloading, debugging tool (ne64_deb.exe as delivered with the uTasker for the NE64). Later a BDM project was added - this can be found on the web site under documents (projects and application notes). The present NE64 package includes Codewarrior 4.5 and IAR projects too.

It was however not until early 2006 - when the uTasker V1.2 was made available - that the simulator took on its present appearance and supported true Ethernet support via the PC's NIC. This was thanks to Joel W. who helped get the WinPCap bits to work together with it. In fact when I look back, I still find it hard to believe that the stack was developed before this stage - it would probably have been much easier now.

Although the NE64 is a neat chip - I still do projects using it and it is surprising how popular it still is!! - Freescale will probably  not further develop it in the future. Its big-brother, the M5223X is probably the long term solution of preference. Nevertheless the NE64 is still possibly the cheapest solution for small embedded Internet capable projects and it has earned its place in the uTasker project and will receive continued support.

Please use this forum section for all to do with the NE64.
I look forward to reading your topics.

Regards

Mark

279

NXP^TM M522XX, KINETIS and i.MX RT / Coldfire M5223X - Welcome

« on: July 09, 2007, 07:31:42 PM »

Hi All

The M5223X Coldfire from Freescale appeared around the end of Q1 2006 and Freescale promoted it with a series of low cost seminars where the visitors also received a M52233DEMO board with integrated P&E BDM which works together with the Codewarrior 6.3 128k limited special edition, which was also supplied. This device has since then established itself as a clear favorite for industrial uTasker based projects. I think that the Freescale strategy works well and of course the Coldfire  is a very mature processor with wonderful (68k based) architecture.

The device's peripherals are rich in features and powerful - some with DMA support. The uTasker project now supports most of these, from the UARTs in DMA mode through to CAN and, of course, the internal Ethernet with PHY.

The more you use the Coldfire part the more you appreciate its capabilities and I must admit that I do enjoy working with the M5223X more than some other devices. This may just be sentimental as I learned most of my processor stuff working with the Motorola 68302 (and DSP 56156) but it may also be that the chips are really that good.

But nowadays it is not just about ease of use but also about product development and production costs (although it probably always was...). High volume products can affort higher development costs even if the cheaper chips are more difficult to get working in the first place - [here one tends to think of ARM based ones...(?)]. In any case, the uTasker aims at keeping the effort involved in getting a project off the ground as low as possible, whether using the M5223X or another supported type. Check out the other processor specific forum sections for more details.

This section is dedicated to the Coldfire - presently the Ethernet M5223X types but soon also the M5222X USB ones too. So it is hoped that this will serve as a discussion platform as well as a useful information source for these chips.

I look forward to to reading your topics here soon!

Regards

Mark

P.S. Note that the uTasker package for the M5223X is now supplied with a GNU make file. This works also in the Eclipse environment and even the P&E BDM is supported, enabling a complete quality development chain based on open source solutions. Some users already use this and I have a simple quide to how to set up the project for use with Eclipse which I am sure will get posted here quite shortly - it will almost certainly be added to the tutorial in the next service pack.

280

µTasker general / uTasker welcome!!

« on: July 09, 2007, 10:44:32 AM »

Hi All

11:11 9.7.2007 and the first uTasker forum post is being started.

I hope that you find the forum of interest and of great use for your own work, whether as student, hobbyist or embedded software professional.

The uTasker project was born during December 2004 as an experiment with the, at the time, new Freescale M9S12NE64. Starting with a scheduling operating system which had found use in various projects over the previous years it aimed at integrating a TCP/IP stack and important processor peripheral drivers to give a useful base for typical embedded projects of this nature. There were four criteria which were adhered to:
1. It was to use the GNU compiler and the Freescale serial monitor so that no further tool investments were required (in the meantime the support of various commercial compilers and IDEs are also available since they also make sense in some circumstances).
2. It should be possible to actively work on the project, including development and testing, without hardware - so a simulator was needed. It was not to be a simulator which simulated at the instruction level (most IDEs have such a thing and they are good for testing small pieces of processor critical code but not very useful for complete applications) but allow 'real-time' testing of the application, especially web type applications. It should also be possible to introduce modules of new chips and peripherals before they are really available (from preliminary data sheet) so that real work on using the new types can be started in advance...
3. The software should be highly portable, allowing it to run unchanged (above the driver level) on any of the supported processors (as long as the processor really supports the peripherals required...)
4. The solution was not to be a copy of other available solutions and it was not designed to compete with these others. It was to be an 'alternative' and complete solution which was allowed to go its own way without necessarily respecting standard conventions. Bits and pieces not required for the types of embedded tasks intended for could be left out but the final solution should include the essentials to do the job in a professional and comfortable manor. Short cuts and restrictions are allowed where they make sense but the global solution should still be usable by all, even with limited experience of embedded processing and microcontrollers.

Today the solution is used by a community of students, hobbyists and professionals and this is good. This helps to test how well the goals have been achieved and where not, gives important feedback as to in which direction the continued development should take.

Check out the processor specific forums for more details about the processors which the uTasker now supports and the state of new developments.

Please use this forum for what it is intended for - to communicate with other users and me, to ask questions, make suggestions and above all just have more fun with your own projects.

I hope to see you on-line in the near future!!

Cheers

Mark

P.S. My thanks go out to Stefan from E-Future for his valuable help in setting up this forum and integrating it into the web site. Thanks!