"Jan Bruns" <testzugang_janbruns@arcor.de> writes:
> What's the difference between uClinux and win32?

uClinux is an operating system derived from Linux.

Win32 is not an operating system or product.  It is a set of APIs
provided by multiple operating systems from Microsoft, and in some
cases by alternative products such as Wine and Wind/U.

Jan Bruns wrote:
> "Eric Smith":
>> "guestuser1" <guestuser1@nowhere.net> writes:
>>> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
>>> why would you even try to run a full Linux (MMU) kernel on it?
>> Sometimes you need the MMU more than you need the performance.  Otherwise
>> we'd all be running uCLinux on our x86 boxes.
> 
> What's the difference between uClinux and win32?
> 

The main differences between uCLinux and full Linux are that full Linux 
implements fork (uCLinux has just vfork, or fork+exec), it properly 
separates the memory space and resources of the kernel and each user 
process from each other, it supports virtual memory, and it has much 
more flexible and efficient dynamic memory allocation.

Mind you, when you look at Win32 (especially earlier versions, but still 
relevant for later windows versions), you don't have a proper fork, user 
processes and the kernel are not properly separated from each other, and 
the virtual memory handling is terrible.

So I see your point - there is not much difference between uCLinux and 
Win32....

"Eric Smith":
> "guestuser1" <guestuser1@nowhere.net> writes:
>> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
>> why would you even try to run a full Linux (MMU) kernel on it?
> 
> Sometimes you need the MMU more than you need the performance.  Otherwise
> we'd all be running uCLinux on our x86 boxes.

What's the difference between uClinux and win32?

Gruss

Jan Bruns

David Brown <david@westcontrol.removethisbit.com> writes:
>
> The analogue blocks are more exciting - there are not many alternative
> ways to get that sort of flexibility.  I think if you view the PSoC
> devices as configurable analogue input/output devices, in which the
> digital blocks and the cpu are simply there to enhance the analogue
> blocks, then it becomes a more interesting device.

The analogue blocks are pretty good, if a bit slow. The whole thing eats
power like 74S was back in fashion, in our experience :-)

Also, the smallest package sizes are massively under-resourced in terms
of blocks available. 2-4 times as many and it would be a really useful
item...


-- 
rich walker         |  Shadow Robot Company | rw@shadowrobot.com
technical director     251 Liverpool Road   | skype: rich_at_shadow
need a Hand?           London  N1 1LX       | +44 20 7700 2487
http://www.shadowrobot.com/hand/

