uC selection

[John Devereux]

Don't forget the sliding mode A/D architecture which completely
eliminates INL, finished products are pricey, and they're not the
fastest in the world...

Some guy "robert" wrote an explanation here:

<http://groups.google.com/group/sci...._frm/thread/d3c04fe57286bfd4/a8e80eb0c2aefd6a>

I wonder what happened to him...

 

[MooseFET]

Right, that fixes the mean, but the narrow bins still have three times the
variance of the wide ones. You can fix the mean, but not the variance (at
least not without making additional assumptions about the data, e.g. that the
real resolution of the histogram is fairly far from 1 LSB).

Yes it is still noisy but given enough data, you still get the curve.
It turns out for the OP's case this isn't an issue. I the case I
needed to deal with many years back, gathering more data was an option
if needed to get the noise level down.

 

[MooseFET]

I believe Phil is talking about counting statistics. A "thin" channel
will appear noisy compared to the others, because it receives less
events.

Yes it does appear I missed his exact meaning.

 

[MooseFET]

On Mar 15, 7:28 pm, Phil Hobbs
[.....]

Making a 4096-bin histogram with the typical '12-bit' uC ADC could lead
to some very amusing displays. IIRC, they usually have truly crappy DNL
specs, and that will screw up the histogram bin widths completely. DNL
of +- 0.5 LSB means that your bin widths can vary by 3:1, and most of
the uC ADCs I've seen have been worse than that. (Though I'm out of
date on that point, admittedly.) Since the number of counts is
generally proportional to the bin width, that makes for some really
misleading histograms.
I assume you're not doing anything that silly, so how do you avoid the
problem?

Methods I've used or seen used:

(1)
Intermix the measurement cycles with calibration cycles so that you
know where the bin edges really are. This requires more electronics
to do and you have to be careful that the calibration doesn't bring
its own artifacts.

(2)
Pay for a 16 bit converter and use 12 bits. This gets the error a lot
smaller at quite a large price increase.

(3)
Use a ramp based converter so that nearby bins are nearly equal.
These methods are slow.

(4)
Add a dither in the analong side and subtract it back out on the
digital side. This turns fixed errors into blurry edges.

Don't forget the sliding mode A/D architecture which completely
eliminates INL, finished products are pricey, and they're not the
fastest in the world...

I'd include such methods as part of the ramp method. You can more
hardware to increase the speed but at a huge cost. A 12 bit flash
converter can be made with very good linearity but you'd need 4096
comparitors to do it in one step.

A two step version of the flash method, can be made but I think there
is not way to not get the nonlinearity issue back in.

 

[Fred Bloggs]

Methods I've used or seen used:

(1)
Intermix the measurement cycles with calibration cycles so that you
know where the bin edges really are. This requires more electronics
to do and you have to be careful that the calibration doesn't bring
its own artifacts.

(2)
Pay for a 16 bit converter and use 12 bits. This gets the error a lot
smaller at quite a large price increase.

(3)
Use a ramp based converter so that nearby bins are nearly equal.
These methods are slow.

(4)
Add a dither in the analong side and subtract it back out on the
digital side. This turns fixed errors into blurry edges.

Don't forget the sliding mode A/D architecture which completely
eliminates INL, finished products are pricey, and they're not the
fastest in the world...

 

[Phil Hobbs]

To plot the histogram, you divide the count in each channel by its
width to equalize them and then plot the value at the true center of
that bin.

Right, that fixes the mean, but the narrow bins still have three times the
variance of the wide ones. You can fix the mean, but not the variance (at
least not without making additional assumptions about the data, e.g. that the
real resolution of the histogram is fairly far from 1 LSB).

Cheers,

Phil Hobbs

 

[John Devereux]

On Mar 15, 7:28 pm, Phil Hobbs
[.....]

Making a 4096-bin histogram with the typical '12-bit' uC ADC could lead
to some very amusing displays. IIRC, they usually have truly crappy DNL
specs, and that will screw up the histogram bin widths completely. DNL
of +- 0.5 LSB means that your bin widths can vary by 3:1, and most of
the uC ADCs I've seen have been worse than that. (Though I'm out of
date on that point, admittedly.) Since the number of counts is
generally proportional to the bin width, that makes for some really
misleading histograms.

