Microcontroller selection

Matthew Hicks wrote:
> Actually, whatever isn't used for the FPGA's bitstream can be used to 
> store anything else and is acessable to the FPGA logic at runtime.
> 

I'm not familiar with the details (I'm an Altera fan), but you are still 
likely to be far from the required flash size for Linux (unless you are 
seriously underusing your fpga).

mvh.,

David


> 
> ---Matthew Hicks
> 
>> Matthew Hicks wrote:
>>
>>> Wrong.  Many vendors make FPGAs with built-in flash, for instance
>>> refer to the Xilinx Spartan 3AN.
>>>
>> That's flash for the configuration of the device, not flash memory for
>> storing program code.  You can store initial values for ram blocks in
>> the flash, but it's of a size appropriate for a small bootloader
>> rather than a full application or os (especially if he is planning on
>> using Linux).
>>
>> mvh.,
>>
>> David
>>
>>> ---Matthew Hicks
>>>
>>>>> Im looking for a controller which has the following I/O (and
>>>>> nothing else)
>>>>>
>>>>> USB 2.0
>>>>> 100Mpps Ethernet
>>>>> A lot of (40) configurable GPIO pins
>>>>> A powerful processing core (> 40 Mhz) which can support
>>>>> RTOS/embedded
>>>>> Linux.
>>>>> 128K -  512K - 1 MB NOR Flash
>>>>> 16 K - 32- 64K RAM
>>>>> and no other I/O device (except possibly the  venerable old RS-232
>>>>> serial interface)
>>>>> Searching for oneis tedious. Looking first if there is ready
>>>>> reckoner by anyone..?
>>>>>
>>>> An Atmel AVR32 (AP7000) will do what you want
>>>> if you accept external flash and the USB 2.0 is a device and not a
>>>> host.
>>>>> Is an FPGA more suitable in case there is no microcontroller with
>>>>> such tailored requirements..?
>>>>>
>>>> You will not find an FPGA with built in flash.
>>>>
>>>>> Kind Regards,
>>>>> Ravishankar
> 
> 

David Brown <david@westcontrol.removethisbit.com> writes:

> Matthew Hicks wrote:
> > Actually, whatever isn't used for the FPGA's bitstream can be used
> > to store anything else and is acessable to the FPGA logic at runtime.
> >
> 
> I'm not familiar with the details (I'm an Altera fan), but you are
> still likely to be far from the required flash size for Linux (unless
> you are seriously underusing your fpga).

The Altera MAX-II has flash available to the FPGA core logic. However,
it's not very large and getting Linux (or even NIOS) to run on the
MAX-II would be somewhat difficult. But I guess we'll see more FPGA's
with combined configuration and user flash in the future.

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Ravishankar S wrote:
> Hello group,
> 
> Im looking for a controller which has the following I/O (and nothing else)
> 
> USB 2.0
> 100Mpps Ethernet
> A lot of (40) configurable GPIO pins
> A powerful processing core (> 40 Mhz) which can support RTOS/embedded Linux.
> 128K -  512K - 1 MB NOR Flash
> 16 K - 32- 64K RAM
> 
> and no other I/O device (except possibly the  venerable old RS-232 serial
> interface)
> 
> Searching for oneis tedious. Looking first if there is ready reckoner by
> anyone..?
> 
> Is an FPGA more suitable in case there is no microcontroller with such
> tailored requirements..?
> 
> Kind Regards,
> Ravishankar
> 
> 
> 
> 
> 
> 
> 
> 
> 

Tedious it may be be, but it is a required learning challenge for the 
designer. If you don't want tedious on occasion, you chose the wrong 
line of work ;)

That said, there's nothing wrong with asking for suggestions, but 
ultimately you will have to choose; and unless you have been through the 
tedium of locating and choosing a processor/controller you will be ill 
equipped for the task.

Cheers

PeteS

I agree it's small (at most 11Mb), but the post I responded to said FPGAs 
didn't offer this.  I just wanted to correct the error in case someone who 
had a less memory intensive project read it and ruled out using FPGAs.


---Matthew Hicks


