uTasker V1.4 AVR32 project

[mark]

Hi All

This is an quick announcement concerning the release of a uTasker package for the AVR32 - see the following:

http://www.utasker.com/avr32.html

For present users of the SAM7X, the ATMEL AVR32 is an interesting companion / alternative. It is a new processor architecture, first released in 2006 and features a low power operation of 1.3mW per MHz with impressive performance and interesting peripherals. Many of the peripherals incorporated are compatible with the ones in the SAM7X or are upgraded versions of the same. It is for this reason that the AVR32 forum and the SAM7X are combined - the similarities in many cases are so great.

However there are also some differences, especially the CPU core which is not an ARM type but a 32 bit processor derived from the 8-bit AVR. There will certainly be a lot to discuss too - for the moment I will just say that I did enjoy porting the uTasker project to the AT32UC3A0512 and working with the tools on the ATMEL EVK1105 evaluation board.

Do give this chip a try, I expect that you will have fun too!

Regards

Mark

P.S. The first AVR32 package is a uTasker1.4 package. Also the SAM7X V1.4 project has been prepared (synchronised) to the V1.4 version and links to registered SAM7X users will be sent out a little later!

[JuKu]

Hi Mark,

Thank you and congratulations for a really impressive package! Any plans to support the EVK1100? (Or should I just go and buy another board? ) I tried the package on EVK1100 as is, and it mostly worked. A LED blinked and serial port was talking to me. However, the network interface didn't work. I didn't (yet) try to modify the package for the LCD, but based on how well the system works otherwise, I don't think that would be that big an issue.

[mark]

Hi

The AVR32 package has only been tested on the EVK1105.

Taking a quick look at the EVK1100 Ethernet diagram I see that the same PHY is used in RMII mode but there is a small difference. The IRQ line is connected to PA26 on the EVK1105 and to PA24 on the EVK1100.

Changing
     #define PHY_INTERRUPT           PA26
in app_hw_avr32.h to PA24 may fix it.

When working with RMII interface it is important that the EMAC and PHY are both configured for the correct speed (10M or 100M) even when auto-negotiating. The interrupt is used to synchronise the EMAC each time the PHY notifies that it has changed. If this is not done it will tend to only work in either 10M or 100M mode - if you can actually connect to a 10M network you may find that it then does work, even without the patch above...

There may of course be other issues which I didn't see but I expect that the boards are so close that it will not be a big job to tune it up to match. Make sure that you disable the CGLCD demo on the EVK1100 since it obviously doesn't have this device connected.

Regards

Mark

[JuKu]

Hi Mark,

Thank you! Changing the pin got the network up and running! Now, I don't need to go and buy another board.  The rest of the differences look small enough that I can deal with them (number and location of buttons, different display and so on). Another issue solved.

[mark]

Hi

Thanks for the feedback. I will add the EVK1100 to the configuration with this interrupt line dependency.
Maybe you will be testing the 4 x 20 LCD? If you manage a setup for this (in app_hw_avr32.h - see page 6 of http://www.utasker.com/docs/uTasker/uTaskerLCD.PDF for some guidelines) I could then add it to the package too ;-)

Regards

Mark

[JuKu]

Hi Mark,

If I just enable the LCD support on config.h, and do a clean and rebuild, the LCD works on the simulator. However, the LCD on EVK1100 is onSPI bus, so it is not very compatible with the current simulator; i didn't even bother trying, I'm sure it wouldn't work.

Is it possible to use the simulator on higher level? In this case we are talking about LCD, but you can take the question in general. Can the peripherals and functions be simulated on an API interface level. For example, use two different versions of "LCD_WriteCharacter(...)" (or whatever the "API" call is), one for simulator and another target? The motivation for this would be that the in my experience, the low level functions are relatively easy to build on target, the real issues are on the application logic and functionality, where the simulator helps enormously. Also, this would make it much easier to adapt the simulator to different hardware. In this case, I could take the LCD interface routines directly out of the Atmel provided stuff and not bother you with the details of an exotic LCD module.

Also, where are the API calls documented?

Cheers,

Juha

[mark]

Hi Juha

There are two APIs used to simulate all LCD types:

extern "C" void CollectCommand(bool bRS, unsigned long ulByte);
extern "C" unsigned long ReadDisplay(bool bRS);

These are used to pass commands and data (depending on the bRS state - which is the command/data input which all have). The ReadDisplay() is used to read its present status or memory content, again depending on the bRS state.

The interface is not hardware dependent and can be used with a parallel interface or an SPI interface; the driver code must simply call the interface routines with the correct data and state (the ones just sent by the driver code to the physical display).

What I don't know is whether the simulator is compatible (or fully compatible) with the LCD on your board; I have never used an SPI based character LCD. As long as it has the standard HD44780 instruction set (which is probably) it would be a case of placing the SPI equivalent routines in _fnWriteDisplay() and fnReadDisplay() in LCD.c and the rest should be compatible.

Regards

Mark

[mark]

Hi All

The following is the patch list for V1.4. Check whether these are solved in the version that you downloaded, else correct when needed:

1) Random number generator error can be corrected as pointed out by Dave here: http://www.utasker.com/forum/index.php?topic=702.msg3049#msg3049

Regards

Mark

[mark]

Hi All

The uTasker V1.4 AVR32 Release-2 is now available. Use the original link and password to download it.

In case access to previous versions is required, they are still available by adding -X to the name, where X is the release number as follows
-0 Original release on 29.7.2009
-1 11.10.2009:

Here is the change list, whereby the most important is the fact that the AT32UC3B types are now supported, tested on the EVK1101 and also simulated in the uTasker simulator:
- uTaskerCombine V1.1 in \Tools allows Intel Hex file output beyond 64k size
- Add AT32UC3B support (EVK1101), including serial loader (including simulation support)
- correction in HTTP dynamic content demonstration
- centralise packing control and little-/big-endian macros to driver.h
- Add permanent ARP entry type
- USE_PARAMETER_AREA support (as simple alternative to USE_PARAMETER_BLOCK)
- Improve simulation support for embedded user files in file system
- Allow DHCP overload options to be tolerated, but not handled
- Optionally close FTP connection on password failure [_CLOSE_ERROR]
- Allow other file types than HTML to be parsed by HTTP server if desired
- Add LCD backlight simulation control
- Add keypad LEDs simulation support
Note: when using AT32UC3B instead of AT32UC3A ensure that _AT32UC3B is enabled and that the corresponding linker script files are used.

Report any difficulties here - good luck!

Regards

Mark


PATCH LIST:
1) If the simulator project fails due to a missing define ID_TEST_R4, delete the file \uTaskerV1.4_AVR32\Applications\uTaskerV1.4\Simulator\resource.h. This forces VS to use the central header in \uTaskerV1.4_AVR32\WinSim , where it is defined.