I assume you're not doing anything that silly, so how do you avoid the
problem?

Methods I've used or seen used:

(1)
Intermix the measurement cycles with calibration cycles so that you
know where the bin edges really are. This requires more electronics
to do and you have to be careful that the calibration doesn't bring
its own artifacts.

(2)
Pay for a 16 bit converter and use 12 bits. This gets the error a lot
smaller at quite a large price increase.

(3)
Use a ramp based converter so that nearby bins are nearly equal.
These methods are slow.

(4)
Add a dither in the analong side and subtract it back out on the
digital side. This turns fixed errors into blurry edges.

Phil Hobbs

Don't forget the sliding mode A/D architecture which completely
eliminates INL, finished products are pricey, and they're not the
fastest in the world...

I'd include such methods as part of the ramp method. You can more
hardware to increase the speed but at a huge cost. A 12 bit flash
converter can be made with very good linearity but you'd need 4096
comparitors to do it in one step.

Even then I would have thought there would still be a lot of
non-linearity for this application (histograms). Say you wanted the
histogram to be smooth to 12 bits, doesn't that mean you need the
comparator thresholds accurate to 24 bits?

A two step version of the flash method, can be made but I think there
is not way to not get the nonlinearity issue back in.

I think the sigma-delta ADCs are quite good for this, but I have not
looked at the details.

This one seems to be the king - I have had a sample for a couple of
years now and not got round to trying it:

<http://www.analog.com/en/prod/0,,AD7760,00.html>

If I am reading the datasheet right, the DNL is less than 1 LSB. So at
24 bits maybe it could do the job.

 

[Phil Hobbs]

MooseFET wrote:
On Mar 15, 7:28 pm, Phil Hobbs
[.....]
Making a 4096-bin histogram with the typical '12-bit' uC ADC could lead
to some very amusing displays. IIRC, they usually have truly crappy DNL
specs, and that will screw up the histogram bin widths completely. DNL
of +- 0.5 LSB means that your bin widths can vary by 3:1, and most of
the uC ADCs I've seen have been worse than that. (Though I'm out of
date on that point, admittedly.) Since the number of counts is
generally proportional to the bin width, that makes for some really
misleading histograms.
I assume you're not doing anything that silly, so how do you avoid the
problem?
Methods I've used or seen used:
(1)
Intermix the measurement cycles with calibration cycles so that you
know where the bin edges really are. This requires more electronics
to do and you have to be careful that the calibration doesn't bring
its own artifacts.
(2)
Pay for a 16 bit converter and use 12 bits. This gets the error a lot
smaller at quite a large price increase.
(3)
Use a ramp based converter so that nearby bins are nearly equal.
These methods are slow.
(4)
Add a dither in the analong side and subtract it back out on the
digital side. This turns fixed errors into blurry edges.
Cheers,
Phil Hobbs
Don't forget the sliding mode A/D architecture which completely
eliminates INL, finished products are pricey, and they're not the
fastest in the world...

I'd include such methods as part of the ramp method. You can more
hardware to increase the speed but at a huge cost. A 12 bit flash
converter can be made with very good linearity but you'd need 4096
comparitors to do it in one step.

Even then I would have thought there would still be a lot of
non-linearity for this application (histograms). Say you wanted the
histogram to be smooth to 12 bits, doesn't that mean you need the
comparator thresholds accurate to 24 bits?

A two step version of the flash method, can be made but I think there
is not way to not get the nonlinearity issue back in.

I think the sigma-delta ADCs are quite good for this, but I have not
looked at the details.

This one seems to be the king - I have had a sample for a couple of
years now and not got round to trying it:

<http://www.analog.com/en/prod/0,,AD7760,00.html>

If I am reading the datasheet right, the DNL is less than 1 LSB. So at
24 bits maybe it could do the job.

Using the smearing method can work pretty well--but you have to use many
many LSBs worth of noise, maybe 1/8 of full scale or something like
that. That still won't fix it if you have a big glitch at the major
carry point, for instance, but for smaller scale stuff it helps a lot.
You also need to use a really great DAC.

