Topics

226

Luminary Micro ^TM LM3SXXXX / uTasker Beta release for the Luminary Micro processors now available!

« on: March 23, 2008, 01:28:26 AM »

Hi All

It is finally ready - a Beta release for the new Luminary Micro package!!

It contains IAR and Rowley Crossworks GCC projects and its use is detailed in the tutorial:
http://www.utasker.com/docs/LM3Sxxxx/uTaskerV1.3_LM3SXXXX.PDF

There are also new binary files for anyone who would like to load the project directly to their own board - get them from:
http://www.utasker.com/software/software.html

These are nice chips to use and the Luminary Micro's evaluation packages contain all that you need to get working with your first Cortex M3 device at attractive prices, so there is nothing standing in your way to give them a try!

Remember that the Cortex M3 delivers about 20% more performance than ARM7 in ARM mode, but runs in space saving Thumb 2 mode - here is a quick comparison between code sizes of the demo project between the LM3S6965 and the NXP LPC2378 compiled in Thumb mode:

LM3S6965 compiled using IAR = 46'500 bytes FLASH; using GCC 51'100 bytes FLASH (Cortex M3 Thumb-2)
LPC2378 compiled using IAR = 48'000 bytes FLASH; using GCC 55'500 bytes FLASH (Thumb mode)

New users of the new chips are very welcome! Just send in the application form to receive complete code and join in to help extend the project: http://www.utasker.com/Licensing/request.html


Regards

Mark

227

Luminary Micro ^TM LM3SXXXX / New demo for Luminary project

« on: March 19, 2008, 09:43:43 PM »

Hi All

The release of the well overdue Luminary project for the uTasker is almost ready.....therefore a couple of details and a link to the latest demo.

The project will be available for IAR and Rowley Crossworks (GCC) including all standard Web support and up to 3 UARTs. This can be seen (apart from the UARTs, which are however working correctly [at least UART0 which I just tested]) at the following demo address:

http://demo.uTasker.com

