[MakeLV] My dream project

[Will]

One comment on top of that, I'm convinced the debugging tools for Microchip
(especially after being spoiled with the ICD3 or even better the ICE) are
much better. With Microchip, I know the the ICD's and ICE program a hell of
a lot faster than any boot loader I've used with their stuff (which is
minimal to say the least). So platform makes a difference depending on what
you tools you choose to use or not use.

-Will C

On Fri, Jul 20, 2012 at 9:06 AM, <rsjames at ix.netcom.com> wrote:

>  I’m going to quibble with Darrell a bit over using debuggers versus
> Bootloaders.  I actually program the AVR32 system I am working on with
> the Bootloader rather than the debugger (which I do have).  My target is
> pretty much based on the Atmel EVK1100 development board.  There are a
> few reasons for using the Bootloader:
>
> 1.    It is faster.  With the debugger, the code is first downloaded to
> the debugger through USB, and then it goes to the chip.  With the
> Bootloader, it goes right to the chip (also via USB).  I did write a
> routine that allows single click downloading between the PC and the USB
> port, but I do still have to do a power cycle before the download.
>
> 2.    The debugger is integrated with Atmel’s development Studio, but the
> interface isn’t great.  There isn’t an option to automatically download
> after the code is built.  This doesn’t sound like a big deal, but I might
> do 50 downloads a day, so it can make a difference.
>
> 3.    The debugger is a bit quirky.  It doesn’t always work.  Lots of
> power cycling.  Occasionally, it decides that it needs to have its
> firmware reloaded from the Studio.
>
> 4.    It does breakpoints poorly.  You click on a line to insert one, but
> clicking on the line again only removes the breakpoint symbol on the screen.
> The breakpoint may still be there in the code!
>
> 5.    Single stepping may not work.  I’m pretty sure this is because I’m
> running FreeRTOs, and the interrupt servicing messes with the single
> stepping.
>
> **** **
>
> ** **
>
> Now the other side.  I spent over a year using just the debugger, and not
> the Bootloader.  It is effective.  I did make quite a bit of use of the
> breakpoint, single step, and memory accesses capabilities.  Currently, I
> do most of my debugging using print statements.  This works a lot better
> with the RTOS.  But I am doing this on a well established code base.  I
> have good serial interface routines to send messages to my PC.  Also, the
> types of problems I am dealing with now aren’t well suited to low level
> debugging.
>
> ** **
>
> I would not want to start developing a new project without a debugger.  Until
> you have an established code base, there is no better way to debug.
>
> ** **
>
> My target actually has four connections to my PC – The JTAG debugger
> (debug and programming), USB (programming with the Bootloader), Serial
> (informational, diagnostic, and debug messages to the PC), and Ethernet
> (communications and programming).  It has more cables than a patient in
> intensive care!  Reprogramming via Ethernet is very interesting, but that
> is a whole ‘nother topic!
>
>
>
> RSJ
>
>
>
>
> -----Original Message-----
> From: Darrell Thayer **
> Sent: Jul 19, 2012 10:16 PM
> To: Build things for fun! **
> Subject: Re: [MakeLV] My dream project
>
> My advice is to skip the bootloader game. Just go with the Pickit 3 - it
> is way cheap and can program and debug every PIC on the planet.
>
> A bootloader is really made to allow for in-the-field updates of software
> - AFTER it has been developed and tested with a full development
> environment (with a debugger).
>
> Bootloaders can also be used by hobbyists that are too cheap (or
> uninformed) to fork out a few more bucks for a real debugger - and don't
> mind wasting a giant amount of their spare time trying to guess what is
> wrong withe their code and/or hardware!  With bootloaders, you have to buy
> special chips and/or boards (with limited chip selection) with
> bootloaders installed - and pay extra every time you buy a board/chip.
>
> Note that in Arduino (a "bootloader" type device), the IDE turns off the
> underlying (GNU-AVR-gcc) compiler warnings - which often points you to what
> may be wrong with your code. Then, to make it worse, there is NO DEBUGGER
> to help you find out what IS wrong!
>
> The Pickit 3 is a full blown ICD (In Circuit Debugger). Do note that some
> very inexpensive PICs do not have the pins or hardware to provide ICD
> functionality - so they need a special "header board" to allow for full
> debugging ( like $25 ). So don't use these PICS - pay an extra 10 cents and
> get one with more pins that supports the IDE w/o a header board.
>
> An ICD/debugger takes full control of a chip such that the IDE (Integrated
> Development Environment - like Microchip's MPLAB) can not only program it,
> but can also allow you to debug your code (right down to the "bare metal").
>
> No sane (or employed) embedded software engineer would waste their
> precious time developing software on a micro-controller without using a
> debugger. I have seen a few people use things like Basic Stamps (for like
> $35 or more) to do something simple - where a 1$ PIC does the job better. I
> gave up on playing with microcontrollers as a hobby for a few decades ...
> until what used to cost THOUSANDS of dollars now costs about $50.
>
> With a Pickit3, you can develop/debug code for ANY PIC processor - without
> any circuit board - just pick one in a DIP package an plug it into a
> solderless breadboard.
> Note that every PIC does not even need an external oscillator (xtal nor
> ceramic resonator); it can use its internal oscillator instead (in many
> projects, the oscillator
> frequency is not at all critical). Actually, a breadboard is not a great
> environment to even use a crystal oscillator - as the PCB layout for
> xtals (and their little picofarad caps) is kind of critical; a resonator
> is not as critical.
>
> Note you will see many dedicated "assembly language only" PIC
> hobbyists/projects on the web. These guys usually came from when the C
> compilers were NOT free, but assembly was. If you want to program in
> assembly, you are in for a massive learning curve. Today, assembly language
> is for making high volume devices where saving a few microseconds or a few
> pennies can save big bucks (like in a toothbrush or this razor:
> http://www.ganssle.com/misc/hydrorazor.pdf ). And only sometimes,
> assembly is required for very fast code (like in an interrupt service
> routine - ISR).
>
> I do love the PIC24F series - very powerful and their "Peripheral Pin
> Select" (PPS) feature can route most digital peripheral functions to any
> "PPS Pin" - also very cool. I often simply breadboard (solderless or
> soldered) PIC24s (ones in DIP packages) - running straight off of batteries
> or a wall-wart and little (3.3V) voltage regulator. Even the 32 bit PIC32
> comes in DIP packages now - a PIC32 can run at 80MHz.
>
> If you are not yet comfortable with breadboarding, as Karl (above)
> suggested, the "Microstick for 3V PIC24F K-series" looks like a good way
> to go. Since this little thing can debug and program PIC24s (and it can be
> plugged into a breadboard), it appears to be a full development system (but
> just for PIC24Fs). I am not sure if it has limitations compared to the
> Pickit3.
>
> Remember the little BASIC PICAXE though (
> http://www.picaxe.com/What-Is-PICAXE). It is very popular in Europe, the
> chips are really cheap, the development environment is free, downloading
> code is via a serial cable. I have made numerous little projects with
> PICAXE processors. However, PICAXE only runs a BASIC interpreter, there is
> only a simulator (not a full debugger), and code runs slowly .... but many
> devices simply do not need to run very fast.
>
> The conversation continues,
> Darrell Thayer
>
>
> _______________________________________________
> Makelehighvalley mailing list
> Makelehighvalley at makelehighvalley.com
>
> http://makelehighvalley.com/mailman/listinfo/makelehighvalley_makelehighvalley.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://makelehighvalley.com/pipermail/makelehighvalley_makelehighvalley.com/attachments/20120720/db6c7164/attachment.htm>