Cheers,

Phil Hobbs

 

[Nico Coesel]

PIC are hard to beat for scalability.
Check out the real details instead of just guessing.
The development toolsets are consistent across 8-bit, 16-bit, DSP, and
32bit lines.

And crappy... The PIC32 bit toolchain uses an ancient GCC compiler.
Free and student versions are crippled on purpose (not all
optimisation options available). So if you want the most from the
PIC32, you really don't want to use the toolset from Microchip.

Besides, why mess around with obfusticated 8 bit devices which
requires proprietary tools while a proper ARM based device with open
tools can be bought for the same amount of money? Microchip has
noticed this too hence the introduction of a microcontroller with a
real CPU. I bet MIPS made them a very good offer to choose a MIPS core
over an ARM core.

When it comes to a consistent toolset I'm quite sure Eclipse beats
most microcontroller development environments hands down. And Eclipse
can work with many more targets than just PIC. If you want a top-notch
consistent development toolset which works for many devices, get
Eclipse and GNU tools.

Look at the high end 32bit PICs:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2591
And there is still a free student version C compiler for it.

If you need anything bigger than those then you are no longer in the
realm of microcontrollers any more, but microprocessors like the ARM
that can access massive amounts of memory and other resources.

Like I stated above, PIC32 is MIPS32 based. They shouldn't call it
PIC. It just doesn't do the MIPS core right. MIPS and ARM are almost
the same. Both are 32bit CPUs with a 32 bit instruction set and a 16
bit compact instruction subset.

 

[DJ Delorie]

Free and student versions are crippled on purpose (not all
optimisation options available).

So? Download the sources and build yourself an uncrippled version.

 

[Nico Coesel]

So? Download the sources and build yourself an uncrippled version.

That is not so easy because MIPS is not the most common architecture.
I'm working on getting GCC 4.1.2 + Glibc + binutils compiled for MIPS
using crosstool but there are some problems with getting the right
versions together and using the proper settings.

 

[DJ Delorie]

That is not so easy because MIPS is not the most common architecture.
I'm working on getting GCC 4.1.2 + Glibc + binutils compiled for MIPS
using crosstool but there are some problems with getting the right
versions together and using the proper settings.

Microchip is required to provide you with the sources to THEIR tools,
so you shouldn't have to worry about getting the right versions.
Download Microchip's gcc sources and build it, then use it in place of
the student version. This is what the GPL is all about.

If you can't get the exact sources to the distributed Microchip gcc,
then Microchip is not obeying gcc's license.

 

[DJ Delorie]

AFAIUI, the optimizer has nothing to do with gcc, hence they are not
obliged to provide the source.

The version I have had gcc's own optimizations disabled. It was easy
to turn them back on again.

 

[Spehro Pefhany]

Microchip is required to provide you with the sources to THEIR tools,
so you shouldn't have to worry about getting the right versions.
Download Microchip's gcc sources and build it, then use it in place of
the student version. This is what the GPL is all about.

If you can't get the exact sources to the distributed Microchip gcc,
then Microchip is not obeying gcc's license.

AFAIUI, the optimizer has nothing to do with gcc, hence they are not
obliged to provide the source.


Best regards,
Spehro Pefhany

 

[Jan Panteltje]

That is not so easy because MIPS is not the most common architecture.
I'm working on getting GCC 4.1.2 + Glibc + binutils compiled for MIPS
using crosstool but there are some problems with getting the right
versions together and using the proper settings.

I downloaded the Linux sources for the Linksys routers from their site,
it includes a working gcc for MIPS, I'v compiled the whole thing and wrote some MIPS
apps too, al seems to work just fine.

My Makefile looks like this (for making a kernel module):
TARGET := mmc
WARN := -W -Wall -Wstrict-prototypes -Wmissing-prototypes -fno-strict-aliasing -mips32

INCLUDE := -isystem /mnt/hdd4/linksys/WAP54Gv3_3_05_03_EN_GPL/release/src/linux/linux/include

CFLAGS := -O2 -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE} -fno-pic -mno-abicalls -mlong-calls