> Matthew Hicks wrote:
> 
>> Actually, whatever isn't used for the FPGA's bitstream can be used to
>> store anything else and is acessable to the FPGA logic at runtime.
>> 
> I'm not familiar with the details (I'm an Altera fan), but you are
> still likely to be far from the required flash size for Linux (unless
> you are seriously underusing your fpga).
> 
> mvh.,
> 
> David
> 
>> ---Matthew Hicks
>> 
>>> Matthew Hicks wrote:
>>> 
>>>> Wrong.  Many vendors make FPGAs with built-in flash, for instance
>>>> refer to the Xilinx Spartan 3AN.
>>>> 
>>> That's flash for the configuration of the device, not flash memory
>>> for storing program code.  You can store initial values for ram
>>> blocks in the flash, but it's of a size appropriate for a small
>>> bootloader rather than a full application or os (especially if he is
>>> planning on using Linux).
>>> 
>>> mvh.,
>>> 
>>> David
>>> 
>>>> ---Matthew Hicks
>>>> 
>>>>>> Im looking for a controller which has the following I/O (and
>>>>>> nothing else)
>>>>>> 
>>>>>> USB 2.0
>>>>>> 100Mpps Ethernet
>>>>>> A lot of (40) configurable GPIO pins
>>>>>> A powerful processing core (> 40 Mhz) which can support
>>>>>> RTOS/embedded
>>>>>> Linux.
>>>>>> 128K -  512K - 1 MB NOR Flash
>>>>>> 16 K - 32- 64K RAM
>>>>>> and no other I/O device (except possibly the  venerable old
>>>>>> RS-232
>>>>>> serial interface)
>>>>>> Searching for oneis tedious. Looking first if there is ready
>>>>>> reckoner by anyone..?
>>>>> An Atmel AVR32 (AP7000) will do what you want
>>>>> if you accept external flash and the USB 2.0 is a device and not a
>>>>> host.
>>>>>> Is an FPGA more suitable in case there is no microcontroller with
>>>>>> such tailored requirements..?
>>>>>> 
>>>>> You will not find an FPGA with built in flash.
>>>>> 
>>>>>> Kind Regards,
>>>>>> Ravishankar

"Ravishankar S" <ravishankar.s@in.bosch.com> skrev i meddelandet 
news:f5qt8b$vca$1@news4.fe.internet.bosch.com...
> thanks guys, for the hints!
>
> the reason for internal flash is: makes the board smaller and simpler (no
> memory interfacing) and reduced pin count
> the reason for linux is: low cost, drivers for ethernet and USB built in 
> and
> already present know-how (in writing drivers)
>
> i have not looked into AP7000 yet. but point not to forget in controller
> selection is: tool support. how are the tools support for AVR32 ?
>

There is a free gcc toolchains supported by Atmel.
Eclipse based AVR32 Studio IDO
Debugging through same JTAGICE Mk II as used with the AVR.
Dev kit (linux capable) for less than $100 has 32 MB of SDRAM and 16 MB of 
Flash.

> -> build tools:  i suppose GNU must have been already ported../ Atmel has
> AVRStudio ..integration..?
> -> debug tools -> Any low cost wigglers available..(gdb support?)
> -> OS: linux support/ does atmel provide any drivers/RTOS
>
> Intended application:
> The application is simple debug device which provides a better performance
> and ease of use than Wiggler.  I suppose a microcontroller with built in
> support for configurable I/O should help here.
>
> Kind Regards,
> Ravishankar
>



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

Ravishankar S wrote:
> thanks guys, for the hints!
> 
> the reason for internal flash is: makes the board smaller and simpler (no
> memory interfacing) and reduced pin count
> the reason for linux is: low cost, drivers for ethernet and USB built in and
> already present know-how (in writing drivers)

Sounds more like [tick box laziness] to me.

You need to decide how much resource your task needs (without the OS)
and then find some Eval boards, and actually try them.

