Messages

3241

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

3242

NXP^TM LPC2XXX and LPC17XX / Re: Timescales for the release of a LPC23xx version

« on: July 11, 2007, 04:58:08 PM »

Hi Martin

Well I don’t advise holding your breath until it is ready since it is really only just getting started here.

Due to the holiday season which is almost upon us I wouldn’t expect a beta until September. This will include the TCP/IP stack as in the demo project shown online at http://84.75.9.2/

The port to the LPC23XX doesn’t involve porting anything at the stack level, although there are a few I/O demos in the project which have to be set up, but rather at the driver level (UART, EMAC, PHY, Timers, FLASH driver, etc.). However there will not be USB support at the beginning – this is planned generally for the project in autumn.

I have used Rowley GCC with the SAM7X but will initially work with IAR on the LPC project.

I don’t know exact comparisons with the other light weight stacks you have mentioned but one big difference is that I think we have a lot more practical features such as HTTP post, Telnet with high speed windowing for example and details like VLAN, plus the uTasker includes a complete project set up with OS, device drivers, complete project as demo, plus a unique simulator (best you try it to appreciate it) and of course full support.


Probably the best thing to do is to try out an available package – the SAM7X is probable the closest (or STR91) and give it a test drive in the simulator (if you don’t have an eval board). You can test everything to do with the stack there and identify its strength and weaknesses in respect to your project. The LPC23XX parts do already run in the simulator, where their ports and peripherals have been prepared but still steal a lot of driver code from the SAM7X – these parts are to be gradually ported until it can run in its real ‘body’.

Perhaps someone else can comment on other available packages like uIP and LWIP?

Regards
 
Mark

3243

µTasker general / Re: External EEPROM alternative to M95xxx

« on: July 11, 2007, 12:58:44 PM »

Hi Dean

Congratulations. I will study your code changes in detail since it will be useful to ensure that the solution is generic for small and large chips. This will certainly save me some time on my project too!!

Another suggestion is to use the program memory based error 404 message as uninitialised eeprom would result in a totally blank page.

This restriction is historic and also due to the fact that presently only FLASH or SPI FLASH can be used at the same time. When using SPI FLASH it is only possible to serve pages from there and not to set some to be served out of program flash. That is the reason why the last file block defaults to 404 error file position, but of course requires that the equivalent html file is really loaded there. This is what I will also have to solve in my next project.

but the web page takes about 7 seconds to load

This is a bit longer than I would expect (ensure that there is really no repetition somewhere) but serving large pages is not that fast. The reason is that the HTTP server doesn't send TCP frames using windowing. This is typical for small TCP/IP stacks and has two reasons: firstly it is very simple and reliable; secondly it doesn't need any ram buffers. Using traditional TCP windowing it would be necessary to have several k buffer space for each session - and if say 5 users could access the same web server at the same time this makes 10..15k of RAM, which the small footprint chips have problems to deliver.

First the calculation:
28k will be served in about 28000/1400 frames = 20 where 1400 is the approx. TCP frame payload (check that you have set this (HTTP_BUFFER_LENGTH in app_hw_xxxx.h) since it can be set smaller to save memory on smaller devices (like NE64).
The PC running teh browser will be working with "delayed acks", meaning that it will ack TCP frames after about 200ms delay, in the hope that the application will send data earlier on to which it can 'piggy back' the ACK - this saves sending short frames in some circumstances. Since the Web browser is not sending anything, it results in each ack being delayed by about 200ms and therefore each served frame also being delayed by 200ms.
20x200ms = 4s. I would expect about 4s rather than 7 but this explains basically why it is not that fast. (this is however content specific as well. The dynamic web parser does sometimes have to cut some frames in length if it is not possible to pack in the generated data in the space available).

In the other direction there is no delayed acks in operation and so uploads are (adequately) fast in a LAN.

Typical web pages of only 2k or so are not noticably slow but of course if you have more memory you can afford to have flashy web pages, where this then becomes apparent.

It just turns out... that I also have the same problem with my new project and so my plan is also to add a special windowing technique to the HTTP server where two frames may be sent at once. The TELNET server uses buffered TCP and this does full windowing and achieves fast bulk transfer but it has to have a buffer to work with (its size is defined by TCP_BUFFER in app_hw_xxxx.h). This buffer is absolutely necessary since data is of a random fashion - for example debug outputs from code or data passed from another input like UART. If there were never frames lost it would not be necessary but in order to be able to repeat TCP frames it must have a backup of the data previously sent. In fact most TCP implementations will require a buffer size of twice the data length due to the fact that TELNET can perform byte stuffing if it is operating in ASCII mode which in the worst case doubles the length of the transmitted payload which needs to be backed up. This is not the case in the uTasker since its solution never saves byte stuffed data (which is a bit more complicated) but reduces the maximum buffer space requirement by factor 2.

But back to HTTP... The fact is that once the transmission side actually sends two TCP frames without waiting for the ack of the first, this is already adequate to reset the delayed ack algorithm used at the PC with the browser running on it. Allowing just one outstanding ack is not very difficult and, due to the fact that HTTP served data is essentially static (not of random nature) it is possible to regenerate lost frames without having a buffer, but rather with maybe one or two additional pointers saved in each HTTP session object. My hope is that it will then achieve high speed serving at the cost of only a few bytes RAM and probably a couple of hundred bytes extra program space. Plus the added development complexity until it all works correctly...

I will tell you as soon as there is something ready so that ou can verify its performance.

Regards

Mark

3244

µTasker general / Re: turning off FS

« on: July 10, 2007, 11:05:43 PM »

Yep - the post only handles predefined file types and to be honest I have never uploaded html files using the post method (that is the only reason why it is not there).

(although I could image using a default post page - like you use the 404 error page - to allow a user to upload all web pages in a project. This would allow the FTP server to be completely removed in favour of working purely with a browser. This would also remove some contraints when working with FTP whereas it often needs special firewall setting because people/companies are sometimes very restrictive with FTP ports.)

Generally it is possible to add further post types or, as you have done, make the text based type less restrictive. I will have a think and maybe add more text types or a general 'catch all' text type. In any case you seem to be having no real problem with the code and as you have seen it is not that difficult to add some more flexibilty if needed in an emergency.

For this type of work I never in fact work on the target - the simulator lets you test and develop much faster and comfortably. But I am assuming that you are using the Coldfire on an eval or your own board, and debugging is generally performed out fo FLASH (there is only 32k SRAM and this is usually too restrictive to share with a program and variables and decent LAN buffer space - RAM debugging is only possible with mini-programs. For Ethernet projects any spare RAM is best used for LAN buffers since here the rule is simply 'the bigger the better'). When working with Codewarrior, pressing the debug button will simply connect to the device in debug mode and doesn't mean that the FLASH content corresponds with the latest compiled project state. Therefore it is always necessary to first synchronise the FLASH contents using the FLASH utility tool.

Although this works well, you still have a limited amount of breakpoints (three I think) and the FLASHing time adds up throughout the day. This is another reason why it is best to do as much work with the simulator (no download times, very fast compiling, great debugging) as possible. Based on our own experiences over the last few years (we also had a forerunner of the simulator before the uTasker project) it is possible to cut many embedded project development times by around 60% by simply using the simulator consequently and then working on the target for verification and low level details.

As far as I understand, it is the browser which recognises the file type when performing the post. I don't actually understand what criteria they use and I have in the past simply looked at the content infomation to learn whether a PDF is for example of binary or other type.

I don't know whether you have already noticed but the port method used is a little special...
You will find that the uTasker project is a bit 'alternative' and sometimes does some little tricks to enable useful things to be performed without having to go a long way to do it.

Code: [Select]

<form action=HS.bin
enctype="multipart/form-data" method="post">
<p>
<input type="file" name="datafile" size="30" £DN0></p>
<p><input type="submit" value="Upload new software" £DN0></p>
</form>
You obviously know this extract from the post HTML.
If you have already learned a bit about the way the dynamic web serving is operating you will know that the £DN0 sequence means "disable the form field if the project doesn't have a large enough file system for a software upload". I am sure that much more detail of such things will be posted soon in a thread of this topic.

The form action=HS.bin is interpreted by the uTasker web server as "post the file which will follow to the file system and name it H.bin. Once the post has completed, serve the web page S.html". Of course the application can intervene and do it differently, but if it can also let the web server part do as it is told. This is practical because it allows the html file to define where posted data ends up in the file system and also what page to serve on success, and is very practical for the software upload in the demo project because the user can upload new software with any name he/she likes and it still ends up in exactly the place in FLASH that you want it to end up at. Afterwards, the web server serves a nice page thanking him/her for doing its and informing that the board will now be reset to complete the update. All will almost zero effort at the application layer!

Possibly this explains what you have been seeing with the different test uploads. If you post an html but set the post up to save it as a bin, it will display as a bin type in the file system (eg. look with FTP). Only files with HTM(L) file types will in fact be parsed by the the web server - this is because if every thing is parsed, including images, any occurance of a special sequence (as used for controling dynamic infomation) in the images would be interpreted and then cause corruption of the image...

Regards

Mark

3245

µTasker general / Re: External EEPROM alternative to M95xxx

« on: July 10, 2007, 08:52:45 PM »

Hi Dean

I have plans to do the same in the very near future with the ATMEL AT45db041 (there is one on the ATMEL SAM7X EVAL board). I expect that they are more or less equivalent.

Here are my tips for your attempt.
1. Configure the project to use SPI File system rather than FLASH based file system (SPI_FILE_SYSTEM rather than FLASH_FILE_SYSTEM in config.h).
2. Set up a new EEPROM size in app_hw_xxxx.h. Eg.

Code: [Select]

#ifdef EEPROM_64K
    #define EEPROM_PAGE_SIZE 128                                         // respect larger page size in SPI EEPROM

    #define FILE_GRANULARITY (2*1024)                                    // File made up of 2k byte FLASH blocks
    #define SINGLE_FILE_SIZE (1*FILE_GRANULARITY)                        // each file a multiple of 2k
    #define FILE_SYSTEM_SIZE (32*SINGLE_FILE_SIZE)                       // 64k reserved for file system (including parameter blocks)
#endif
3. Note that the SPI EEPROM support is actually 'emulating' a FLASH device so it shouldn't actually matter whether the device is really an EEPROM or a FLASH type.

4. The simulator will probably not actually work correctly yet because the larger devices probably require different addressing (more bytes to address more address lines). This will mean getting into the driver routines:
- first you will have to change the actual SPI accesses if they are not compatible.
- then you will need to add the simulated FLASH in WinSim.c. You will see that the low level SPI routines call fnSimM95xxx() and so they will need to call fnSimM25PExxx() instead. In fnSimM25PExxx you need to look at what the SPI is sending and try to react as if it were the real device. This will enable both sides to be developed together and fnSimM25PExxx() also checks that the SPI driver is really doing that what you want to do with it. Depending on the commands, the simulated FLASH writes to a local memory of the same size as its FLASH or returns data from it.

5. Once this is operating correctly it is best to save the contents to disk on program termination and read them back on on start - see the routines fnPrimeFileSystem() and fnSaveFlashToFile() in FileToDisk.c.

The last job would then be to check that it really all works like that when you test on your target with the real device connected. Often it requires an itteration somewhere but sometimes it is possible to get it right first time - in any case it usually is much faster than trying to do the whole job directly on the target.

Good luck

Mark

P.S. I would also like the possibility of operating with both internal FLASH and external SPI based FLASH at the same time. This is probably a bit more complicated since the project is presently set to do EITHER / OR...

3246

µTasker general / Re: turning off FS

« on: July 10, 2007, 08:27:23 PM »

Hi

Now I have the details.

1. When posting, also make sure that you know what type of data is to be posted. Images, Text, binary etc. The single or multiple file types should each be defined (SUPPORT_POST_BINARY and/or SUPPORT_POST_TEXT and/or SUPPORT_POST_GIF). Unrecognised file types will be received without any errors but the contents will be dumped.
This is not a problem that you have since you already get further than this.

2. When the post begins, the call back event CAN_POST_BEGIN occurs, including details about the socket receiving the post. The details include a pointer to the file location where the file WILL be stored.
Your call back rountine (fnHandleWeb() in the demo SW) can check the file location if it wants and also change it - diverting the data elsewhere. In your case you can choose not to save it to a file by setting the file pointer to zero:
 

Code: [Select]

HTTP_session->ptrFile = 0;  // we decide not to save this to a file but handle it ourselves
Note that you can also decide to refuse the post by returning any non-zero value.

3. For each frame you receive you will need to handle the event POSTING_DATA_TO_APP (I think that you probably already have seen this).

4. After reception of all of the data the event INFORM_POST_SUCCESS or INFORM_POST_FAILED (only when serious error) will be received. You then know that the data has been completely received and you can then cause a different web page (or default) to be served - see the uTasker demo which already does this.

So I think that you only need to clear the ptrFile field in the call back and this will allow the post to operate as you require, thus without modifying the HTTP code.

Regards

Mark

3247

µTasker general / Re: turning off FS

« on: July 10, 2007, 07:19:10 PM »

Hi

Best continue with this change so that you can ensure that all otherwise works the way you want to use it.

I have used this for writing posted data to a BDM in the past and will check out the details about the pointer - I'll report back as soon as I have details.

Regards

Mark

3248

µTasker general / Re: tftp tests

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

Hi

Yes, this is correct. The tftp support was added in a service pack and the service packs update the code but not the project (I will look at the feasibility of including an upgraded project file in future service packs to automate this).

For example, if you look at the service pack release notes for the M5223X you will see that tftp was added with SP3 and the upgrade guide states:
"TFTP.c will have to be added to the simulation or target project if TFTP is used."

However you are correct that it would be neater if this were automated. The only risk is that it needs to be updated in all project files (VS, GNU, Eclipe, Codewarrior, IAR, and any others which are supported) and so it is difficult to shut out all chances of a mistake when adding services to an existing project.

Thanks for the tip though and I will see what can be done.

Regards

Mark

3249

NXP^TM M522XX, KINETIS and i.MX RT / Re: USE_IP_STATS

« on: July 09, 2007, 11:54:13 PM »

Hi

You are correct, I can confirm this and have corrected it so that all occurances of fnIncrementEthernetStats() in the M5223X hardware module are removed when USE_IP_STATS is not defined.

I also verified that the other processor projects are not affected.

This counter was added some time back to verify the overrun rate in particular networks when reducing the rx buffer count and with/without the use of smaller rx buffer chaining (configurable by NUMBER_OF_RX_BUFFERS_IN_ETHERNET_DEVICE (6 recommended) and USE_MULTIPLE_BUFFERS (not generally used))

Thanks again.

Mark

3250

µTasker general / Re: turning off FS

« on: July 09, 2007, 11:42:37 PM »

Hi

I think that this is the correct place since the question is not that platform specific. It is just as valid for an ARM project for example.

I understand that you would like to use the web server just to allow posting software. In this case replacing the 404 error page with a post formula is reasonable trick - note that most chips can be used with the define "SUPPORT_INTERNAL_HTML_FILES" which enables the web pages to be positioned in code rather than be uploaded via FTP (this is not possible with the NE64 project since it uses banked memory and one bank especially for files where HTTP always wants to access in the bank rather than use linear memory).

You are correct that normally the HTTP server works quite closely with the file system, which is generally logical since most HTTP use is to do with file reads and writes (mainly reads...). However it is also possible to use the option "SUPPORT_HTTP_POST_TO_APPLICATION". In this case the data which is received by the post is not actually saved to a file but rather passed on to the application. Your fnHandleWeb() call back can handle the event "POSTING_DATA_TO_APP", which is passed with a pointer to the data in the frame and the length of the data.
Then you are free to do anything you want with the received data - typical application are to send it to another port or write it to a device like an FPGA, but of course if you have routines that write it to your required location in FLASH this is probably what you need.

The only possible catches I see are these:
1. the parameter system (managing application parameters and IP config etc.) is realised as part of the file system code so completely removing the file system may cause some difficulty there - depending on whether you need the parameter support or not.
2. You may find it easier to keep the file system but replace the routines (or some of them with dummy calls to ensure that all compiles and links). I am not sure though.
3. You may find that you need a certain amount of code from the file system simply for saving to FLASH (you can also look in the boot loader code since this has a minimum solution for FLASH operations) and I am wondering whether you may find it easier with only quite minimum code size requirement to still use the file system in the project. According to code size comparison in the M5223X tutorial the file system code occupies about 2,3k FLASH. This includes also the low level FLASH driver routines for the M5223X so potential savings will be somewhat less.

Take a look at SUPPORT_HTTP_POST_TO_APPLICATION support. I would run the uTasker simulator and check that your HTTP post data is really passed to call back - check with data sending several frames to ensure that the file system never kicks in somewhere. When the application detects the end of the file you may like to have a second small web page in the program code which it then serves. See how fnHandleWeb() handles the end of a normal post to the file system - it receives the event "INFORM_POST_SUCCESS" and then specifies the web side to be displayed out of program code by returning "DISPLAY_INTERNAL" .

If you are lucky you may find that the HTTP code itself doen't require any manipulation to achieve what you would like.

Good luck

Regards

Mark

3251

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...

3252

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

3253

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

3254

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

3255

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.