ok, it's old good thing. Last large project I maintain was built on am186 40MHz chip, and I'd use rs232 boot loader and serial port console to debug it. that was very long story, and we got the functioning system (access control with myfire cards fo 64000 person and general purpose rule-based control system) in 3 years. now I'm developing a thickness gauge based on msp430fg4617, and I got a full-featured working sample (graphic LCD, UI, statistics, memory, IrDA etc.) in 6 months. too bad, the propiertary IDE from TI has a limitation of 8 kb of code and we do not want to spend any funds for development tools except the hardware, so we turned to opensource (as I see, it is also a good way to do something good for the community).
2007/9/21, David Smead <[email protected]>: > > Most of the code I write is for embedded systems using MSP430, AVR, and > ARM chips. If you're trying to do much debugging using gdb, GUI > front end or not, expect some slow slugging. > > You have to build your own debugging environment to locate bugs quickly. > > You need gdb to get a serial port operating and after that you can use > that for the majority of debugging. I wrote my own small scanf and > printf functions to further simplify using a serial port. On top of > that I have a small monitor that allows peek and poke and other specific > commands to examine task specific information. > > ARM processors have traps for memory accesses of data and instructions > which are outside memory bounds or illegal. You want some code behind > such traps to report them. It's a good idea to supply interrupt service > routines for all possible interrupts just in case one of them gets > enabled you will trap it. You also want some sort of fatal_error > function you can drop in anywhere to catch abnormal conditions. That > function should output the file name and line number. > > I've been writing code hot and heavy since spring - 115K executable in > an LPC2148 processor, and I've probably used gdb breakpoints a dozen > times. Would I have benefitted from a GUI? Not! > > Having writen embedded software since the the mid-1960s, one constant > I've observed is; those who don't plan and implement a debugging > strategy as part of their application development will be late, over > budget, and full of bugs. Time spent on your own debugging tools is > time saved! Gdb is a very last resort. > > Sincerely, > > David Smead > www.amplepower.com > www.amplepower.net > > > On Thu, 20 Sep 2007, Кобрин Олег wrote: > > > i've newer version of dll. > > and I can't use command-line gdb, because there is very large amount of > code > > to debug and very few time... > > > > 2007/9/20, Grant Edwards <[email protected]>: > >> > >> On 2007-09-20, Кобрин Олег <[email protected]> wrote: > >> > >>> is anybody here? .... > >> > >> Yes, but we use gdb from the command line. ;) > >> > >> I have used the DDD frontend with msp430-gdb, but not very often. > >> > >> -- > >> Grant Edwards grante Yow! I want another > >> at RE-WRITE on my > CEASAR > >> visi.com SALAD!! > >> > >> > >> > ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2005. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Mspgcc-users mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users > >> > >> > > > > > > -- > > _____________ > > Oleg V. Kobrin > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > -- _____________ Oleg V. Kobrin
