| Author |
Message |
|
|
Posted: May 04, 2007 - 03:32 PM |
|

Joined: Apr 12, 2006
Posts: 115
|
|
Hi,
Many thanks to squidgit and sma for valuable data about Ethernet on the AVR32. I was looking into how to set up an Ethernet port, and found my way to the NGW100 schematics. Ethernet requires a lot of 'glue logic'. However, I saw that the AP7000 supports USB high-speed, which does not require a lot of glue. Unfortunately, the AP7000 looks like a Lovecraft-style giant octopus monster next to the ATMegas I'm used to dealing with.. which for this comparison would be fluffy bunnies or something.
I'm trying to weigh the benefits of building a daughter card for the NGW100 versus implementing the AT32AP7000 on my own board. I'm trying to make an acoustic array as part of my thesis. The role of the AT32AP7000 in this case would be to read from a series of hardware FIFO queues as fast as possible, perhaps do a little bit of bit-shuffling if time permits, and shove the data off to a PC. In my design, each microphone data stream (buffered by the FIFO) would be read through a single GPIO pin.
I see that the NGW100 opens up something on the order of 60 GPIO pins, which is plenty. Data would need to be read from each pin at 800Kbps. 800Kbps seems possible for the AP7000, but it would be nice to have that confirmed (or maybe someone knows the upper limit?). I'd also like to wipe the OS that it ships with and implement the functionality I want with a program written straight to the processr, just like your typical ATMega. I would hope this would make the functionality more reliable and deterministic. Is the possible/wise/necessary?
The other option is to try to place the AP7000 on my own board. This seems like it will take a lot of time and require a learning curve I'd rather avoid for the time being. Is there any advantage to "handrolling" in this manner?
Thanks again! |
|
|
| |
|
|
|
|
|
Posted: May 04, 2007 - 03:39 PM |
|


Joined: Jan 07, 2003
Posts: 4580
Location: Oslo, Norway
|
|
If you do not have the tools or skills to do 4-layer (or more) PCBs, go for a ready kit
I think sampling at 0.8 MHz should not be a problem for the pins, but I do not know the number of inputs you need. |
|
|
| |
|
|
|
|
|
Posted: May 04, 2007 - 04:08 PM |
|


Joined: Feb 25, 2003
Posts: 194
Location: Trondheim / Norway
|
|
Handling of BGAs isn't easy. Go for a AP7001 instead. Remember it is an in-order out-of-order pipeline and cache and other features target towards throughput. But there are means to take to make it more deterministic (and slower). It probably makes more sense to run processors like the AVR32 AP family with an OS than without. But you can use it without and OS as well, sure  |
_________________ 11011110101011011100000011011110
|
| |
|
|
|
|
|
Posted: May 04, 2007 - 06:43 PM |
|


Joined: Apr 26, 2006
Posts: 1079
Location: Trondheim, Norway
|
|
| You can make your application more deterministic by locking parts of it in the cache. If you do that, 800kbps should be achieveable. USB communication is mostly offloaded onto a DMA controller, so there shouldn't be too much time wasted on copying data around. Or I suppose you can put your sampled data directly into the USB FIFO and just hit Go when it's full. |
|
|
| |
|
|
|
|
|
Posted: May 04, 2007 - 06:48 PM |
|


Joined: Apr 26, 2006
Posts: 1079
Location: Trondheim, Norway
|
|
| Come to think about it, 800kbps should work fine even without locking things in the cache -- it's not _that_ fast. But you may experience some jitter if you don't. |
|
|
| |
|
|
|
|
|
Posted: May 05, 2007 - 08:20 AM |
|


