Messages

3256

ST^TM STM32 and STR91XF / Re: STR91XF Pre-release

« on: July 13, 2007, 12:44:03 PM »

Update 1: http://www.uTasker.com/software/STR91XF/STR91XF_Update_1.zip

Hi all STR91 users / testers


1. CPU Speed.
To set the PLL speed there are the following defines in app_hw_str91xf.h.

Code: [Select]

#define CRYSTAL_FREQ    25000000                                         // crystal or clock input frequency (4 to 25MHz)

#define OSC_DIVIDE      25                                               // 1..255

#define PLL_MUL         192                                              // 1..255

#define POST_DIVIDE_EXP 3                                                // 0..5 (3 for 48MHz, 2 for 96MHz)
 

You no doubt know that the STR91 can operate at up to 96MHz. This setting is however for 48MHz operation. The various register settings can be modified to generate various speeds and there is a checking routine which will cause a compile error to be generate if the user tries to set anything with an illegal value (eg. the PLL intermediate frequency must be between within 200 and 622MHz ). See the users’ manual for detail – section 2.4.

To work with 96MHz clock POST_DIVIDE must simply be set to 2 instead of 3.

Note also that when the uTasker simulator is running it displays the exact PLL frequency that the CPU would be running at.

Running at 48MHz is no problem. However to achieve fastest operation there are a number of settings which have to be correct. I have used the ST application note http://www.st.com/stonline/products/literature/an/13563.pdf as reference.

The project does however adapt itself according to the PLL. For example, the PCLK should not be faster than 48MHz and so dividers must be set when the PLL is greater. Then the FLASH wait states has to be increased when operating at over 66MHz. See fnSetFMI() in str91xf.c – here I have had to make a correction so that it operates correctly from bank 0 and bank 1 at all selected speeds.

Then there are some new errata. It is best to collect these from the ST web site. One important point to note is that the original chips (rev. B and D for example) have a problem at 96MHz which means that a reset is only effective when it is a power up reset – this means that debuggers can not really work at 96MHz- check the chips you have on your boards to see whether you have this limitation!! If you do (which is unfortunately very likely), stick to 48MHz for the moment.

There are also some errors (also in the last silicon) to do with clock dividers. In fact I got caught out and I still believe that there is another bug which means that it is in fact necessary to set PCLK to RCLK/8 to get it to divide by 2!! See the following forum discussion for full details about the state of development: http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5460&forum=21

 
2. PHY. I tested the PHY and found that although it is responding correctly I am not getting the expected interrupt on link up/down. I also found out that the ST PHY doesn’t correspond to the typical PHY register set so I have had to change the defines for it in the header file. This is an open point – see the following forum posting for more details: http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5489&forum=21

 
However this doesn’t actually affect normal operation – there is just no link up/down events of they were needed.

3. I have added low power support (define SUPPORT_LOW_POWER in config.h) but haven’t actually verified it yet… This uses the IDLE mode of the chip to stop the CPU clock when there is no processing to be performed. As soon as a peripheral interrupt arrives it should continue operation. I have used this successfully with the Coldfire and the SAM7X so I am hoping that it also works well on this chip.


Plan of attack:
- I still have to test the boot loader. The project compiles and I have already successfully used the boot loader with the chip (although not yet over Ethernet).
Since the boot loader occupies only 2k of an 8k FLASH block in Bank 1 I think that it will be useful to add also loading via UART.
- Then I plan to configure a RIDE GNU project (I have successfully used RIDE with the STR91 but it is some time ago and needs main and boot builds).
- Once the RIDE project is good there will be a GNU build but I would then like to use a stand-along GNU build and probably an Eclipse project with it.


If you have any remarks or results from your own tests please let me know.


Thanks for your help.


Best regards


Mark

3257

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

3258

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

3259

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

3260

µ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

3261

µ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

3262

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

3263

µ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

3264

µ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

3265

µ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

3266

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

3267

µ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

3268

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

3269

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

3270

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