Joerg wrote:> Les Cargill wrote: >> hamilton wrote: >>> On 3/6/2014 8:04 PM, Les Cargill wrote: >>>> Simon Clubley wrote: >>>>> On 2014-03-06, Mel Wilson <mwilson@the-wire.com> wrote: >>>>>> Ed Prochak wrote: >>>>>> >>>>>>> Just wondering what folks thought about the Arduino platform. Any >>>>>>> users >>>>>>> here? >>>>>>> >>>>>>> It looks like a simple easy to use platform. Anyone care to share >>>>>>> experience with this in an embedded system. >>>>>> >>>>>> I've said before: it's over-packaged. For proofs-of-concept, or for >>>>>> one- >>>>>> offs to drive test jigs and such things, I love Arduini. For a final >>>>>> design, I find that the baked-in design decisions start to get in the >>>>>> way, >>>>>> and eventually it's time to do a custom board. And the expense, too. >>>>>> >>>>> >>>>> And a good thing about the AVR is that much of the range _is_ available >>>>> in PDIP so prototyping a circuit is rather easy and a hobbyist does not >>>>> have to go to pre-packaged boards like Arduino, or start designing and >>>>> assembling PCBs, in the same way you have to do when working with ARM. >>>>> >>>>> Simon. >>>>> >>>> >>>> I am on a strict no-AVR diet these days. Never again. >>>> >>> >>> I have used AVR 8-bit on a few products. Good enough for what I was >>> doing. >>> >> >> >> AVR works, but you can't stick your hand in the same river twice with them. >> >> Granted, that's not unique to AVR, but I got bit by that on AVR. >> > > Can you elucidate what happened?It could easily have been a problem on our end, but I doubt it. I We could not get one of their JTAG pods to get the processor in HALT. We had two; one old, one new and the new one just didn't work.> 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. >I don't use an IDE unless I am forced to.> [...] >-- Les Cargill
Arduino users?
Started by ●March 6, 2014
Reply by ●March 11, 20142014-03-11
Reply by ●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.-- John Devereux
Reply by ●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 ●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 ●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 ●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 ●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 ●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 ●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 ●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/
