Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Philips LPC ARM7 Devices & USB

Posted by Nobody/Anonymous on October 10, 2005
Hi,

I'm looking at the Atmel, Philips & STMicro ARM7 devices with USB interfaces.

I note that the current FreeRTOS supports the USB interface on the Atmel AT91SAM7 family, but not on either the Philips or STMicro device families.

I was wondering whether anyone had done any work in this area, or whether there were technical reasons why it hasn't yet been done. e.g. I've come across a few problems with USB on the Philips LPC2148, specifically when using the ULINK JTAG port on the Keil MCB2140 board.

I'm happy to contribute a USB port on either (or both) of these devices but don't want to "re-invent" the wheel if someone is already addressing this.

Any advice would be appreciated.

Regards,

David Henretty

RE: Philips LPC ARM7 Devices & USB

Posted by Richard on October 10, 2005
I'm not aware of anybody currently providing USB samples with FreeRTOS for these other devices, but there is absolutely no technical reason why it cannot be done.

FreeRTOS provides sample drivers, normally for a UART, the structure of which can be copied for any peripheral. You can simply use the sample interrupt driven UART driver as a frame work, then put in your own USB code. I'm sure sample USB code will be available for the LPC and STR devices somewhere. Try the Yahoo groups for LPC code.

Regards.

RE: Philips LPC ARM7 Devices & USB

Posted by Nobody/Anonymous on October 11, 2005
Thanks for the prompt response Richard - much appreciated.

Sample USB code for HID, Bulk and Isochronous endpoints is provided with the Keil board (or on the Keil website). However, these are standalone examples - the issue is porting the USB control code (driver) to FreeRTOS, as has already been done on the Atmel device. I'll take a look at the UART driver as you suggest and see what is involved in porting the sample code to work under FreeRTOS.

There appear to be specific issues with the Philips device in that all the provided examples work fine until I attempt to load them using the ULINK JTAG interface. This usually fails or ends up in "hyperspace" after single-stepping a few instructions. I'm not sure what the cause is; it may be related to interrupts or a hardware interaction between the USB and JTAG interfaces. I had no such problems with the Atmel board and IAR tools.

I don't yet have an STMicro kit, so can't comment on it.

Regards,

David.

RE: Philips LPC ARM7 Devices & USB

Posted by Richard on October 11, 2005
In theory it should be a matter of:

+ Creating an ISR that simply services the USB interrupt by receiving data from the hardware, posting the data to a queue, then clearing the interrupt. The ISR should therefore be small and fast.

+ Creating a task that receives data from the queue, processes it, and if necessary generates data in response.

The structure and syntax for the ISR can be obtained from the UART example (for example, how to define the ISR, how to send data to a queue from the ISR, how to cause a context switch from within the ISR if necessary, etc.) which is compiler dependent.

Hopefully the code required to service the hardware will be obtained from the Keil example. This will go into the ISR.

Again, hopefully the code required to parse the descriptors, generate data in response, etc. will also be obtained from the Keil example. This part of the code can go in a task.

See the SAM7 USB example also for more information.

Regards.

RE: Philips LPC ARM7 Devices & USB

Posted by Jeff Smith on October 13, 2005
Richard, you mentioned the ISR (which should be quick) would read data available from the USB hardware, then send to a queue.

I wonder how this relates to a recent statement that the FreeRTOS queue is more complex than needed for simply queuing bytes from a serial port because it adds event-tracking overhead. Does that apply here, that it would be better to use a simple revolving buffer to pass the bytes from the interrupt?

RE: Philips LPC ARM7 Devices & USB

Posted by Richard on October 14, 2005
What using the queue gives you is a way of guaranteeing that the received bytes would be processed immediately should the ISR end by Yielding (forcing a context switch).

A task can block on a queue waiting for data to arrive. If the ISR posts onto the queue then the task will unblock. If at that point it is the highest task in the system able to run, then it will run on the next context switch, which by following the UART examples can be within the ISR.

This gives you a sort of second level interrupt (conceptually). The main processing happens at task level so you don't have to worry about having interrupts disabled or alternatively nesting interrupts, but the ISR and data processing happen sequentially, and the interrupted task does not execute again until the data processing is complete.

Placing data into a simple circular buffer does not automatically wake a task that might be waiting for the data. This means the task might not process the data immediately upon at the end of the ISR. It is therefore really application dependent as to which is best for you. You can have a faster interrupt, or an automatic way of prioritising processing. If you do not need to immediately process received characters then the simple buffer might be better for you.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists