There is more than one way to skin a cat and there is getting to be a
very large number of ways to design systems that need signal
processing along with standard control processing. One of the MCU-
like devices that are good at this is the Blackfin from ADI.

I had not paid a lot of attention to it in the past, but earlier this
year I attended a seminar on it and realized that it is a pretty nice
little chip in many ways. I tried joining the Blackfin Yahoo group
only to find that it was overrun by spam (sound familiar?). So I
started another one and have taken steps to preclude it from going the
same route.

http://tech.groups.yahoo.com/group/BlackFinDSP-MCU /

If you have and interest in the Blackfin processor, you can discuss
your issues and ask questions there. Being highly targeted, it should
provide lots of good info.

I've been doing the designs with Blackfin since 2003 and still do, and I
can tell you that Blackfin is same as crap as all other MCUs and CPUs. A
tremendous list of the incredible bugs in the silicon, completely
idiotic and unusable memory protection, poor set of peripherals, weak
external bus shared between SRAM and other peripherals.

Yes, several things are good about it, however don't get over excited.

"Hallo freinds I am Babbadushman. I want 2 ask U a Q about 2+2=4. What
does this mean? I need this urgent and immediately."

] Speaking of BlackFin, it was initially seen as the CPU for the
]cellphones. When it became apparent that they missed the market,
]Intel pulled out the plug, leaving ADI with the unripe project.
]ADI put the things together as they could, and released the
]obviously incomplete processor. Sadly enough, the original
]concept was appealing. Now ADI is pathetic in pushing
] BlackFin in all directions, including those where BlackFin
] doesn't fit (like the consumer video, for example).

So it's got low power consumption ?
How would it be for a 2..4 AA-cell driven Ebook ?
Or is the CPU power consumption irrelevant compared
to a 80 * 20 char display ?

I don't recall for sure if uCliniux is ported, but I want to say yes.
The power consumption is not especially low. The units I considered
were about the same as one of the high end ARM CPUs, both in
performance and power. They may have come out with some versions that
are better on static power.

Although Blackfin consumes somewhat less power then the other DSPs, I
wouldn't call it the low power processor.

The very minimum power consumption of Blackfin is at the order of 80mA
at 3.3V. This is if the core is running at 24MHz and idling most of the
time. At full speed, BlackFin burns about a couple of watts.

Kinda working. As good as the illustration of the possibility.
If you want BlackFin to run with the speed of AVR, use ucLinux.
uClinux is linux without MMU, which is nonsense indeed.

One of my Blackfin projects (based on a '533) uses less power than
that:

http://www.afibalert.com /

I am not at liberty to divulge the actual numbers, but it appears that
one's
mileage varies on power consumption.

Hmmm, I have delivered a couple of solutions using uClinux for the
Blackfin.
I am not sure if it's ready for prime-time (i.e. ready to
power something you could sell at Best Buy), but it is definitely
good enough to deliver single-digit prototypes to customers or perhaps
if you are making some sort of test equipment that is for the lab and
not for consumer use. So I guess I agree with you there.

Hahaha! Quite a bit of an exaggeration, but the point is correct.
gcc for the Blackfin is about 40% slower than ccblkfin (the ADI
compiler), and linux adds some overhead that isn't there if you
use your own OS (like I usually do).

I am not involved in the usual linux or OS religious wars, so
I don't know if linux w/o an MMU is nonsense. I mean, is VDK
without an MMU(*) retarded? Is any pre-rolled OS running on a chip
without an MMU silly?

The reason I used uClinux was that the client wanted TCP/IP running
over gigabit ethernet from their blackfin, and they needed it
pronto. My analysis (given the time and $$ involved) was that the
only way to achieve all the goals was to port the existing gigabit
linux driver to uClinux for the Blackfin, and it worked great. All
I had to do was to get the ethernet chip working, and from there
TCP/IP was a done deal.

Plus since I had to follow the GPL, you all can benefit from my work
on the gigabit driver (it's rolled into the base distribution now).
Since then, ADI has taken it over and increased the performance
of the driver since I last touched it. Sure wish they had been
interested in the driver before I spent all those late nights
in kernel panic :-)

--Keith

(*) BTW the Blackfin does have an MMU, just not one that gives the
granularity needed for a port of the real linux kernel.

I was planning the BF-537 for the low power project, and I measured the
actual power consumption that can be attained. There could be some +/-
difference, however the ballpark is going to be as I cited.

By design, linux was meant for the 386 protected mode. A lot of the
functionality of the linux core relies on the MMU. Linux without MMU is
the perversion of the base concepts.

VDK is retarded regardless.

The dynamic memory management without MMU is unsafe and involves many
tradeoffs. The memory protection is the other highly desirable feature
of MMU. Blackfin has a rudimentary MMU which doesn't provide neither
address translation nor a sensible mechanism for the memory protection.
The exception handling of BlackFin is simply a nightmare: there is no
sense in the way it is implemented, and there are the ugly bugs in the
silicon in the addition to that.

We developed the proprietary RTOS for Blackfin, including the posix
compliant FAT32 file system and TCP/IP stack over the BlackFin native
MAC. At minimum, it can run from the bare 537-class chip using only the
internal memories.

I could never understand the joys of the GPL.

Obviously they wanted to make the real MMU (look at all of those empty
registers), however it didn't happen.

It starts from the belief that the 'one laptop per child'
hyped-idea from MIT can't handle the lack of mains electricity
in 3rd world locations.

So the 2 to 4 rechargable AA's need to give about 8 hours
reading. I didn't yet find out about display power consumption,
and a 'hi-volume used for other devices' display would be used.
Of course if the display's consumption is significant then the
CPU is less relevant. I guess a 8-bit CPU would do, except for
the lack of ability to leaverage existing software, eg. uclinux.

Here's some ideas of required capabilities for the student/reader:
* hyper link to random sections,
* bookmark where I was last time,
* bookmark the stuff/s that I want to show Joe & Jill..
* cutNpaste ..........
* search: where-else/if XYZ was mentioned........
* embed(?sp) [simple] sketches in the text...posibly animated
* ... etc. ..your ideas/requirements...

So, I realise that the half second delay of low-power Epaper
is a problem for eg. cutNpaste.

I'm thinking of a 5 or 10 finger-capacitive-pad input
mouse-like/pointer.