I have a project requiring me to pipe about 14 MBits/sec from a sensor onto a network via UDP to one IP address. The data requires no processing and is steady. I know the Atmel AT91SAM7X handles up to about a 50MHz clock, but I am fairly new to it. My question is, can the at91sam handle this? Or do I need more horsepower?
If you can get the data from the sensor using one of the DMA channels may be it is possibile. You would DMA the data into a buffer then DMA the data through the EMAC. The CPU would not have to copy data around.
gdisirio, thanks for your reply. I think one of the Synchronous Serial Interfacess supports DMA Does this mean I have to dump it into the DMA as a UDP frame and the E MAC takes care of the rest?
All the serial channels (SPI, SSP, USART) support the DMA if I remember well.
You could DMA the data into a preformatted ethernet frame then start the transfer with the EMAC. this should minimize the CPU load. The EMAC can transmit the whole frame without any help from the CPU and generate an interrupt when it is done.
Probably you will have to manage multiple buffers (preformatted frames) in order to not stop the input data from the sensor while the previous frame is outgoing.
I think it is an interesting problem.
I am new to networking on a 32-bit ARM, but I have done socket programing in *nix land and I have lots of Atmega 8-bit experience. I guess the ethernet frame generation is not handled by the MAC, but by the code on the ARM? Do I have to generate a CRC and manage all the bit fields and ethernet addresses too? For some reason I thought the MAC handles this.You could DMA the data into a preformatted ethernet frame then start the transfer with the EMAC.
The EMAC is able to generate the CRC itself and append it to the frame. The procedure is described in section 37.3.2 of the data sheet.
On the ATMEL web site there is an application note about the EMAC with included source code. Try here: http://www.atmel.com/dyn/resources/prod … _2-2_0.zip
Hi
UDP frames have also check sums over the IP and UDP data which needs to be calculated by the CPU (UDP is also allowed to work without checksum by setting the field to zero (no problem if data is in a LAN since the Ethernet check sum is much stronger).
See the following for more details about SAM7X Ethernetthroughput:
http://www.utasker.com/forum/index.php?topic=20.0
Also see the following benchmark for various UDP configurations (for a Coldfire at 40MHz but using same SW and can be considered more or less equivalent):
http://www.utasker.com/docs/uTasker/uTa … hmarks.PDF
Regards
Mark
Thanks for the pointers mark,
It looks like this may possible after all because:
I don’t need to worry about receiving any data like ack’s
I don’t need to worry about checksums since the EMAC does this in hardware at the ethernet layer
The EMAC is able to generate the CRC itself and append it to the frame. The procedure is described in section 37.3.2 of the data sheet.
On the ATMEL web site there is an application note about the EMAC with included source code. Try here: http://www.atmel.com/dyn/resources/prod … _2-2_0.zip
Isn’t this code for the AT91RM, not the AT91SAM7X
If you look at the register names you can see they have the same name, function and offset.
The EMAC should be the same or very similar on both chips, you should still be able to use the code as reference.
regards,
Giovanni
gdisirio
The code you posted a link to has a huge problem when used on the sam7x. From the sam7x datasheets:
37.4.1.3 Transmit Buffer List
Transmit data is read from areas of data (the buffers) in system memory These buffers are listed
in another data structure that also resides in main memory. This data structure (Transmit Buffer
Queue) is a sequence of descriptor entries (as defined in Table 37-2 on page 562) that points to
this data structure.
To create this list of buffers:
- Allocate a number (n) of buffers of between 1 and 2047 bytes of data to be transmitted
in system memory. Up to 128 buffers per frame are allowed.
- Allocate an area 2n words for the transmit buffer descriptor entry in system memory
and create N entries in this list. Mark all entries in this list as owned by EMAC, i.e. bit 31
of word 1 set to 0.
- If fewer than 1024 buffers are defined, the last descriptor must be marked with the wrap
bit – bit 30 in word 1 set to 1.
- Write address of transmit buffer descriptor entry to EMAC register transmit_buffer
queue pointer.
- The transmit circuits can then be enabled by writing to the network control register.
It gets worse:
37.4.1.6 Transmitting Frames
To set up a frame for transmission:
Enable transmit in the network control register.
Allocate an area of system memory for transmit data. This does not have to be contigu-
ous, varying byte lengths can be used as long as they conclude on byte borders.
Set-up the transmit buffer list.
Set the network control register to enable transmission and enable interrupts.
Write data for transmission into these buffers.
Write the address to transmit buffer descriptor queue pointer.
Write control and length to word one of the transmit buffer descriptor entry.
Write to the transmit start bit in the network control register.
This is far different from the a91rm code, and would be a huge pain to write and test. Atmel has no app note or code on the at91sam7x emac. Yes I know that code comes with the various rtos’s out there, but the emac drivers seem to be intertwined too much with the OS.
I am going to write an EMAC driver for my FOSS project so I am planning to look into those differences soon, it may take some time to complete and test however. I wish to create a web server demo on the SAM7X using ChibiOS/RT and the uIP stack.
You may just wait it is done and use it as a whole or use it as a code sample.
Giovanni
I appreciate your input gdisirio. Atmel should have an app note on doing this. It looks kinda time consuming.
Also, thanks for offering up your code. I will definitely be interested in looking at what you come up with. It might be that de-embeding the freertos from the emac driver is more time efficient than writing one from specs, but still not by much.
If FreeRTOS has a demo with an EMAC driver it could be a good idea to study it. De-embed it from FreeRTOS should not be harder than de-embed it from ChibiOS/RT 