Messages

3256

µ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

3257

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

3258

µ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

3259

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

3260

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

3261

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

3262

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

3263

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.

3264

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

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

Hi Kremer

Congratulations on posting before I even had a chance to add a welcome post to this section!
Unfortunately (for me) I had a dental appointment just after I managed to switch everything on line so I didn't get the chance to post in each section - but many thanks. I hope that the new forum helps with the exchange of data and with networking between users of the chips too.

Look forward to seeing you around in the future!!

Regards

Mark

3265

µ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!