On 07/03/14 13:58, Mel Wilson wrote:> Tom Gardner wrote: > >> On 06/03/14 19:59, 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'd be curious as to how difficult it would be to use >> Arduino hardware /without/ using the Arduino run-time >> environment. > > Apparently not difficult. I've seen signs on Adafruit and maybe BoingBoing > that people are doing that. Seems you can use the Arduino serial bootloader > to download any binary code, and if you have a native AVR programmer you can > replace the bootloader. And I believe there may be a sketch to program an > Arduino to be a native AVR programmer. I haven't tried this. I may be > wrong.I'm sure you can simply ignore the bootloader, or alternatively merely use it to boot into your own code. (Same advantage as MSDOS: once you'd loaded your program, it stayed out of the way unless you used the BIOS functions!) But what do the various Arduino libraries presume about the runtime environment? I never bothered to find out.> Thing for me is that if I must start soldering, I can put an ATmega onto a > board for $10 or less. Not $30.Yes, but avoiding having to design and build the i/o gubbins on the various shields has its attractions in some circumstances. Having said that, for the project below, I also decided to have fun finding out how to build a double-sided PCB using the laser printer resist technique :)>> Background is that I recently build a glorified >> real-time clock calendar with personalised >> information that runs off a couple of AA cells >> for several months. I used the AVR IDE and AVR >> Dragon, which was pleasant enough except that >> it required Windoze. (No idea whether it could run >> under Win8, and quite frankly I don't care). > > I think openocd will work with the Dragon. See > <http://hackaday.com/2010/10/25/avr-programming-02-the-hardware/> . There's > a lot there we all already know, but the rest seems to be from the horse's > mouth.I had a quick hack trying to get the environment working under Linux, but at the first sign of aggro I rapidly gave up and took the easy Windoze path :( Root cause may well have been an almost-but-not-quite- obsolete version of Ubuntu LTS. Maybe I'll choose to skin that cat another time.
Arduino users?
Started by ●March 6, 2014
Reply by ●March 7, 20142014-03-07
Reply by ●March 10, 20142014-03-10
Tom Gardner wrote:> I'd be curious as to how difficult it would be to use Arduino hardware > /without/ using the Arduino run-time environment.Not very. I've tried it a few times (using AVR-Ada) without any real problems once I had managed to compile AVR-Ada hosted on my development platform (Debian). I've never cared to try the official Arduino IDE. Greetings, Jacob -- �Saving keystrokes is the job of the text editor, not the programming language.� -- Preben Randhol
Reply by ●March 10, 20142014-03-10
On 03/10/2014 02:51 AM, Jacob Sparre Andersen wrote:> Tom Gardner wrote: > >> I'd be curious as to how difficult it would be to use Arduino hardware >> /without/ using the Arduino run-time environment. > > Not very. I've tried it a few times (using AVR-Ada) without any real > problems once I had managed to compile AVR-Ada hosted on my development > platform (Debian). I've never cared to try the official Arduino IDE. > > Greetings, > > Jacob >The Arduino IDE is just a front end to the GCC tool chain. You can go outside the sketch language which is just a C subset. If you look the predefined functions are just a collection of C++ classes to make the peripherals easier to use. The sketch is run through the C preprocessor to expand the Arduino stuff and then sent to the GCC AVR G++ and linker. You can access the I/O registers directly using the standard AVR mnemonics (remember it goes through the standard tool set). I wrote code that was mostly Arduino with a few direct register accesses and an interrupt handler to handle a case where the base pin I/O and polling was too slow. You can also use the IDE to develop for smaller chips (ATtiny 24 and 25 series for example). You can then load a sketch into the Arduino to use it as a hardware programmer and download the code into the ATtiny. The programmer sketch is included as one of the sample programs. See http://hlt.media.mit.edu/?p=1695 for ATtiny development. As far as using the Arduino directly as an imbedded processor, I would probably not do that unless all the functions were needed. Using it for development and then a smaller board (or even smaller chip) may be more practical. If you are actually using most of the Arduino functions smaller form factor boards are available for the classic Arduino. For example I developed an IR remote decoder using the Arduino and IDE. I then loaded the code into an ATtiny85 for the end use (I only needed a couple of I/O lines decoded).
Reply by ●March 11, 20142014-03-11
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? 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. [...] -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 11, 20142014-03-11
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 ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●March 11, 20142014-03-11
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. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 11, 20142014-03-11
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. -- John Devereux
Reply by ●March 11, 20142014-03-11
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? 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. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 11, 20142014-03-11
On 2014-03-11, Joerg <invalid@invalid.invalid> wrote:> 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? > 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. >If I had to consider such a possibility in one of my projects, I would: 1) use avrdude in CLI mode to first manually verify the fuses were set to the same values for all devices within the same AVR MCU variant (and I would read the fuse documentation in the Atmel docs to make sure those values made sense). 2) Run my application until it failed again. 3) After failure, once again use avrdude in CLI mode to manually verify the fuse settings were unchanged from step 1. Can you do the same with whatever tools you are using ? Simon. PS: I've never experienced AVRs slowly dying even with the homebrew AVR flash programmer setup I have. I have managed to kill them outright when the programmer failed on _very_ rare occasions, but I have never seen a slow failure. Have you tried another type of programmer ? -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●March 11, 20142014-03-11
Simon Clubley wrote:> On 2014-03-11, Joerg <invalid@invalid.invalid> wrote: >> 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? >> 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. >> > > If I had to consider such a possibility in one of my projects, I would: > > 1) use avrdude in CLI mode to first manually verify the fuses were set > to the same values for all devices within the same AVR MCU variant (and > I would read the fuse documentation in the Atmel docs to make sure > those values made sense). > > 2) Run my application until it failed again. > > 3) After failure, once again use avrdude in CLI mode to manually verify > the fuse settings were unchanged from step 1. >Good idea. But they'd have to get their hands around AVR-Dude. Right now they are using the serial port programmer that comes with Arduino. Which requires this hokey "capacitor in the air" at the reset pin.> Can you do the same with whatever tools you are using ? >Unfortunately not. Arduino seems to be very restricted in the diagnostic area :-(> Simon. > > PS: I've never experienced AVRs slowly dying even with the homebrew > AVR flash programmer setup I have. I have managed to kill them outright > when the programmer failed on _very_ rare occasions, but I have never > seen a slow failure. Have you tried another type of programmer ? >No, this is a client far away and their main strength isn't really programming. But we are in the process of moving everything away from Arduino. This includes using professional uC contractors, something that I am really not. -- Regards, Joerg http://www.analogconsultants.com/