It has the standard web server stuff with SMTP (so send yourself a test mail), TIME SERVER, TELNET etc. and the code was compiled using GNU - measuring around 52k in size including UART driver code. (Don't forget, the Cortex M3 core uses Thumb 2 mode and so ARM/Thumb modes is a thing of the past, generating Thumb-size code with even more performance that ARM code mode).

I am now satisfied that I understand enough about the chip and the development tools to complete the tutorial so that the package can be distributed. I have made a developer's log of all problems that I encoutered on the way, technical details and ideas about the strengths and weaknesses of the chips and their peripherals. These details will probably find there way into future theads...

I am quite excited about the new uTasker package due to the great number of chips which Luminary offers - a large percentage of them have Ethernet on-board (including PHY) and the uTasker potentially supports all of them - starting at the smallest, the LM3S101, in 24 pin package with 2k RAM, 8k FLASH and one UART. The project can very simply be configured to run on this device and various other parts can also be simply added when and if needed.

The first release (Beta) will be available for all who have signed up for it - you will receive a direct email. New users are always welcome; simply sign up on the license request page: http://www.utasker.com/Licensing/request.html

There are still various drivers to be added and lots of further details to be discovered - it would be great if anyone is interested in doing some work on the project to get as much out of these interesting chips as possible.

I look forward to the official release announcement in the next days!

Regards

Mark

228

Luminary Micro ^TM LM3SXXXX / New Luminary parts and packages

« on: March 17, 2008, 04:26:05 PM »

Hi All

Here's a copy of news from Luminary Micro about the introduction of 20 new parts (that makes 124 different now available) as well as new temperature and package options.

"Twenty new Stellaris family members providing cost-effective entry points and precise motion control support are immediately available for order. Additionally, Luminary Micro extends the capability and reach of the entire Stellaris family by announcing a new small BGA (ball-grid array) package option with a space-saving 10mm by 10mm footprint and a new extended temperature option with a -40 to 105 degrees Celsius operating temperature range."

See the original news release at: http://www.luminarymicro.com/products/whats_new.html

Regards

Mark

229

µTasker general / TCP/IP Offload problem with Vista

« on: February 16, 2008, 09:14:43 PM »

Hi All

I had a case where the uTasker project was not operating correctly together with a PC running Vista. Thinking that it must be due to an incompatibility with the simulator somewhere I offered to debug it (not actually using Vista myself just yet). It turned out to be due to the fact that the PC was not sending a check sum in its transmitted IP frames (sending 0x0000 in place) and so all IP frames to the uTasker simulator were being rejected.

Strangely it was not doing this to all connections - which I didn't managed to understand - but it turned out that there is a setting in Vista for the characteristics of the network adapter which allows IPV4 offload settings to not work with the check-sum of rx, tx or both direction of IP frames. This offload setting was enabled and disabling it solved the issue.

I am not entirely sure whether it was an incorrect setting for the network card or whether someone had been playing around with it but I didn't find anything similar on my XP based PC.

The reasons for this feature (including pros and cons) can be discovered at the following link:
http://en.wikipedia.org/wiki/TCP_Offload_Engine

Searching the Internet for more references turned up a lot of cases of unreliability or intermittent Internet problems which were eventually tracked down to these settings - so it may be good to know about them just in case.... in fact a few cases do spring to mind which were quite similar: ARP works correctly since it is not built on IP so the ARP entry is seen, but communication just isn't possible.

Regards

Mark


Follow-up:
On a new Vista PC I had a problem but didn't see that any checksums were missing. Well, not using Ethereal on the network, but the simulator was really receiving 0x0000 in place fo the IP checksum (presumable because WinPCap is sniffing before and hardware which is adding this).
The minimum setting change can be performed by:
- System -> network connections -> NIC configuration -> Characteristics -> Configuration -> Extended -> IPV4 Checksum offload -> change from "Rx & Tx Enabled" to "Tx Enabled"

Additional note: there are in fact settings for different protocols too. (TCP and UDP) For example I found that NETBios was not working correctly when simulator (but stangly was to other devices on the network). Looking more closely it was evident that the UDP check-sum was being sent incorrectly (although the IP check-sum was OK). After disabling rx and tx offloading for UDP it worked correctly.

230

µTasker general / USB Development 'Blog'

« on: February 13, 2008, 02:18:49 AM »

Hi All

Since the uTasker USB development is now (finally) in full swing I thought it timely to start writing a bit of information about it. The first project base is with the Freecale M5222X USB Coldfire with OTG (On-The-Go) capability but the stack is being constructed in a way to allow as much HW independency as possible. The present state (as of writing) is that a first HID (Human Interface Device) class is more or less up and running, but there is still a lot to do and learn before it can be considered as complete... so here's the first installment of a USB development 'Blog' for anyone interested in future USB, or  just enjoys having a laugh at the frustrations of a lonely software developer...


Introduction

USB (Universal Serial Bus) has firmly established itself in the world of PC connectivity. Originally a lot of people were very sceptical about whether it really represented the solution which its promoters reported it to be. How could it compete with Firewire? Did it really have any advantages in any function other than a new method of connecting dongles without having to pile them on the parallel ports? When will it be ready to really be used if Windows NT isn’t going to support it?

But history has shown that it does have a number of benefits which has enabled it to become the new connectivity standard. The version 2.0 has also increased operating speed capabilities to almost the Firewire performance level, at lower costs, and so now there are only a few areas where the interface can not be used.

My personal experiences with USB

I once had a project which involved USB 1.1. This was back in about 1999 when it was still quite new – new Windows 98 PCs already had good support for USB (the hardware had maybe 2 physical connections if one was lucky, whereby one was generally used by the USB mouse, although often PS-2 connections were available too). There were reports about a Windows NT version (possibly a service pack) which would also support USB and the project I was working on absolutely had to be compatible with Windows NT. As the project preparation evolved and the USB controller chips had been designed into the circuit board it became apparent that the NT promises were probably not going to be kept and so a USB interface was also probably going to backfire due to this – the idea was scrapped in place of a standard RS232 connection, which was also adequately fast (I think that later versions of NT could use a USB mouse but didn’t seem to really do much more than that).

So the first project, which would have given some useful early experience, fizzled out. Since then I have not had a second project which required USB and so the only further experience was as a user, where my main impressions of the technology are of headaches trying to get the PC to find drivers for newly installed devices; PC crashes when connecting; my digital camera which worked with XP for about a week and then reported that the device was no longer usable and has never worked since (although an old Win 98 laptop still works fine with it); strange behaviour requiring a USB connected device to be plugged out and back in to get things back to normal; drivers which need to be installed again after simply stopping working (P&E USB Coldfire Multilink is a classic example!!); why does my USB mouse sometimes stop working entirely when debugging with the P&E Coldfire Miltilink?; devices which work great with one PC but refuse to be recognised by the next; having no idea which COM port is being used when connecting a USB-RS232 converter – and it moving around when plugged in to a different connector; and….

As you can see – my experience has not always been the best and I still am very reluctant to use USB in any project where reliability is of importance. On the other hand, I haven’t had the knowledge to be able to solve such problems or identify their causes – I don’t know whether these problems are due to basic USB deficiencies, poor drivers or flaky embedded software, or hardware related issues, or user related stupidity….so it was time to learn more!

How to start with USB

I have read a lot of stuff about how simple USB is to use and it is also true that there are a great many USB controllers and processors with integrated USB which make life very easy. By loading demo software to the chips they do of course operate, but demo software generally is just that – it shows that it can work and does work (sometimes to a degree) but usually has no prevision for error handling and recovery from fault conditions which is important to achieve real long term operating reliability. So demo software is a useful starting point but the developer still needs to have a good understanding and the capability to extend and correct when moving from this starting point.

There are also a lot of USB books and or course masses of on-line information. I have read a lot of this and started with a nice muddle of terms such as “endpoints”, “Tokens”, “descriptors”, “functions”, “Enumeration”, “PIDs”, “IN and OUT transactions”, “Bulk and Isochronous”, “IDLEs, SOFs, EOPs transfers”, “Low, Full and High speed devices”, “Bit-stuffing and NRZI-Encoding”, “Hubs, Devices and the all important SIE” .. not to mention OTG.

So I had read all about it and heard how easy it all is (I mean everyone is using it nowadays), so surely I could pick up a processor with integrated USB interface and type in a few C-command to get it all going!

Fact is, I still didn’t have a clue…..

How on earth does one start implementing a USB stack?

Since I was serious about getting this sorted out I decided that a USB analyser was an essential tool to spy on the USB bus and see what is going on and later what was going wrong with my attempts. I went for the Ellisys USB Explorer which allows recording and analysing low speed, full speed and high speed links. It is not the cheapest and also not the most expensive analyser available but I didn’t want to miss out on having also the high speed support and have to buy a better version later anyway.

So with a muddle in my brain but with a hardware USB analyser at my side, plus a couple of reference books and some demo software as starting point it was at last time to get my coding fingers into operation and get my PC communicating with my first USB project.

----------------------------------------------------------

In the next installment I will introduce the Coldfire M52223 and some details of the enumeration process.

Regards

Mark

231

NXP^TM LPC2XXX and LPC17XX / LCD demo on MCB2300 using GNU - volatile register...

« on: January 31, 2008, 11:40:51 PM »

Hi All

The LPC23XX Beta version includes an LCD demo which is set up for use on the Keil MCB2300 board. This also runs when compiled with the IAR compiler (at least the version which I use..), but it was known that the LCD remains blank when compiled with Crossworks (GNU). Since the LCD is not the most important thing this (small) details didn't hold back the release but a quick attempt to solve it beforehand didn't result in any quick fix.

But today I did fix it after some head scratching stooped over the logic analyser screen. The timing was a bit different but nothing which seemed out of specification. But it finally became clear that the display was simply not driving the bus when read - which turned out to be not exactly true but rather the LPC23XX was not setting the bus lines to high impedance (not necessarily obvious on analyser display).

In such cases it is invariably due to some optimisation and in this case it turned out to be a register that was not declared as volatile causing the bus direction control to be totally removed.

To get this working, the following line in LPC23XX.h fixes it in case any Crossworks (GNU) user would like to see it running correctly.
#define FIO1DIR                          *(volatile unsigned long*)(FAST_GPIO_BLOCK + 0x20)

But this throws up a few background questions which should perhaps be looked at in a little more detail:

Why is there this problem when compiled with GNU but not with IAR?
It all has to do with how the compiler optimiser handles the case and possibly also what level of optimisation is actually being used. The uTasker project always uses the highest level of optimisation for size and so it is also expected that the compiler does what it can to save unnecessary code space.

How and to what degree this takes place depends on the compiler intelligence (or stupidity depending on how you look at it) and generally a quality compiler (which one tends to pay a lot more money for) is expected to squeeze more code into a certain amount of code space (this will often also translate into code which needs less instructions to run and so is not a bad choice.)

In the example, the following lines of C-code are considered to be totally unnecessary and so are removed by the GNU compiler with full optimisation (stupid or clever?) and considered to be necessary by the IAR compiler (dumb or very clever??):

FIO1DIR &= ~LCD_BUS_MASK;               // set LCD bus to be input
..write data and clock
FIO1DIR |= LCD_BUS_MASK;                 // set LCD bus back to driven state

Since the value of FIO1DIR is the same after the second operation as before the first operation was performed the optimiser may simply remove both of the lines, and save a few instructions in the process to allow (non-operational code) to fit into less FLASH space and be executed faster!

How does the use of volatile help control this?
The volatile type attribute was added to ANSI-C in its second edition. It informs the compiler that it must not perform optimisations on the variable and is typically used when the value stored in a variable can not be considered as remaining stable - eg. a port input is an obvious case since it can change at any time. Other example would be a variable which can be accessed by a DMA controller and thus changed at almost and time with out this being visible in the program flow.
 
Finally- why are all registers not simply set to be volatile and then such problems should be automatically avoided?
There are some headers for ports which contain only volatile defines. These will not be able to suffer from optimiser operation and so are obviously very safe.

However consider the following:
#define FIO1DIR                          *(unsigned long*)(FAST_GPIO_BLOCK + 0x20)
#define FIO1PIN                          *(volatile unsigned long*)(FAST_GPIO_BLOCK + 0x34)
#define FIO1SET                          *(volatile unsigned long*)(FAST_GPIO_BLOCK + 0x38)

This is a small extract from the uTasker header for the fast ports in the LPC23XX.
By looking at it it is clear that the FIO1PIN register value (which reflects the state of inputs) can change without this change being a consequence fo a CPU access. The optimiser can not assume any value just because the code flow has previously set a value to it (in the case of this register it will in fact never be written to).

Consider this example
if (FIO1PIN == FIO1PIN ) {
}
A variable without volatile type attribute will always result in the comparison being true and so the compiler can simply always execute the true case. In the case of a volatile type the compiler should never assume that the result is true since the content could well change between the two accesses to the same register!!

FIO1SET is also defined as volatile because of the fact that it can be written with bits to set outputs but reading it back makes no sense - code will probably never attempt to read it, but it is clear from the define that its content will not necessarily be the same value when read back as when it was written to.

if (FIO1SET == FIO1SET ) {
}
Although this is a very silly piece of code it would usually result in the check being unequal. Without the volatile type attribute the optimiser would almost always result in the wrong path being take!

FIO1DIR is a read/write register and there is no possibility of its content changing between accesses, so why should it be defined as volatile? Its content is purely code dependent and this is clear by looking at the header file. There is no need to consult the user manual to be sure of this fact and its definition is thus just as valid as the volatile definition for the FIO1SET, where is is also perfectly clear that the content of the register when read back is NOT necessarily the same as the value written (the exact reason for the difference in content is not the same but the baisc characteristic is nevertheless clear).

Consider when FIO1DIR were define as volatile and the following code written:

FIO1DIR = 0x0000000;
..
FIO1DIR |= 0x0000004;
..
FIO1DIR |= 0x0005010;
..

here the optimiser has no choice but to read the present value at each step and perform an OR function before writing the new value.

Without the volatile attribute the optimiser could do the following:

FIO1DIR = 0x0000000;
..
FIO1DIR = 0x0000004;
..
FIO1DIR = 0x0005014;

This results in faster and more efficient code, even if the programmer didn't specifically notice that this is in this case a more efficient (and non-dangerous) method to achieve the same results.

So my conviction is that there are some advantages of using the attribute in a selective way rather than simply declaring everything as volatile.


So how do we solve the problem with the GNU code not working correctly with the LCD demo?

The first solution has already been shown. By setting FIO1DIR with volatile attribute it is already cured. But the define doesn't inform us any more about its real characteristic and automatic compiler optimisation in other time critical code segments may be lost.

I see two methods which I will be considering for the next SP.

1.
#ifdef _GNU
    #define _VOLATILE volatile
#else
    #define _VOLATILE
#endif

#define FIO1DIR                          *(_VOLATILE unsigned long*)(FAST_GPIO_BLOCK + 0x20)
#define FIO1PIN                          *(volatile unsigned long*)(FAST_GPIO_BLOCK + 0x34)

Here it is clear that the volatile attribute assigned to the register is to ensure the GNU compiler doesn't (over)optimise but the programmer understands that the register's content is really purely code dependent. Non-GNU compilers (assuming they don't optimise - which may of course also change between compiler releases!!!) will still be free to optimise where seen to be advantageous.

2.
#define VOL_FIO1DIR                   *(volatile unsigned long*)(FAST_GPIO_BLOCK + 0x20)
#define FIO1DIR                          *(unsigned long*)(FAST_GPIO_BLOCK + 0x20)

Here there are simply 2 different register definitions and the programmer can decide when a particular access 'should really' be volatile in a critical code section (the programmer shoudl of course knwow such thing swhen programming and should be able to make the final decision...).

Does any one have any inputs to help decide which solution would be the best ??

Regards

Mark

232

NXP^TM M522XX, KINETIS and i.MX RT / M5223X Service Pack 6 available

« on: January 29, 2008, 12:15:23 AM »

Hi All

Please note that a new service pack for the M5223X is now available on the service pack page:
http://www.utasker.com/software/softwareV1.3.html

The complete release note can be found also there or directly at:
http://www.utasker.com/software/V1.3/SP_M5223X_Notes.txt

In summary, the new service pack contains the following features.
- the patch list from the SP5 thread (http://www.utasker.com/forum/index.php?topic=40.msg175#msg175) has been implemented
- NetBios support
- SPI based file system option (with support for multiple external devices)
- Hardware flow control capabilities on the UARTs
- Dynamic web content generation - with demo integrated into the project
- The project runs on the M5222X (without UART) by adding _M5222X define to the project (in addition to _M5223X) [M52223EVB and M52221DEMO boards] - also simulation support
- The project can be configured to run on the newer M5221X chips by adding _M5221X define to the project (in addition to _M5223X)  [M52211EVB and M52210DEMO boards] - also simulation support

Note that the file config_ref_m5223X_sp6.h is included in \Applications\uTaskerV1.3. This will not overwrite existing config.h files but includes the most up to date list of options and also a few defines which are required for compatibility with the latest version. In case of compiler errors when building existing projects just copy the missing defines from here to your own config.h.
This reference file can also be renamed to config.h to use it as it is [it was also used to test the SP6 release].

The GNU_Coldfire directory can be completely replaced, as can the CodeWarrior_M5223X directory. These projects have been rebuilt to include all latest files. The simulator project will also be updated automatically to include all project files. You may therefore have to add your own files to the project again if they are in the original directory.

It is important to know that the CodeWarrior project has now been configured to use parameter passing in registers (previously it was using compact passing). The new startup file Startup.s for CodeWarrior now has been changed to support this. The new Code Warrior project is configured to work like this but if libraries are used, the correct library (compiled for parameter passing in registers) must also be used!

CodeWarrior_M5223X\uTaskerV1.3\bin contains the latest version of the conversion utility for creating files for software uploading using the "Bare-Minimum" uploader support [uTaskerConvertV1.1.exe].

In the simulator VS project there is now a build configuration with a post build using the GNU compiler. If this is used it will call the bat file in GNU_ColdFire - you will probably have to set the paths there to match your own GNU compiler installation.

I hope that you find the new features useful.

Should there be questions or difficulties, please post here so that an answer can be given to benefit all users.

Good luck!!

Regards

Mark

233

NXP^TM M522XX, KINETIS and i.MX RT / Flash Clock Setting correction

« on: January 26, 2008, 09:16:56 PM »

Hi all M5223X users

Thanks to Leon Y's investigations it has been determined that the setting for the FLASH Clock (state-machine frequency) is not correct in the routine fnConfigFlash() in M5223X.c.

The calculation of the setting uses the oscillator clock where the correct clock value should be (system clock/2).
Since all M5223X projects use 25MHz clock (due to the Ethernet/PHY requirements) a system clock of (60/2MHz == 30MHz) results in a flash clock frequency slightly higher than the correct frequency range.

Before looking at the correction it may be interesting to look at why the error was made and what the implications may be.

The reason for the error is almost certainly due to the fact that the data sheet about the FLASH module is not that specific about this point. It states that the Internal Flash Bus Clock must be divided down to a frequency in the range of 150kHz and 200kHz. Possible Internal Flash Bus Clock frequencies are in the range of >150kHz to <102.4MHz. The Internal Flash Bus Clock was somehow interpreted as being the crystal frequency since example values seemed way off if the PLL output were the Internal Flash Bus Clock frequency. It has now been established that it it is the PLL output clock divided by 2 - this is specified in the data sheet in chapter 21.6 (EZPort) - "The flash controller module runs at the system clock frequency divided by 2". This detail doesn't appear in the FLASH module chapter itself, presumably the source of the misunderstanding.

It turns out that a system running at 60MHz will have a FLASH state-machine clock (FCLK) of 234'375Hz using the original code. This is 17.19% higher than the maximum specified frequency and this means that the timing when programming and deleting FLASH using IAP (in-application-programming) is also 17.19% less that specified. The good news is that there is no known case that this has caused a real problem so it seems as though there must be a bit more tolerance than specified - although it is possible that effects in slight under-programming could only be detected after ageing.
Systems which don't use the typical (maximum) system clock of 60MHz can be classified as follows:
Frequencies between 38.4MHz and 51.2MHz are in tolerance.
Frequencies less that 38.4MHz would cause over-programming which could result, in the worst case, in stress-enduced FLASH damage. [I haven't heard of anyone using the chip at such a slow system frequency - idle mode is also not an issue. However please see the note about the Boot Loader below!]

The following code corrects this and also automatically respects the optimum setting for any possible system speed as suggested by Freescale.

Code: [Select]

#if BUS_CLOCK > (12800000)                                               // divider required above this frequency (required clock is between 150kHz and 200kHz - incorrect value > 200kHz could reduce programming reliability. incorrect value < 150kHz could result in FLASH damage)
    #define FLASH_DIV   ((BUS_CLOCK/200000/8/2) - 1)
    #define FLASH_ROUND (((BUS_CLOCK + ((200000*8*2) - 1))/200000/8/2) - 1)
    #if FLASH_ROUND > FLASH_DIV
        #undef FLASH_DIV 
        #define FLASH_DIV FLASH_ROUND
    #endif
    CFMCLKD = (PRDIV8 | FLASH_DIV);                                      // set the FLASH state machine frequency as close to, but not higher than 200kHz
#else
    #define FLASH_DIV   ((BUS_CLOCK/200000/2) - 1)
    #define FLASH_ROUND (((BUS_CLOCK + ((200000*2) - 1))/200000/2) - 1)
    #if FLASH_ROUND > FLASH_DIV
        #undef FLASH_DIV 
        #define FLASH_DIV FLASH_ROUND
    #endif
    CFMCLKD = FLASH_DIV;                                                 // set the FLASH state machine frequency as close to, but not higher than 200kHz
#endif
Thsi code replaces the following in fnConfigFlash() in M5223X.c.
    // This works for oscillator clocks greater than 12.8Mhz
    CFMCLKD = (PRDIV8 | (unsigned char)((OSCCLK/200000/8)));

I recommend making this change also in M5223X_boot.c if you are using the boot loader. In this case the error is probably causing some stress on the FLASH due to overprogramming since the Boot Software doesn't set up the PLL to operate at 60MHz, instead it leaves it at the oscillator speed (25MHz) - this results in a FCLK of 97'656Hz with the original code. In this case the following 2 lines can be added before the new code above to ensure that the calculation is made with the bus equal to the oscillator value:
#undef  BUS_CLOCK
#define BUS_CLOCK  OSCCLK

I hope that this doesn't cause any inconvenience and that there are no reliability concequences found as a result.

Regards

Mark

234

NXP^TM LPC2XXX and LPC17XX / LPC2106 / LPC2103

« on: January 26, 2008, 04:46:55 PM »

Hi All

I have spend some time verifying the compatibility of the LPC23XX project for use on smaller LPC devices, specifically the LPC2104/5/6 (128k FLASH and 16k/32 or 64k RAM) and the smaller LPC2101/2/3 (8k/16k/32k FLASH and 2/4/8k RAM).

I found that there is a difference in the PLL set up and the vectored interrupt controller which needed to be adjusted. The vectored interrupt controller difference required a small change in the vectors and I made linker script files for each device due to the large memory differences.

After the work I could successfully verify the adapted project set-up on two boards - the IAR LPC210X KickStart Card (with LPC2106) and the Olimex LPC-P2103 prototyping board. By changing a single define in config.h it is thus possible to compile the uTasker demo project to run on these and also the LPC2378 based Keil MCB2000 and Olimex LPC2378-STK boards.

Of course only the LPC2378 boards use Ethernet and the TCP/IP stack and the other boards just allow control over a UART. This does however show that it is possible to run a single project with one define change on a wide range of LPC devices.

While memory use is not of great importance on the larger devices it becomes a big issue on the smaller ones - in which case the use of resources (code and data space) has to be carefully planned and monitored. The LPC2101/2/3 devices are pre-destined for projects where the larger device is probably already being used but a simple peripheral extension (like standalone keyboard or display) is required. They are cheap, small and powerful and can make use of already developed code and development environments. With this in mind, I look a closer look at the project's memory requirement when it was configured to use the serial interface demo. Here are some benchmark figures (IAR compiler, Thumb mode)

Code:
- uTasker OS - 910 bytes
- uMalloc (for heap management) - 204 bytes
- serial TTY driver - 770 bytes with only character mode and no flow control - up to 1'870 bytes with all modes and flow control enabled
- LPC2XXX initialisation, interrupt and hardware driver code - 2'200 bytes
- queue drivers - 1'650 bytes - up to 1'930 bytes depending on options

RAM:
- around 140 bytes global/static variables
- around 1'000 bytes HEAP (with 600 bytes of these allocated to the UART buffers)
- in addition, a few hundred bytes for interrupt and CPU stack are reserved

The above doesn't include the application - the actual demo application has a large menu driven interface and so is code and constant data hungry (around 7k, which will not let it run in that form on the smallest chip).

A project based on communication via UART is thus set up ready to add the specific application for a resource-price of around 5'800 bytes FLASH and 1'400 bytes RAM. In the smallest device - the LPC2101 - this leaves around 2.2k FLASH space for the application code and about 800 bytes RAM for its own use. Considering that the application has full support of the uTasker OS and the UART interface it can be written in a modular and efficient manor to achieve useful functions. If this is not enough for the particular simple application, the next device up in the chain (eg. LPC2102), with doubled memory size, will allow expansions with no additional effort.

Just contact me if you are interested in using any of the LPC210X range. Beta testers are very welcome. Don't forget that the uTasker simulator also works with all of these devices, so develoment becomes even easier!!

Regards

Mark

235

NXP^TM LPC2XXX and LPC17XX / Olimex PC2378-STK support added to Beta version

« on: January 24, 2008, 02:51:27 PM »

Hi All

Here is a quick note to say that support for the Olimex LPC2378-STK has been added to the Beta version.

The new files are available on the service pack page:
http://www.utasker.com/software/softwareV1.3.html

New hex files are available to owners of this board, which can be loaded using FLASH Magic
http://www.utasker.com/software/software.html

The uTasker LPC23XX tutorial has also been updated to reflect the new board support:
http://www.utasker.com/docs/LPC23XX/uTaskerV1.3_LPC23XX.PDF

Brief release notes are included in the service pack. Note that to set the project up to use the Olimex LPC2378-STK activate the define OLIMEX_LPC2378_STK rather than KEIL_MCB2300 in config.h

Good luck

Regards

Mark

236

ATMEL^TM AT91SAM7X and AVR32 / PHY configuration

« on: January 23, 2008, 09:57:39 PM »

Hi All

After having a small difficulty with the demo project on an Olimex board it is interesting to discuss some details about the initialisation of the PHY chip to ensure that it initialises in the correct mode and has the correct address. This has resulted in a slight change in the project configuration code which you may like to take over from the details below.

At the time of writing the uTasker project for the SAM7X is delivered with configurations for two common evaluation boards: the ATMEL AT91SAM7X-EK and the Olimex SAM7-EX256.
The main difference between the Ethernet interface of the two boards is the use of different PHYSICAL layer devices: the AT91SAM7X-EK has a DAVICON DM9161A while the Olimex board uses the MICREL KS8721.

Fortunately the control of the PHYs are compatible (and standardised) to high degree. However the interface to these devices differs in some respects - mainly in the way that the PHYs are configured by port states on reset. It is typical to configure some PHY modes and the address of the device on the maintenance interface using pull-up and pull-downs at reset. Some of these configurations can be be reprogrammed later but a couple are critical so the Ethernet controller can even communicate with the PHY.

Examples of mode inputs are RMII mode, loopback or isolation mode.
The PHYs generally have a pull-up or pull-down to determine the stating mode if no external devices does it. This is also valid for the PHY address - for example the Micrel will default to address 0x01 since 4 address lines have pull-downs and ADD0 has a pull-up.

The configuration lines are also shared with other lines and so are generally connected also to the SAM7X. The SAM7X has pull-ups on its port lines by default and this can give a conflict with the PHY, which may have pull-downs. The question as to which wins the fight to determine the port state can not be determined so, if there is not also a stronger pull-up/down on the board to determine it, the defalt state is not really known.

The solution is to perform a second reset of the PHY while the SAM7X actively drives these configuration pins. This is performed in the Ethernet driver initialisation using the SAM7X feature of being able to generate a pulse on the reset output to reset external devices (without causing a CPU reset). Once the reset has completed, the SAM7X GPIOs can be programmed for MII use and the PHY is in the required mode.

It was found that the communication address of the PHY was not always as expected. The uTasker code uses 0x1f - ADD0..ADD4 = '11111' but the Olimex board, using Micrel PHY, was found to be defaulting to 0x01. This means that a check of the PHY ID (read on initialisation) was not causing a match and the Ethernet interface was subsequently not being initialised (this is interpreted as an error and the Ethernet initialisation is aborted).

A check of project code showed that the mode lines were correctly being derived on the second initialisation, but the PHY address lines were not. Since the code has been previously verified on Olimex boards it suggests that variations in the pull-up strengths between devices means that this may vary between boards and so a correction was necessary.

The following shows the improvement to ensure that the PHY address is controlled correctly.

In app_hw_sam7x.h the driving of the configuration lines are controlled using a define. The define varies between board type, and so there are 2 defines - one for the ATMEL and one for the OLIMEX board. The board type itself is selected in config.h.

ATMEL board code change

    #define PHY_ADD_31              (PB04 | PB05 | PB06 | PB13 | PB14)
    // DAVICON DM9161AE on ATMEL eval board
    // remove pullup on TEST input (MII ERXDV) so that device goes to normal mode
    // remove pullup on RMII input (MII ECOL) so that device uses MII mode
    // drive power down mode to '0'
    // drive PHY address to 0x1f (31)
    #define DRIVE_PHY_OPTION_LINES() PIO_PUDR_B = (PB15 | PB16); PIO_PER_B = (PB18 | PHY_ADD_31); PIO_OER_B = (PB18 | PHY_ADD_31); PIO_CODR_B = PB18; \
                                     PIO_SODR_B = (PHY_ADD_31);

The 5 connections from PB04, PB05, PB06, PB13 and PB14 drive the DAVICON pins (CRS, RXD0, RXD1, RXD2, RXD3) to '1' during the commanded reset. These lines latch in the PHY address on reset. Afterwards all pins are switched to their MII function.

OLIMEX board change

    #define PHY_ADD_31              (PB05 | PB06 | PB13 | PB14)          

    // set the option lines as we would like them to be for the MICREL PHY
    // drive to zero (default after reset)
    // drive PHY address configuration lines to correct address value
    #define DRIVE_PHY_OPTION_LINES() PIO_PER_B = (PCS_LPBK | ISOLATION_MODE | RMII_MODE | RMII_BACKTOBACK_MODE | PHY_ADD_31); \
PIO_OER_B = (PCS_LPBK | ISOLATION_MODE | RMII_MODE | RMII_BACKTOBACK_MODE | PHY_ADD_31); \
PIO_SODR_B = (PHY_ADD_31);

The 4 connections from PB05, PB06, PB13 and PB15 drive the MICREL pins (RXD0, RXD1, RXD2, RXD3) to '1' during the commanded reset. These lines latch in the PHY address on reset. Afterwards all pins are switched to their MII function.
The 5th address line (ADD0) is connected to the IRQ line of the PHY and defaults both at the SAM7X and MICREL to pull-up. Therefore this line doesn't need to be specifically driven. Afterwards it remains as input to detect interrupts originating from the PHY.

The modification for the Olimex board solved the problem. No known problems exist with the ATMEL board, but the change was successfully tested and should ensure that no problems are encountered in the future.

Regards

Mark

237

NXP^TM LPC2XXX and LPC17XX / LPC23XX Beta release now available

« on: January 20, 2008, 01:17:10 AM »

Hi All

Here’s a quick note to inform you of the availability of a new uTasker package for the LPC23XX (including LPC2101..LPC2106 sub-set support).

This release will initially have the status of pre-release Beta. That means that it is not under versions control as a release version and so no history notes are being maintained as further parts get integrated (eg. there is no I2C driver integrated in this release).

It is available for immediate use by anyone interested in these NXP devices. It includes the unique uTasker simulator for the LPC23XX and projects for IAR, Rowley Crossworks GNU and also a standalone GNU build which is suitable for the Yagarto package using Eclipse.

A new tutorial is ready at http://www.utasker.com/docs/LPC23XX/uTaskerV1.3_LPC23XX.PDF

Beta testers are very welcome. Just fill out the new application form on the uTasker web site (mention which package you are already using if you are already registered) http://www.utasker.com/Licensing/request.html and I will get it to you.

These ARM7 chips are very exciting so take a look if you don’t know them already.

Best regards

Mark

238

µTasker general / Ethereal and Wireshark

« on: January 18, 2008, 11:22:24 PM »

Hi All

For an interesting review of the reasons for the change of project name from Ethereal to Wireshark (billed as the world's most popular network protocol analyzer) see the following!!

http://www.linux.com/feature/54968

Regards

Mark

239

ATMEL^TM AT91SAM7X and AVR32 / SAM7X SP3 is now available

« on: January 16, 2008, 01:14:36 AM »

Hi All

Don't get the impression that the SAM7X SP2 has so many problems that SP3 was necessary after only a few days...
But since new dynamic web content generation support is now ready for use it was the easiest package to add it to so that it can get in to circulation (and tested) as quickly as possible.

The SP3 is now available on the V1.3 SW page: http://www.utasker.com/software/softwareV1.3.html

The includes a new demo and a short tutorial on the new support will appear in the near future.

Here are the new release notes (a couple of important details are marked bold)

Regards

Mark




SP3. 15.01.2008
===============

This small service pack adds new dynamic content generation support and corrects a potential problem with global timer operation

WinSim
------
WinSim.c -
   08.01.2008 Ethernet code made conditional on Ethernet availability    {13}

Ethereal.cpp -
   08.01.2008 Content made conditional on Ethernet availability

WinSimMain.cpp -
   08.01.2008 Ethernet code made conditional on Ethernet availability    {10}

WinPcap.cpp -
   08.01.2008 Made content conditional on Ethernet interface availablility

WinPcap.cpp -


uTasker
-------
GlobalTimer.c -
   03.01.2008 Correct deleted software timer firing early                {3}

stack
-----
The HTTP interface has been improved to allow TCP buffer growth when inserting additional strings. This results in imporved frame efficiency and is also required for the new dynamic generation support.

http.c -
   06.01.2008 Pass end of buffer space to fnWebParGenerator                           {13}
   06.01.2008 Pass buffer space end to fnInsertHTMLString()                           {14}
   07.01.2008 Simulator flag iFetchingInternalMemory reset on completion (no longer in driver) {15}
   08.01.2008 Rework dynamic insertion parameter solution                             {16}
   09.01.2008 Allow frame length increase when inserting strings                      {17}
   11.01.2008 Improvement when generated frames can not grow more                     {18}
   12.01.2008 Additional management information to aid dynamic generation             {19}
   12.01.2008 Optionally pass HTTP session information to fnInsertValue()             {20}
   12.01.2008 Apply INSERT_SHORT_STRINGS support always (define removed)

webutils.c -
   06.01.2008 Add defines for user information pointers                  {4}
   06.01.2008 Add tx buffer end to fnInsertHTMLString() and allow buffer growth {5}
   06.01.2008 Correct a buffer end check                                 {6}
   12.01.2008 Apply INSERT_SHORT_STRINGS support always (define removed)

tcpip.h -
   06.01.2008 Add tx buffer end to fnInsertHTMLString()                  {9}
   11.01.2008 Extend HTTP struct to include user data pointer and dynamic count array {10}
   12.01.2008 Optionally pass HTTP session information to fnInsertValue() {11}

hardware
--------
SAM7XSim.c -
   15.01.2008 Correct WDT_MR initialisation value                        {13}

SAM7X.c -
   06.01.2008 Add DISABLE_WATCHDOG() macro                               {23}
   07.01.2008 Don't reset simulator flag iFetchingInternalMemory (caller does it) {24}

\Applications\uTaskerV1.3
-------------------------
webInterface.c -
   08.01.2008 Add dynamic insertion demo                                 {5}
   12.01.2008 Adjust fnInsertValue() to accept sesssion information      {6}

app_hw_sam7x.h -
   06.01.2008 Add DISABLE_WATCHDOG() macro                               {6}


\Applications\uTaskerV1.3\WebPages\WebPagesSAM7X\AlternativePages
-----------------------------------------------------------------

E_multiplication_table.htm - new alternative web page for testing dynamic web content generation



Note that the definition for the location of user name and passord used by the web server and ftp server has been added to webutils.c.
This needs to be added to config.h - see the example config-sam7x-reference.h

#define POINTER_USER_NAME parameters->cUserName                          // define where the user name and password is taken from
#define POINTER_USER_PASS parameters->cUserPass

To test the new dynamic web content generation copy the HTML file E_multiplication_table.htm from \Applications\uTaskerV1.3\WebPages\WebPagesSAM7X\AlternativePages to the target or simulator via FTP (this overwrites the statistic page).
When the statistic page is then visited it will instead show the new demo. Its use is self-explanatory!!

240

µTasker general / Dynamic web content generation

« on: January 14, 2008, 06:48:15 PM »

Hi All

Here is a note to say that some additional support for generation of dynamic web content (eg. HTML and Java script) is being added to the HTTP interface.

There is a new demo of this on-line at http://demo.uTasker.com which includes this. Take a look at the statistic page which has been replaced by a side which can generate a muliplication table with user defined number of rows and columns. The interface allows multiple users to generate tables of various sizes at the same time.

This is not a PHP (or similar) server built into the uTasker project but it does allow user code to generate such things without having to get involved with the details of HTTP or TCP. The user code simply has a reference to a 'chunk' of content to be generated. This starts at number 1 and continues counting until the user decides that there is no more work to do. The user code doesn't need to know details about how much space is available in the present TCP frame being constructed or whether it is a repeat due to a previous TCP timeout.

The user code can be inserted into fnInsertString() and the code used to generate the on-line multiplication table is below as reference. This support is being further tested and will certainly be included in future service pack releases:

Code: [Select]

        if (ptrBuffer == 0) {                                            // special case when session is terminating. This is used to clear any session specific data and onl yoccurs when there is a valid user data pointer
            uMemset(http_session->ptrUserData, 0, sizeof(MULTIPLICATION_TABLE));  // clear content
            return 0;
        }
        if (*ptrBuffer == '0') {
            MULTIPLICATION_TABLE *ptrMulTable;
            unsigned short usChunk = (usTxLength - 1);
            unsigned short usX, usY;

            if (http_session->ptrUserData == 0) {
                http_session->ucDymamicFlags = NO_DYNAMIC_CONTENT_TO_ADD;// inform that we don't want to generate anything this time
                *usLengthToSend = 0;
                return cValue;                                           // user session unknown so don't generate anything. This occurs when the window is first opened
            }
            ptrMulTable = (MULTIPLICATION_TABLE *)http_session->ptrUserData;

            if (usTxLength > (ptrMulTable->ucColumns * ptrMulTable->usRows)) {
                if (ptrMulTable->ucColumns == 0) {                       // no valid input data
                    http_session->ucDymamicFlags = NO_DYNAMIC_CONTENT_TO_ADD;// inform that we don't want to generate anything this time
                    *usLengthToSend = 0;
                    return cValue;                   
                }
                return 0;                                                // complete table content generated
            }

            usX = (usChunk%ptrMulTable->ucColumns);
            usY = ((usChunk/ptrMulTable->ucColumns) + 1);
            if (usX == 0) {
                if (usY == 1) {
                    cPtr = (uStrcpy(cValue, "<tr style=""background-color:white""><th width=""60"">") - 1); // start a new table row
                }
                else {
                    cPtr = (uStrcpy(cValue, "<tr><th style=""background-color:white"" width=""60"">") - 1); // start a new table row
                }
            }
            else {
                cPtr = (uStrcpy(cValue, "<th width=""60"">") - 1);       // start a new column
                usY *= (usX + 1);                                        // the multiplication result
            }
            cPtr = fnDebugDec(usY, (WITH_TERMINATOR), cPtr);             // insert the result

            if (usX == ptrMulTable->ucColumns) {                         // end of this row
                cPtr = uStrcpy(cPtr, "</tr></th>");                      // close table row
            }
            else {
                cPtr = uStrcpy(cPtr, "</th>");                           // close a single column
            }
            *usLengthToSend = (cPtr - cValue - 1);                       // length of code to insert
        }
The example adds a single table element on each execution (its definition of 'chunk' to be added) but could also generate a complete line instead.

I hope that you agree that this allows for a flexible interface to user code to perform a variety of similar tasks.


Regards

Mark