John/David
..thanks for your help ...
Well...
My first conclusion :
V2 x V4 core and Linux x uCLinux issues are totally dependent, rigth?
1- Considering my company have reasonable experienced designers in control
embedded applications flows / state machines / hardwares accesses, low_level
drivers code, etc ( I don“t use OS ...yet...) . we would feel very
confortable / confident enougth to handle uCLinux, taking its advantages due
to small overheads e getting closer to hardware control..and that full Linux
would not give us more usefull resources than uCLinux .considering our
application is an ethernet based PLC (no video, .MP3,etc...).
Rigth or wrong?
2- If I not use DDR memory, only SD_DRAM or ordinary SRAM, the V2 flex bus
is pretty enough to it.
Rigth or wrong?
3- In practical ways, what is the advantages of Linux over uCLinux?What
could I do with linux I could not with uCLinus?or how much more effort shoud
I do in one then the other?
4- Could someone explain me why / whnen should I use SDR / DDR / DDR2 /
Mobile etc..devices?It makes a difference
when chosing between V2 x V4, rigth?
5- uCLinux was made because the MMU lack, or due to a necessity of a lower
level management / hardware constraints considerations ? I mean..uCLinux is
a kind of trick for not mmu enable mcus?
6- A V2 requirements, like pcb cares, powers, etc...is much(?) more simpler
than a (full use) V4?
Ricardo Raupp
----- Original Message -----
From: "John Bodnar" <
john.bodnar@...>
To: "Ricardo" <
ricardo@...>
Sent: Thursday, May 01, 2008 3:12 PM
Subject: Re: [ColdFire] Linux x uClinux for ColdFires: what is the best for
what?
> David Brown wrote:
>> With higher frequency and higher performance devices, you have to take
>> more care with your memories and buses, and you have more worries about
>> your power supplies and decoupling. You often need more voltage levels
>> (the v4 has 1.5V for the core, 1.8/2.5V for the memory buses, and 3.3V
>> for IO - the 5234 with which I am most familiar has 1.5V core and
>> everything else at 3.3V). It is typically easier on slower devices to
>> attach other peripherals to the external buses without glue logic, level
>> converters, etc.
>
> Well, therein lies the rub. As soon as you start supporting DDR of any
> kind, you get away from being able to produce a device with only two
> voltage rails. The MCF523x family only supports SDR, so it never had a
> reason to support other than just I/O and VDD supplies.
>
> The MCF5445x still maintains a 3.3V general-purpose memory bus (FlexBus)
> for connecting up everything else but your SDRAM. In the future, I'm
> looking to move the FlexBus to its own dedicated supply rail in order to
> support flashes and FPGAs/CPLDs with 1.8V I/Os as a means of reducing I/O
> power. This would up the number of supply rails to four (core, SDRAM,
> FlexBus, and digital I/O), but you could still run the FlexBus at 3.3V, if
> desired.
>
>> I haven't used any v4 cores, so my rough comments are only based on my
>> reading of datasheets and application notes. But our move from the
>> older, slower MC68832 to the MCF5234 required a bit step in board
>> complexity and quality - I would plan for another step up, though perhaps
>> not as large, in doing a v4 board.
>
> I think we've made the MCF5445x family quite friendly for board design,
> especially on the 256-ball MAPBGA variants. We're trying to take the
> lessons we've learned from doing the package and substrate design for
> those devices and apply them to new higher end parts going forward.
>
>> I you want to tell me that I'm wrong, and that the MCF5445x is as easy to
>> use as the MCF5234 (baring the lack of a TPU), then go ahead - I'll
>> listen! I like the ColdFire architecture, and if the v4 will give me a
>> lot more processing power for little more complexity, then it's
>> definitely good to know.
>
> I think I mentioned it before, but I am hardly an expert on board design,
> so I could be wrong on all counts :-( That said, I had plenty of help
> from some real experts on the MCF5445x, so I think we've made that family
> one of our better examples of how to pin out and package a device. Of
> course, by saying as much, I'm now setting myself up for pot shots from
> the peanut gallery, so let the shooting commence :-)
>
> John Bodnar
> Systems Engineer
> Microcontroller Solutions Group
> Freescale Semiconductor, Inc.
>
> --
> POPI Classification
> [ ]General Business Information
> [x]Freescale Internal Use [ ]Freescale Confidential Proprietary
>
> ---
>
coldfire@... Send a post to the list.
>
coldfire-join@... Join the list.
>
coldfire-digest@... Join the list in digest mode.
>
coldfire-leave@... Leave the list.
>
>
>
> __________ NOD32 3067 (20080430) Information __________
>
> This message was checked by NOD32 antivirus system.
>
http://www.eset.com>
>
---
coldfire@... Send a post to the list.
coldfire-join@... Join the list.
coldfire-digest@... Join the list in digest mode.
coldfire-leave@... Leave the list.