If you want to skip USB/Ethernet code, (that's ok) then find Eval kits 
with that portion already working in their examples - what you really 
want is not linux, but working peripheral libraries.


> 
> i have not looked into AP7000 yet. but point not to forget in controller
> selection is: tool support. how are the tools support for AVR32 ?
> 
> -> build tools:  i suppose GNU must have been already ported../ Atmel has
> AVRStudio ..integration..?
> -> debug tools -> Any low cost wigglers available..(gdb support?)
> -> OS: linux support/ does atmel provide any drivers/RTOS
> 
> Intended application:
> The application is simple debug device which provides a better performance
> and ease of use than Wiggler.  

and you think you need Linux ?!

> I suppose a microcontroller with built in
> support for configurable I/O should help here.

This for example, would be a good starting point :

http://www.st.com/stonline/stappl/cms/press/news/year2007/p2176.htm

(Just $49.)

-jg

>>
>> i have not looked into AP7000 yet. but point not to forget in controller
>> selection is: tool support. how are the tools support for AVR32 ?
>>
>> -> build tools:  i suppose GNU must have been already ported../ Atmel has
>> AVRStudio ..integration..?
>> -> debug tools -> Any low cost wigglers available..(gdb support?)
>> -> OS: linux support/ does atmel provide any drivers/RTOS
>>
>> Intended application:
>> The application is simple debug device which provides a better 
>> performance
>> and ease of use than Wiggler.
>
> and you think you need Linux ?!
>

If you have Linux running, then you could conceivably run OpenOCD in the 
box.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

thanks group, once again for the hints:

that narrows down my search, since there are a huge number of
microcontrollers out there.

linux: now it seems overkill for the application. that's now for sure..

AP7000 is not suitable: it has way too many peripherals..and its intended
for multimedia low-power apps, but AVR32UC - microcontrollers seems to be a
perfect fit. Im yet to look at the ST micro.

The configurable I/O pins are important since it will deal with JTAG pins.

Also, i think the trend is towards a single chip solution: look at SoC's. it
may be good from learning point to interface external devices, but for
prototying its better to have everything on chip. It is also good from EMI
perspective (Automotive).


Kind Regards,
Ravishankar

"PeteS" <axkz70@dsl.pipex.com> wrote in message
news:jfKdnZV6BI6IwBzbnZ2dnUVZ8vmdnZ2d@pipex.net...
> Ravishankar S wrote:
> > Hello group,
> >
> > Im looking for a controller which has the following I/O (and nothing
else)
> >
> > USB 2.0
> > 100Mpps Ethernet
> > A lot of (40) configurable GPIO pins
> > A powerful processing core (> 40 Mhz) which can support RTOS/embedded
Linux.
> > 128K -  512K - 1 MB NOR Flash
> > 16 K - 32- 64K RAM
> >
> > and no other I/O device (except possibly the  venerable old RS-232
serial
> > interface)
> >
> > Searching for oneis tedious. Looking first if there is ready reckoner by
> > anyone..?
> >
> > Is an FPGA more suitable in case there is no microcontroller with such
> > tailored requirements..?
> >
> > Kind Regards,
> > Ravishankar
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> Tedious it may be be, but it is a required learning challenge for the
> designer. If you don't want tedious on occasion, you chose the wrong
> line of work ;)
>
> That said, there's nothing wrong with asking for suggestions, but
> ultimately you will have to choose; and unless you have been through the
> tedium of locating and choosing a processor/controller you will be ill
> equipped for the task.
>
> Cheers
>
> PeteS

"Ravishankar S" <ravishankar.s@in.bosch.com> skrev i meddelandet 
news:f5tibc$9fb$1@news4.fe.internet.bosch.com...
> thanks group, once again for the hints:
>
> that narrows down my search, since there are a huge number of
> microcontrollers out there.
>
> linux: now it seems overkill for the application. that's now for sure..
>
> AP7000 is not suitable: it has way too many peripherals..and its intended
> for multimedia low-power apps, but AVR32UC - microcontrollers seems to be 
> a
> perfect fit. Im yet to look at the ST micro.

If you want high speed USB (480 Mbps), your selection is limited.
If you accept Full Speed USB (12 Mbps), then your next
selection criteria should be high speed DMA driven synchronous
serial peripherals.

The Atmel synch serial port peripherals generally run as fast as the CPU 
core.

> The configurable I/O pins are important since it will deal with JTAG pins.
>
> Also, i think the trend is towards a single chip solution: look at SoC's. 
> it
> may be good from learning point to interface external devices, but for
> prototying its better to have everything on chip. It is also good from EMI
> perspective (Automotive).
>
>
> Kind Regards,
> Ravishankar



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

> AP7000 is not suitable: it has way too many peripherals..and its intended
> for multimedia low-power apps, but AVR32UC - microcontrollers seems to be 
> a
> perfect fit. Im yet to look at the ST micro.

Note that the AP7000 series has high-speed (480 mbps) USB, whereas the UC3 
series has only full-speed (12 mbps) USB.

Leo Havm�ller.