> Grant Edwards <invalid@invalid.invalid> writes:
>
>> On 2014-03-12, John Devereux <john@devereux.me.uk> wrote:
>>>
>>>> I do not trust the POR/BOR on them at all. But that goes for most uC, it
>>>> seems uC designers have a hard time with threshold detectors or the
>>>> respective companies don't have enough analog talent.
>>>
>>> Anything that is the slightest bit analog they get wrong. (Generally,
>>> not Atmel specifically). BOD, POR, clock PLLs, voltage references,
>>> ADCs. Startup, Real time clocks, sleep current.
>>
>> In my experience, TI does a better job than most when it comes to the
>> analog stuff on uControllers, but it does seem that putting analog
>> stuff on the same die as a CPU results in generally sucky analog
>> stuff.
>
> I guess the process is tuned for, say, flash memory and everything else
> just has to work with that.
>
Yes, that's definitely a big part of the problem. When you make a pcb,
you have choices about the number of layers, the thickness of the
layers, width of tracks, types of vias, power layers, coatings, etc.
You pick different combinations for boards that are high-speed digital,
accurate analogue, low-power, high current, etc. Chip design is
somewhat similar, but there are more factors, they make a bigger
difference, and they are harder to mix on the same die. So mixing
digital parts, memory, power parts and analogue parts on the same die is
always going to mean compromises.
> The other leading edge analog vendor is ADI, and they are the only ones
> I would trust to put an ADC on a CPU chip. Trouble is their digital
> peripherals are clunky.
>
> These look pretty powerful:
>
> <http://www.analog.com/en/processors-dsp/cm4xx/products/index.html>
>
> I have not tried any TI micros yet, they were late in the game with ARMs
> IIRR.
>
>
Reply by Joerg●March 12, 20142014-03-12
langwadt@fonz.dk wrote:
> Den onsdag den 12. marts 2014 19.08.06 UTC+1 skrev John Devereux:
>> Grant Edwards <invalid@invalid.invalid> writes:
>>
>>
>>
>>> On 2014-03-12, John Devereux <john@devereux.me.uk> wrote:
>>>>> I do not trust the POR/BOR on them at all. But that goes for most uC, it
>>>>> seems uC designers have a hard time with threshold detectors or the
>>>>> respective companies don't have enough analog talent.
>>>> Anything that is the slightest bit analog they get wrong. (Generally,
>>>> not Atmel specifically). BOD, POR, clock PLLs, voltage references,
>>>> ADCs. Startup, Real time clocks, sleep current.
>>> In my experience, TI does a better job than most when it comes to the
>>> analog stuff on uControllers, but it does seem that putting analog
>>> stuff on the same die as a CPU results in generally sucky analog
>>> stuff.
>>
>>
>> I guess the process is tuned for, say, flash memory and everything else
>>
>> just has to work with that.
>>
>>
>>
>> The other leading edge analog vendor is ADI, and they are the only ones
>>
>> I would trust to put an ADC on a CPU chip. Trouble is their digital
>>
>> peripherals are clunky.
>>
>
> seems the manufacturers do one of two things:
>
> make analog designers do the analog peripherals, the analog works but the digital interface is a clunky hairball that barely works
>
> make digital designers do the analog peripherals, the digital interface
> works but the analog performance leaves a lot to be desired
>
This could easily be solved if they accepted the use of consultants.
Often not done in large companies and that's a big mistake.
--
Regards, Joerg
http://www.analogconsultants.com/
Reply by ●March 12, 20142014-03-12
Den onsdag den 12. marts 2014 19.08.06 UTC+1 skrev John Devereux:
> Grant Edwards <invalid@invalid.invalid> writes:
>
>
>
> > On 2014-03-12, John Devereux <john@devereux.me.uk> wrote:
>
> >>
>
> >>> I do not trust the POR/BOR on them at all. But that goes for most uC, it
>
> >>> seems uC designers have a hard time with threshold detectors or the
>
> >>> respective companies don't have enough analog talent.
>
> >>
>
> >> Anything that is the slightest bit analog they get wrong. (Generally,
>
> >> not Atmel specifically). BOD, POR, clock PLLs, voltage references,
>
> >> ADCs. Startup, Real time clocks, sleep current.
>
> >
>
> > In my experience, TI does a better job than most when it comes to the
>
> > analog stuff on uControllers, but it does seem that putting analog
>
> > stuff on the same die as a CPU results in generally sucky analog
>
> > stuff.
>
>
>
> I guess the process is tuned for, say, flash memory and everything else
>
> just has to work with that.
>
>
>
> The other leading edge analog vendor is ADI, and they are the only ones
>
> I would trust to put an ADC on a CPU chip. Trouble is their digital
>
> peripherals are clunky.
>
seems the manufacturers do one of two things:
make analog designers do the analog peripherals, the analog works but the digital interface is a clunky hairball that barely works
make digital designers do the analog peripherals, the digital interface
works but the analog performance leaves a lot to be desired
-Lasse
Reply by John Devereux●March 12, 20142014-03-12
Paul Rubin <no.email@nospam.invalid> writes:
> John Devereux <john@devereux.me.uk> writes:
>>> it does seem that putting analog stuff on the same die as a CPU
>>> results in generally sucky analog stuff.
>> I guess the process is tuned for, say, flash memory and everything else
>> just has to work with that.
>
> The digital stuff in an Arduino-level 8-bit microcontroller is quite
> wimpy compared to the faster ARM mpu's, application processors, etc. I
> wonder if they could use processes tuned to the analog stuff and just
> accept lower efficiency of the digital part. Even if the digital
> performance suffers by 2x or more vs. a digital-optimized process on the
> same amount of silicon, it could still be fine.
That is what ADI did with their "analog microcontrollers".
<http://www.analog.com/en/processors-dsp/analog-microcontrollers/products/index.html>
Mediocre cores with decent analog.
But their new CM4xx look like the successors to these, and are very
powerful. Expensive, and I don't know what the digital periperals are
like (IME they are usually a bit limited compared to other vendors).
--
John Devereux
Reply by Paul Rubin●March 12, 20142014-03-12
John Devereux <john@devereux.me.uk> writes:
>> it does seem that putting analog stuff on the same die as a CPU
>> results in generally sucky analog stuff.
> I guess the process is tuned for, say, flash memory and everything else
> just has to work with that.
The digital stuff in an Arduino-level 8-bit microcontroller is quite
wimpy compared to the faster ARM mpu's, application processors, etc. I
wonder if they could use processes tuned to the analog stuff and just
accept lower efficiency of the digital part. Even if the digital
performance suffers by 2x or more vs. a digital-optimized process on the
same amount of silicon, it could still be fine.
Reply by John Devereux●March 12, 20142014-03-12
Grant Edwards <invalid@invalid.invalid> writes:
> On 2014-03-12, John Devereux <john@devereux.me.uk> wrote:
>>
>>> I do not trust the POR/BOR on them at all. But that goes for most uC, it
>>> seems uC designers have a hard time with threshold detectors or the
>>> respective companies don't have enough analog talent.
>>
>> Anything that is the slightest bit analog they get wrong. (Generally,
>> not Atmel specifically). BOD, POR, clock PLLs, voltage references,
>> ADCs. Startup, Real time clocks, sleep current.
>
> In my experience, TI does a better job than most when it comes to the
> analog stuff on uControllers, but it does seem that putting analog
> stuff on the same die as a CPU results in generally sucky analog
> stuff.
I guess the process is tuned for, say, flash memory and everything else
just has to work with that.
The other leading edge analog vendor is ADI, and they are the only ones
I would trust to put an ADC on a CPU chip. Trouble is their digital
peripherals are clunky.
These look pretty powerful:
<http://www.analog.com/en/processors-dsp/cm4xx/products/index.html>
I have not tried any TI micros yet, they were late in the game with ARMs
IIRR.
--
John Devereux
Reply by Grant Edwards●March 12, 20142014-03-12
On 2014-03-12, John Devereux <john@devereux.me.uk> wrote:
>
>> I do not trust the POR/BOR on them at all. But that goes for most uC, it
>> seems uC designers have a hard time with threshold detectors or the
>> respective companies don't have enough analog talent.
>
> Anything that is the slightest bit analog they get wrong. (Generally,
> not Atmel specifically). BOD, POR, clock PLLs, voltage references,
> ADCs. Startup, Real time clocks, sleep current.
In my experience, TI does a better job than most when it comes to the
analog stuff on uControllers, but it does seem that putting analog
stuff on the same die as a CPU results in generally sucky analog
stuff.
--
Grant Edwards grant.b.edwards Yow! Do I have a lifestyle
at yet?
gmail.com
Reply by John Devereux●March 12, 20142014-03-12
Joerg <invalid@invalid.invalid> writes:
> John Devereux wrote:
>> Joerg <invalid@invalid.invalid> writes:
>>
>>> John Devereux wrote:
>>>> Joerg <invalid@invalid.invalid> writes:
>>>>
>>>>> Simon Clubley wrote:
>>>>>> On 2014-03-11, Joerg <invalid@invalid.invalid> wrote:
>>>>>>> Can you elucidate what happened? We are wrestling with ATMegas (328 and
>>>>>>> 1284) right now and it's painful. Unfortunately they started with the
>>>>>>> Arduino IDE and somehow the things don't behave consistently. But we
>>>>>>> haven't gotten to the root cause just yet.
>>>>>>>
>>>>>> Within each AVR MCU variant, are the AVR fuses set to the same values ?
>>>>>>
>>>>> They did correct the libraries accordingly. But who knows, the Arduino
>>>>> IDE is a bit mysterious in that respect. Sometimes a system works fine
>>>>> for a few hours and then crashes. Other times it didn't even boot or
>>>>> needed a few firmware re-loads.
>>>> The "fuses" are configuration bits in eeprom, they can indeed be a
>>>> source of inconsistent behaviour.
>>>>
>>> Is it possible that fuses become partially "undone" or partially set?
>>
>> I guess it must be *possible* for them to be partially set. If
>> programming is interrupted or done incorrectly or at wrong voltage
>> perhaps.
>>
>
> That we could safely exclude.
>
>
>> I was thinking more of something like the wrong clock oscillator option,
>> or wrong brownout detection level.
>>
>> I seem to recall reports of on-chip POR being flakey too, but it is
>> years and years since I used them.
>>
>
> I do not trust the POR/BOR on them at all. But that goes for most uC, it
> seems uC designers have a hard time with threshold detectors or the
> respective companies don't have enough analog talent.
Anything that is the slightest bit analog they get wrong. (Generally,
not Atmel specifically). BOD, POR, clock PLLs, voltage references,
ADCs. Startup, Real time clocks, sleep current.
--
John Devereux
Reply by Joerg●March 12, 20142014-03-12
John Devereux wrote:
> Joerg <invalid@invalid.invalid> writes:
>
>> John Devereux wrote:
>>> Joerg <invalid@invalid.invalid> writes:
>>>
>>>> Simon Clubley wrote:
>>>>> On 2014-03-11, Joerg <invalid@invalid.invalid> wrote:
>>>>>> Can you elucidate what happened? We are wrestling with ATMegas (328 and
>>>>>> 1284) right now and it's painful. Unfortunately they started with the
>>>>>> Arduino IDE and somehow the things don't behave consistently. But we
>>>>>> haven't gotten to the root cause just yet.
>>>>>>
>>>>> Within each AVR MCU variant, are the AVR fuses set to the same values ?
>>>>>
>>>> They did correct the libraries accordingly. But who knows, the Arduino
>>>> IDE is a bit mysterious in that respect. Sometimes a system works fine
>>>> for a few hours and then crashes. Other times it didn't even boot or
>>>> needed a few firmware re-loads.
>>> The "fuses" are configuration bits in eeprom, they can indeed be a
>>> source of inconsistent behaviour.
>>>
>> Is it possible that fuses become partially "undone" or partially set?
>
> I guess it must be *possible* for them to be partially set. If
> programming is interrupted or done incorrectly or at wrong voltage
> perhaps.
>
That we could safely exclude.
> I was thinking more of something like the wrong clock oscillator option,
> or wrong brownout detection level.
>
> I seem to recall reports of on-chip POR being flakey too, but it is
> years and years since I used them.
>
I do not trust the POR/BOR on them at all. But that goes for most uC, it
seems uC designers have a hard time with threshold detectors or the
respective companies don't have enough analog talent.
[...]
--
Regards, Joerg
http://www.analogconsultants.com/
Reply by John Devereux●March 12, 20142014-03-12
Joerg <invalid@invalid.invalid> writes:
> John Devereux wrote:
>> Joerg <invalid@invalid.invalid> writes:
>>
>>> Simon Clubley wrote:
>>>> On 2014-03-11, Joerg <invalid@invalid.invalid> wrote:
>>>>> Can you elucidate what happened? We are wrestling with ATMegas (328 and
>>>>> 1284) right now and it's painful. Unfortunately they started with the
>>>>> Arduino IDE and somehow the things don't behave consistently. But we
>>>>> haven't gotten to the root cause just yet.
>>>>>
>>>> Within each AVR MCU variant, are the AVR fuses set to the same values ?
>>>>
>>> They did correct the libraries accordingly. But who knows, the Arduino
>>> IDE is a bit mysterious in that respect. Sometimes a system works fine
>>> for a few hours and then crashes. Other times it didn't even boot or
>>> needed a few firmware re-loads.
>>
>> The "fuses" are configuration bits in eeprom, they can indeed be a
>> source of inconsistent behaviour.
>>
>
> Is it possible that fuses become partially "undone" or partially set?
I guess it must be *possible* for them to be partially set. If
programming is interrupted or done incorrectly or at wrong voltage
perhaps.
I was thinking more of something like the wrong clock oscillator option,
or wrong brownout detection level.
I seem to recall reports of on-chip POR being flakey too, but it is
years and years since I used them.
> We've had cases where everything worked well and after a few hours or
> days the ATMega would seem to slowly "die". Reprogramming brought it
> back, most of the time.