CC := /opt/brcm/hndtools-mipsel-linux-3.2.3/mipsel-linux/bin/gcc

Note the definition of CC
You can download the stuff from the Linksys site (big).
http://www-au.linksys.com/servlet/S...345999&pagename=Linksys/Common/VisitorWrapper

Does this help?

 

[Nico Coesel]

Microchip is required to provide you with the sources to THEIR tools,
so you shouldn't have to worry about getting the right versions.
Download Microchip's gcc sources and build it, then use it in place of
the student version. This is what the GPL is all about.

If you can't get the exact sources to the distributed Microchip gcc,
then Microchip is not obeying gcc's license.

Like I said: the version they offer is too old -they offer the
sources-. Okay, software will compile but there are problems with
handling long long (64 bits integers) and the syntax checking isn't
strict enough to meet modern standards.

 

[Nico Coesel]

I downloaded the Linux sources for the Linksys routers from their site,
it includes a working gcc for MIPS, I'v compiled the whole thing and wrote some MIPS
apps too, al seems to work just fine.

My Makefile looks like this (for making a kernel module):
TARGET := mmc
WARN := -W -Wall -Wstrict-prototypes -Wmissing-prototypes -fno-strict-aliasing -mips32

INCLUDE := -isystem /mnt/hdd4/linksys/WAP54Gv3_3_05_03_EN_GPL/release/src/linux/linux/include

CFLAGS := -O2 -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE} -fno-pic -mno-abicalls -mlong-calls

CC := /opt/brcm/hndtools-mipsel-linux-3.2.3/mipsel-linux/bin/gcc

Note the definition of CC
You can download the stuff from the Linksys site (big).
http://www-au.linksys.com/servlet/S...345999&pagename=Linksys/Common/VisitorWrapper

Does this help?

Not really I tried to use crosstool but I found out this is not a
tool to rely on for modern GCC compilers. I'm now trying
emdebian-tools from emdebian.org. Which seems to work! The reason I
want to get it compiled is because I'm trying to use gcc + glibc for
an embedded device without FPU together with buildroot.

 

[JosephKK]

PIC are hard to beat for scalability.
Check out the real details instead of just guessing.
The development toolsets are consistent across 8-bit, 16-bit, DSP, and
32bit lines.

I admit that i have not studied PIC in particular, but i am looking
for almost any platform that has truly scaled over that range.

MIPS Nearly successful, but fell into disuse. Never
was 8 bit
SPARC came closer, still did not make it, never was 8 bit
X86 almost works right, never really was 8 bit, has
64 bit now
AVR maybe the closest? Was it ever 8 bit?
68K scaled from 16 to 32 bit, never was 8 bit
HP-PARISC scaled from 16 to 64, never was 8 bit
DSPs None were ever 8 bit, 12, 16, 24, and 32 bit (FP)
DEC Alpha Started as 32/64 bit
DG uNova Started as 32 bit, is gone now.
NS32000 Started as 16 bit, hit 32 bit, is all but gone now
SH* Seems to make the grade also, has some 64 bit.
65XXX 8 and 16 bit only
many others 8 bit only
many others 16 bit only

This list is surely partial at best.

You really haven't investigated this properly have you?
PIC have everything from a tiny 8 bit 5 pin job through to huge 32bit
DSP's, and the toolsets and interface are consistent across the entire
line.
Really?

PIC will be able to do anything you ever want, both professionally and
for hobby.
Really?

Microchip have sold *billions* of PICs to industry, hobby sales would
represent a ridiculously small percentage of that.

Look at the high end 32bit PICs:

Like why? If i need 32 bits it is not really a microcontroller any
more. Besides i might like or have more experience with AVRs or SH2,
SH3, SH4, SH5, and thus find them more convenient.

 

[JosephKK]

AFAIUI, the optimizer has nothing to do with gcc, hence they are not
obliged to provide the source.


Best regards,
Spehro Pefhany

Maybe, the question is what do any of their tools have to do with GPL,
LGPL, or other public licences?

 

[DJ Delorie]

Maybe, the question is what do any of their tools have to do with
GPL, LGPL, or other public licences?

Some of their tools are licensed under the GPL.