Andreas Ehliar wrote:
> ["Followup-To:" header set to comp.arch.fpga.]
> On 2008-11-10, David Brown <david@westcontrol.removethisbit.com> wrote:
>> I'd like to see something like that too.  The only one I can think of is 
>> Atmel's FPSLIC's, which are an FPGA with an AVR core.  But they don't 
>> really do the same thing - the AVR core is like an add-on hard-core in a 
>> small FPGA.  I'd prefer something that had the convenience and easy of 
>> use of a normal AVR device (or similar small micro), but with some 
>> programmable logic built-in to off-load the processor for fast I/O or 
>> calculation acceleration.  A hundred or so CPLD macrocells would be 
>> enough for many situations.
> 
> You might be interested in PSoC. I don't know much about this but from
> the marketing material I've read it might have roughly the functionality
> you want (even though it doesn't really have an embedded CPLD or FPGA).
> 
> /Andreas

(Please don't set followup-to headers unless you really have a good 
reason for it - this thread is equally at home in both c.a.f. and c.a.e.)

The PSoC is certainly an interesting architecture.  I haven't used them, 
so I am basing my opinion on reading datasheets and application notes 
rather than experience - I hope I'll be corrected if I'm wrong here.

The PSoCs digital blocks are very limited - they are basically glorified 
8-bit timer/counters with internal connections to other blocks (the AVR 
XMega have this too).  There are also *far* too few digital blocks - 4 
8-bit timer/counters is not much, especially as a 16-bit timer takes two 
blocks, as does a full-duplex uart channel (with no extra buffering).  I 
am also not too impressed by the cpu core.

The analogue blocks are more exciting - there are not many alternative 
ways to get that sort of flexibility.  I think if you view the PSoC 
devices as configurable analogue input/output devices, in which the 
digital blocks and the cpu are simply there to enhance the analogue 
blocks, then it becomes a more interesting device.

["Followup-To:" header set to comp.arch.fpga.]
On 2008-11-10, David Brown <david@westcontrol.removethisbit.com> wrote:
> I'd like to see something like that too.  The only one I can think of is 
> Atmel's FPSLIC's, which are an FPGA with an AVR core.  But they don't 
> really do the same thing - the AVR core is like an add-on hard-core in a 
> small FPGA.  I'd prefer something that had the convenience and easy of 
> use of a normal AVR device (or similar small micro), but with some 
> programmable logic built-in to off-load the processor for fast I/O or 
> calculation acceleration.  A hundred or so CPLD macrocells would be 
> enough for many situations.

You might be interested in PSoC. I don't know much about this but from
the marketing material I've read it might have roughly the functionality
you want (even though it doesn't really have an embedded CPLD or FPGA).

/Andreas

cs_posting@hotmail.com wrote:
> On Nov 10, 12:55 am, "H. Peter Anvin" <h...@zytor.com> wrote:
> 
>> It would still be nice to have more chips with combination
>> microcontroller and small FPGA at the low end, as that is often a useful
>> mix as opposed to having to have a much bigger FPGA.  Aiming this at the
>> high-end CPLD markets (with features such as onboard flash, 5V
>> tolerance, etc.) would be especially nice.
> 
> My feeling is that when talking about low cost FPGA's, it's not the
> logic fabric required to implement a decent microcontroller-class soft
> core that's the problem, it's the ram to store the program that is
> mostly missing and thus pushes you either into a larger FPGA than
> logic demands require, or into using an external memory.
> 
> And flash cells would be nice too, but if doing that might as well
> include storage for the FPGA bit file too.  Otherwise you can just
> append the program code in a serial config flash and load that into
> ram to execute from.  Or you could if the ram problem were solved...

Of course you want to have storage for the FPGA bit file.  Additionally,
I think you'd really want single voltage, as is pretty much the norm in
flash microcontrollers.

That's the problem with going to "full" FPGAs like Spartan or Cyclone:
the power supply and storage requires some reasonable degree of
technical sophistication in the design, whereas most CPLDs and flash
microcontrollers can be wired up by a complete board design newbie like
myself and expect it to work.

	-hpa

"guestuser1" <guestuser1@nowhere.net> writes:
> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
> why would you even try to run a full Linux (MMU) kernel on it?

Sometimes you need the MMU more than you need the performance.  Otherwise
we'd all be running uCLinux on our x86 boxes.

> It may be academically interesting, but a far more practical setup
> would use a Virtex4/FX (PowerPC-405) or a
> Virtex5/FXT (PowerPC-440) 

More practical for what?

For some applications cost is more of a concern than maximum CPU performance.
The Virtex 4 or Virtex 5 are somewhat expensive; for some applications that's
OK and for others it isn't.

On Nov 10, 12:55 am, "H. Peter Anvin" <h...@zytor.com> wrote:

> It would still be nice to have more chips with combination
> microcontroller and small FPGA at the low end, as that is often a useful
> mix as opposed to having to have a much bigger FPGA.  Aiming this at the
> high-end CPLD markets (with features such as onboard flash, 5V
> tolerance, etc.) would be especially nice.

My feeling is that when talking about low cost FPGA's, it's not the
logic fabric required to implement a decent microcontroller-class soft
core that's the problem, it's the ram to store the program that is
mostly missing and thus pushes you either into a larger FPGA than
logic demands require, or into using an external memory.

And flash cells would be nice too, but if doing that might as well
include storage for the FPGA bit file too.  Otherwise you can just
append the program code in a serial config flash and load that into
ram to execute from.  Or you could if the ram problem were solved...

H. Peter Anvin wrote:
> David Brown wrote:
>> My understanding of Altera's FPGAs is that they have pretty much given
>> up on using ARM hard-core processors, because the Nios / Nios II was
>> actually faster for real use - the flexibility of memory bus
>> arrangements, custom instructions, etc., meant that the space taken by
>> the ARM core was simply not worth it.
> 
> It would still be nice to have more chips with combination
> microcontroller and small FPGA at the low end, as that is often a useful
> mix as opposed to having to have a much bigger FPGA.  Aiming this at the
> high-end CPLD markets (with features such as onboard flash, 5V
> tolerance, etc.) would be especially nice.
> 
> 	-hpa

I'd like to see something like that too.  The only one I can think of is 
Atmel's FPSLIC's, which are an FPGA with an AVR core.  But they don't 
really do the same thing - the AVR core is like an add-on hard-core in a 
small FPGA.  I'd prefer something that had the convenience and easy of 
use of a normal AVR device (or similar small micro), but with some 
programmable logic built-in to off-load the processor for fast I/O or 
calculation acceleration.  A hundred or so CPLD macrocells would be 
enough for many situations.