|
JawnV6 posted:Sorry, I don't mean to sound so snippy. My preferred approach involves both. I like my build process to be simple and command line based, primarily for the reasons I mentioned in my last post. I like to code in an IDE most of the time though. I actually rather like Atmel's AVR Studio 6. I find it easy to work in, the debugger works well and is intuitive (although conditional breakpoints are not supported), and it's been all I've needed so far. Given that it is built on MS Visual Studio, it's not surprising that it has a solid feature set. I am a huge fan of good debuggers, and consider use of one to be a key skill for developers. There are certain times when using a debugger is not really an option (like if you are hacking on a linux kernel device driver, and it is crashing on startup) and so it's good to know other effective approaches to debugging, but I am not typically working in those areas. I take a bit of offense to the statement "Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging..." because it really isn't like that in my industry. Some of the developers I know who have the best practices work in vi or emacs on linux. When they need to debug something, they dust off Eclipse (typically) and use it just for the debugger. They have just internalized the keyboard shortcuts and general mindset of their preferred editor to the point where their productivity is severely impaired using anything else.
|
#
¿
Nov 15, 2013 21:02
|
|
|
|
| # ¿ May 10, 2024 06:56 |
|
|
In black and white text on a computer screen, the sentence reads like a blanket statement attributing shoddy practices to linux command line folk. There are definitely some people who meet your description, but there are an equal number of Windows/OSX IDE programmers who think they can get by with the same shoddy practices. If we just take the "from cmdline linux land" bit out entirely then I don't think anyone will object.
|
|
#
¿
Nov 15, 2013 21:42
|
|
|
I completely agree, but that still doesn't mean debuggers are not great tools. In the last few weeks I've had to debug two nontrivial things where debuggers were invaluable: The first was an IE9 table display issue where hidden <td> elements in large tables loaded via ajax and added to the DOM via innerHTML() would randomly still show up. It turns out this is a known IE9 bug, and the workaround is to remove any whitespace around the <td>s. Figuring out what the hell IE9 was doing without stepping through the Javascript and looking at various values would have been dubious at best. The debugger here gave me a quick and easy way to sanity check that the DOM was right and it was in fact IE9 being screwy. I was also able to step through the same area in Chrome and Firefox and see that they ended up with the same DOM. Yes, sure I could have resorted to the Javascript equivalent of printf - alert() - but it would have been really, really painful to debug that way. The second was a server side issue in Java with Lucene, where multiple distinct servers were sharing an index file and one was leaking a file lock over an NFS mount. Tracking that one down required remotely connecting a debugger to multiple machines simultaneously and stepping through the contested area of code on each box in lock step. Doing this without a proper debugger is outright impossible. You simply can't sync JVMs by making System.out.println() calls. A debugger is necessary sometimes, and if you don't know how and when to use one, you are simply not going to be effective at solving certain problems. Hopefully your development practices are good, and you rarely run into those issues, but they are sometimes out of your control (IE9, NFS weirdness). On the embedded side of things, I am still a complete novice. I find the debugger very useful for mundane things like confirming that my understanding of what registers get updated on different interrupts is actually right. I'll read the datasheet and think I know what it's saying, but then step through my code in the debugger and realize that I misunderstood it slightly. It makes it much easier and faster to see what is actually going on when you really aren't sure.
|
|
#
¿
Nov 15, 2013 22:34
|
|
|
No I admit that I read it negatively. I doubt I'm the only one who did so, but I don't expect or want any apology.
|
|
#
¿
Nov 16, 2013 04:24
|
|
|
I have zero experience with it, but you could always stick it in a VM if you want to try it out without interfering with another install.
|
|
#
¿
Nov 30, 2013 03:03
|
|
|
Luigi Thirty posted:I can't get the drat Dragon to connect to my new ATMega. I have a 10-pin JTAG to 6-pin ISP cable, plug it into the Arduino the only way it fits (it's notched and the notch runs into a plastic header if you put it in backwards). Atmel Studio says VTarget is 2.6V and it can't read the device signature, saying it can't enter programming mode. This is a brand-new ATMega328P straight out of the box. They're both connected to the computer via USB. Now I'm afraid that I damaged components on the board as well other than the AVR. Can you post a picture of how everything is wired up? I've had a similar issue when I wasn't providing power to the chip correctly.
|
|
#
¿
Feb 21, 2014 15:05
|
|
|
I say wired up because I've only used my dragon to program chips in a ZIF header, so I have to do some jumpering to get all the connections in place. Are you providing power to both boards? Have you tried using an ISP cable instead of your JTAG to ISP cable? The dragon docs are here and may be of some use. Edit: Basically to program a chip onboard the arduino, I think you want to be doing this. armorer fucked around with this message at 20:43 on Feb 21, 2014 |
|
#
¿
Feb 21, 2014 20:37
|
|
|
Please don't do that, you can get this to work pretty easily I think. First of all you are connected to the wrong header on the Arduino. That header is to program the USB chip, you want the other 6 pin header.  Second, you will probably need a straight 6 pin cable, because the Dragon is expecting to sense a voltage on one of the ISP header pins. It might work though if you use the Dragon in JTAG mode, I have never tried using a cable like you are.
|
|
#
¿
Feb 21, 2014 20:57
|
|
|
This image give you the pin out for the ICSP header.  The "correct" way to do this is with a 6 pin cable going from the ISP header on the dragon to the ICSP header on the Arduino. Any chance you can get such a cable? Or maybe cut down an old floppy drive cable you have lying around?
|
|
#
¿
Feb 21, 2014 21:30
|
|
|
JawnV6 posted:I'm not sure this is applicable, but when I've used the Dragon to program targets I've either powered it just from the Dragon or not connected the VCC at all. From here: http://www.atmel.no/webdoc/avrdragon/avrdragon.isp_description.html That quote doesn't apply here. That is saying that if you are trying to program a chip on the Dragon itself, you need to jump from VCC to pin 2 on the ISP header. When you are programming an off board chip though you should just connect header to header. The thing that is goofy in what he is doing is that he is running from the dragon JTAG header over to the arduino's ICSP header. I have never tried that, but if it works at all you'll need to tell Atmel Studio that you are using JTAG, not ISP. Edit: Sorry about the double post. I should have just edited my previous comment.
|
|
#
¿
Feb 21, 2014 21:34
|
|
|
Luigi Thirty posted:I took a hacksaw to one end of a floppy cable and just jammed the other end on the Dragon and now I get a device signature and 5V reading. Awesome! I'm glad you got it working. As for the reset enable trace, I really don't know because I haven't used the Dragon in the manner that you are.
|
|
#
¿
Feb 22, 2014 05:12
|
|
|
more like dICK posted:I'm looking to move from an Arduino to something a bit less "magical". Are TI MSP430's a good starting point? You could look into AVR as well, since you already have one in your Arduino.
|
|
#
¿
Apr 4, 2014 21:09
|
|
|
PDP-1 posted:Atmel Studio 6.2 (set up for an ATtiny24) is taking this ISR handler code I am pretty sure you should just do code:
|
|
#
¿
Sep 24, 2014 04:13
|
|
|
A long time ago I made a post in here about getting up and running doing AVR programming on windows. I said I would follow up at some point with a linux walkthrough. Is there interest in that still? I could write up something that goes through the various free linux command line tools, including debugging.
|
|
#
¿
May 6, 2015 15:44
|
|
|
Aurium posted:I think it would be great if you did. Debugging is of particular interest to me. Okay, I got debugging working using avarice and gdb. You could front-end gdb with something if you want, but I won't go into that. In my write-up I'll be using an AVR Dragon, Mint 16 (out of date, should probably work on any more recent Ubuntu/Debian-based distro), and an atmega328p. The atmega328p doesn't support JTAG, so I'm using debugWire, but it should be even easier to do on an AVR chip that supports JTAG.
|
|
#
¿
May 6, 2015 19:55
|
|
|
|
| # ¿ May 10, 2024 06:56 |
|
|
Popete posted:If you could writeup something on using an AVR emulator on Linux that would be cool. A guide to setting up and using simavr for instance. I will see about adding that in. I haven't had time to do the writeup yet, but I have everything prepared for it other than running an emulator. It is a pretty solid thing to add though so I'll see what I can do.
|
|
#
¿
May 12, 2015 10:11
|
|