Joined: Sep 14, 2003
Posts: 4228
Location: Queanbeyan, Australia
|
|
|
ubarch wrote:
Data would need to be read from each pin at 800Kbps. 800Kbps seems possible for the AP7000, but it would be nice to have that confirmed (or maybe someone knows the upper limit?). I'd also like to wipe the OS that it ships with and implement the functionality I want with a program written straight to the processr, just like your typical ATMega. I would hope this would make the functionality more reliable and deterministic. Is the possible/wise/necessary?
Probably a good idea. I haven't had time to investigate exactly why, but
Code:
gpio_set_value(GPIO_PIN_FOO, GPIO_HIGH);
gpio_set_value(GPIO_PIN_FOO, GPIO_LOW);
gpio_set_value(GPIO_PIN_FOO, GPIO_HIGH);
gpio_set_value(GPIO_PIN_FOO, GPIO_LOW);
in a Linux kernel module produces a square wave of just 300kHz at mclk 140MHz on an AP7000 IIRC.
Running a nice simple RTOS (freeRTOS etc) is probably advisable just from an ease-of-getting-things-done PoV. Then again, depending on your level of experience with ATMEGA parts, you might find it easier/ more productive to treat the AP7000 like a big one of those and be done with it.
If you're keen to design your own board, do look in to the UC3 family as well, they have all the interfaces you'd need and are much easier to route (100-pin TQFP vs 256-pin BGA ) but they do run slower. As previously mentioned the AP7001 is not BGA either, simplifying routing, but it makes up for it by being physically huge .
-S. |
|
|
| |
|
|
|
|
|
Posted: May 07, 2007 - 12:22 AM |
|

Joined: Apr 12, 2006
Posts: 115
|
|
|
Quote:
If you're keen to design your own board, do look in to the UC3 family as well
Agreed. I filled out the form for some samples, but no word from Atmel yet.
Quote:
As previously mentioned the AP7001 is not BGA either
Not BGA, but also not sold by DigiKey. I can't find it through findchips.com, either. Where do you get them?
As for laying out my own board, I'm competent with Eagle CAD and their Martian user interface, but I'm beginning to convince myself that a $70 dev board with all the comm peripherals pulled out of an AP7000 just can't be beat when you factor in the cost of time in layout and fabrication. I jsut need to make sure that the GPIO pins that are pulled out aren't routed in such a way that they can't handle 800Kbps.
Also, I'm looking at the FreeRTOS website, and seeing that they list a port for the UC3 processors, but not the AP700X processors. What would be involved in getting FreeRTOS working on the NGW100 board? Would I have to re-code all the drivers that Atmel provides?
Thanks! |
|
|
| |
|
|
|
|
|
Posted: May 07, 2007 - 08:13 AM |
|


Joined: Sep 14, 2003
Posts: 4228
Location: Queanbeyan, Australia
|
|
|
ubarch wrote:
Not BGA, but also not sold by DigiKey. I can't find it through findchips.com, either. Where do you get them?
xD you don't, not through regular people at least. Samples only AFAIK, maybe not even that. Perils of being at the cutting edge, eh? Also try requesting samples through your local Atmel distributor rather from Atmel direct, I've found that the locals tend to be a bit of a softer touch
ubarch wrote:
I jsut need to make sure that the GPIO pins that are pulled out aren't routed in such a way that they can't handle 800Kbps.
I think you'd have to be trying pretty hard to manage to route signals across a 10cm board such that they couldn't take 800Kbps . 'specially when there's support at the headers for high speed peripherals such as SPI (to 20MHz), ISI, etc.
ubarch wrote:
Also, I'm looking at the FreeRTOS website, and seeing that they list a port for the UC3 processors, but not the AP700X processors. What would be involved in getting FreeRTOS working on the NGW100 board? Would I have to re-code all the drivers that Atmel provides?
There's an unofficial (but fully functioning and supported) port of FreeRTOS to the AP7000 family available here: http://sourceforge.net/projects/ap7x-freertos/
Last I heard ngw support was "coming soon", though I don't imagine it would take heaps of effort to cut-and-paste the stk1000 stuff, change the SDRAM size and bus width and enable some slightly different peripherals if it hasn't already been done.
-S. |
|
|
| |
|
|
|
|
|
Posted: Jun 20, 2007 - 08:40 AM |
|

Joined: Apr 11, 2007
Posts: 11
|
|
For that kind of data manipulation, a FPGA would be an easier bet : you would use it to multiplex all your data streams into a single data stream that you'd then send ...
- through ethernet or USB
- or through high speed synchronous serial interface to a uC board |
|
|
| |
|
|
|
|
|