Atmel ICE and Atmel Studio is useful but a micro controller with a Cortex-M*- CPU is probably a lot better choice. They are very good, cheap, very common and used by many manufacturers. Most of them if not all will be able to do PWM for DC or 3-phase motors and probably the same with a quadrature encoder. Most of them if not all have UART and SPI for communication while the more expensive also have Ethernet.
On Thu, 23 Feb 2017 19:09:54 +1100 Erik Christiansen <dva...@internode.on.net> wrote: > On 22.02.17 09:50, Dave Cole wrote: > > Is anyone using the ATMEL ICE and Atmel Studio 7 IDE to do Arduino > > programming and debug? > > > > http://blog.solutions-cubed.com/debugging-arduino-sketches-with-atmel-studio-7/ > > The Atmel ICE referenced there is fancier than the one I used more > than a decade ago, at least in the range of targets it supports. > > (I just use the GNU toolchain, as "Unix _is_ the IDE" in my little > world, and GUIs don't seem worth the inconvenience.) > > > Apparently when using that combo you can do breakpoints during debug. > > ISTR that even the old one provided several breakpoints, which are > needed if you have to capture which way the code branched, and there are > several possibilities. > > > The ICE uses the 6 pins on the Arduino rather than the USB port > > Yes, it talks SPI to on-chip hardware which does the actual RT breakpoint > matching, IIRC. (So the USB port is a completely unrelated peripheral in > this context.) > > > and circumvents the regular Arduino boot loader that is used with the > > Arduino IDE. > > Yes, it also functions a programmer, just like an STK500 or any of the > AVR programming dongles swarming on the intertubes. It's great for > programming a new bootloader too, if needed. > > > However Atmel Studio can also be used without circumventing the > > Arduino boot loader as well. So what is the best way to go? > > Debugging and programming need not be performed with the same device, > but is most convenient if the debugger doesn't have to be disconnected > when downloading new code. That should be possible with USB download as > well, probably, so whatever is easier with a cup of coffee in the other > hand. > > > I need to do some code debug which is going to be really difficult to > > debug without using breakpoints. > > For the first two decades of RT embedded software development, I always > had an ICE, and believed they were essential for the task. Over the > following decade I learned that a hell of a lot can be done without, and > stopping at a breakpoint can be inferior to capturing a snapshot byte or > two in RAM, then logging them via the UART, to a monitoring PC. BUT, > even in that last decade, there _were_ times when we made sure there was > an ICE at our elbow, even if it had to be shipped in from Japan, as in > the case of the NEC V850 target. > > At $60, I'd snaffle one, just as insurance for meeting project deadlines. > (Even if the project is just DIY stuff.) > > > Print statements via the Arduino IDE is not going to cut it. Life is > > too short. > > When developing an 8-channel PABX phone interface card, using an > ATmega64, I made sure we had the UART going first, and logged such > things as per-channel state transitions via that. It turned out better > than an ICE, because it gave more insight _and_ didn't stop the > multi-threaded multi-instance state machines; the itty-bitty OS kept > chugging, with its timer service, so that software timers could still > elapse, even as we were capturing debug guff. > > A breakpoint is a crowbar in the gears - not always the best debugging > solution in RT applications. Development can be faster without an ICE, > if you hold your mouth right. ;-)) > > > Is using the Atmel ICE the way to go, or is simply using the Atmel > > Studio 7 IDE sufficient for difficult debugs. > > > The Atmel ICE interface is only $60, Atmel Studio is a free download, > > so its really not expensive. > > Yep, it's amazingly cheap, and it is comforting to know it's in the box > under the desk. I'd give it a whirl, but e.g. building the code up from > a little round-robin scheduler blinking a LED, to running two tasks, > each blinking at a different rate, to multi-threaded multi-instance > state machines, means each capability increment has little to debug, and > logging might be just as good, in practice. > > It's cheap peace of mind, innit? > > Hopefully attempting to answer your questions is a bit more useful than > chirruping names and numbers of other CPUs that you're not using. Yes, > we all have our favourites, and the use-my-cpu-with-cream-cheese-and-pickles > non-answers crop up on other lists as well. Sigh. > > Sometimes I pick up a sub-$10 (including postage and USB cable) Arduino > board and a bare "shield" on Ebay, just to use as cheap quick hardware, > blow away the bootloader, and use it as a bare ATmega328P, hitting it > with GCC and a programmer. (Just don't tell anyone that I do most of the > programming in assembler, especially the state machines, for which I > have a mini "language" created with assembler macros.) > > Erik > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users -- Nicklas Karlsson <nicklas.karlsso...@gmail.com> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
