How does everyone debug their code?

I'm just wondering how everyone else 'traps'/debugs to make sure their code is doing what's expected.

I come from the days, when using VMS DCL, it was possible to use a command 'set verify'....as the program ran through its routive it was possible to monitor it's progress. Now with a PIC being 'standalone' that's not possible initially - so how does everyone do it?

For example, with a simple ADC program, it's fairly easy to get an LED to light up if a certain conditon is met...but that's going to grow old very quickly, if you have to put in a routive & each & every time! (also it's not that flexible - for example what if the condition isn't met...why not, what went wrong etc)

Ideally, I'd like to see PIC output on my PC screen as the PIC program runs through it's program. Therefore I'm thinking hyperterm & getting my PIC to talk to the PC's COM port.

I therefore googled about a bit & found surprisingly little 'definitive' info. For example, some sites said that it's not necessary to changle the levels from TTL to RS232 (??) etc. Also decent readable PIC-> RS232 COM ports circuits seem a little thin on the ground (I bought a MAX232 chip a few months ago, but would now like to use it)

So this got me thinking...perhaps there's any easier way of debugging? (I've had a quick try with PIC emulatorw...perhaps I'm just getting a little old, but I might has well been reading the service manual for the Hubble Space telescope)

Is getting the PIC to talk to the PC the way to go?

I'm using a PIC16F690.

There is several way indeed. Some use Proteus, some MPLAB sim, some use Serial communication (and/or ICD like Pickit 2 or MicroCode ICD), or still some LEDs or a LCD.

What's the best method? Hard to tell, for me a blend mix of everything above (less Proteus as I don't trust it) do a really good job. And then, it really depend where I am in the development stage and how big the "bug" is.

An ICD tells you exactly what happen in your code in real life, and more, it give you ALL internal register status, down side, they're usually a bit slow.

HTH

Hi,

Steve is right ... ICD2 or 3 really are great tools, Consider Pickit too.

16F690 not supported for debug ???

FALSE !!! for 30 Euros at Farnell, you get the 16F690-ICD Debug adapter ...

µChip ref AC 162061.

Then just

1) plug
2) play
3) Enjoy ...

Alain

You're kidding!

In their wisdom the authors of PBP gave you a DEBUG command which can be directed out to any spare available PIC pin...

Add a penny Resistor and you're communicating with your PC.

Can it get any simpler?

Quote:

---

Originally Posted by Melanie

You're kidding!

In their wisdom the authors of PBP gave you a DEBUG command which can be directed out to any spare available PIC pin...

Add a penny Resistor and you're communicating with your PC.

Can it get any simpler?

---

This sounds *just* the job...have you some linkage I can consume please?

The linkage is to your PBP Manual... use the really complex schematic provided in the DEBUG section.

Quote:

---

Originally Posted by Melanie

The linkage is to your PBP Manual... use the really complex schematic provided in the DEBUG section.

---

Whoop...there it is! (with a whopping one component count)

Can someone talk me through the circuit? (just kiddin')

I'm so excited, I'm actually thinking** about getting a round in.

Many thanks,
Hank.

** ....I've now thought about it - maybe next time!

Hank, it sounds like something similiar to what I have been working on as well with regards to working with an ADC in value. I've been using a serial connection to my 16F877/16F877A. Just like you at first I had a little LED turn on with my ADC value coming in from a pressure transducer. I set it up to turn on portc.0 at 1 psi then portc.1 at 3 psi etc... Like you said that just confirmed it worked. The real work was in taking the value and converting them to a PSI value. I got some great help with that calculation and ported my actual PSI to the serial port so I could see the actual value. I had a tone of SEROUT2 commands dumping everything to a hypertermial session.

I have the schematic for the connection with the max232 rs232 chip if you need it.

David

If you have PICKIT there's no need for any RS232 level shifter, no resistor either... use the USART tool.

If you're a bit clever, you'll design your thingy to accept ICSP. And then you can also use those ICSP line for Debug with PICKIT.

That's an handy tool for less than 50$.

I uses ISIS. It simulates the code right on the computer, complete with SPICE for the electrical schematic. With PBP, I've got to watch the compiler asm output, but I can see all of the variables change and i/o pins as fast as I want, with breakpoints. When I use Proton+, I get to step through the basic code, one basic line at a time. It even gives me the option to see the assembled code between each basic line, and step through that, too.

Well, I've after two solid nights battling to get my PIC 16F690 to talk to the outside world...I've got it working :o

I decided I really did want some form of serout command (that I could call on demand), therefore last night I messed about with a MAX232 for a couple of hours....no success (I now realise that this was becuase I was feeding the MAX232 just 3V...sourced from the PICKIT2 VCC - it needs 5V - doh! Thanks to DavyJones for emailing me the schematics)

Anyway, the post that mister_e madecaught my attention - & I've ended up going that route. I now have PIC program going outputing to the UART window (within the PICKIT app - altough it's a little clunky if you ask me). I 've actually pimped my PICKIT2 board by soldering on a little switch which allows me to quickly switch between the PICKIT as a 'programming device' & the PICKIT 2 as a 'serial interface device' ....so no need to change the PICKIT2 edge connector now :-)

Anyway, I'm on the final straight...my query now relates to Terminal Window formatting (or rather whatever it takes to get the PICKIT 2 UART window to clear down!)

Can anyone outline (in simple terms), how I can send simple 'clear screen', line feed commands etc using the HSEROUT command?

here's a little of my code (you've not to laugh!)

ADCIN 0, DC_Level_IN ; Read the DC level on RA0 (pin 19)
HSEROUT ["ADCIN Value = ", DEC DC_Level_IN]

The problem with the above method is it's very hard on the eyes, as ithe data progresses across the screen left to right. Ideally I'd like each update to appear on a new line (or even just totally clearing the screen before the data is updated each time)

Many thanks in anticipation.

Hank.

Quote:

---

Originally Posted by HankMcSpank

ADCIN 0, DC_Level_IN ; Read the DC level on RA0 (pin 19)
HSEROUT ["ADCIN Value = ", DEC DC_Level_IN]

The problem with the above method is it's very hard on the eyes, as ithe data progresses across the screen left to right. Ideally I'd like each update to appear on a new line (or even just totally clearing the screen before the data is updated each time)

Many thanks in anticipation.

Hank.

---

Try:
[code]
HSEROUT [254,1,"ADCIN Value = ", DEC DC_Level_IN]
[code]

Quote:

---

Originally Posted by HankMcSpank

ADCIN 0, DC_Level_IN ; Read the DC level on RA0 (pin 19)
HSEROUT ["ADCIN Value = ", DEC DC_Level_IN]

The problem with the above method is it's very hard on the eyes, as ithe data progresses across the screen left to right. Ideally I'd like each update to appear on a new line (or even just totally clearing the screen before the data is updated each time)

Many thanks in anticipation.

Hank.

---

Try:

Code:

---

HSEROUT [254,1,"ADCIN Value =  ", DEC DC_Level_IN]

---

Damn, need the edit feature back . .

Thanks for trying to help me out Joe, but it didn't solve my problem...

http://img245.imageshack.us/img245/4628/tempi.th.jpg

(though I'm seeing lots of little rectangles after the data onscreen now - perhaps such unexpected results is a quirk of Microchips' UART tool window?)

This works intermittedly...

HSEROUT [10,13," Increase Gain, ADCIN Value = ", DEC DC_Level_IN]

...about 4 times out of 10, I get a new line!

I've tried changing the baud

DEFINE HSER_BAUD 2400

...but I just get garbage when i do (yes, I'm changing the setting in the UART window too!). therefore I'm thinking this might the general flakiness of the internal oscillator &/or the quirkiness of the Microchip UART window?

Quote:

---

Originally Posted by HankMcSpank

Thanks for trying to help me out Joe, but it didn't solve my problem...

(though I'm seeing lots of little rectangles after the data onscreen now - perhaps such unexpected results is a quirk of Microchips' UART tool window?)

---

I misread your post, I thought you were sending to a serial LCD.

Quote:

---

Originally Posted by HankMcSpank

This works intermittedly...

HSEROUT [10,13," Increase Gain, ADCIN Value = ", DEC DC_Level_IN]

...about 4 times out of 10, I get a new line!

I've tried changing the baud

DEFINE HSER_BAUD 2400

...but I just get garbage when i do (yes, I'm changing the setting in the UART window too!). therefore I'm thinking this might the general flakiness of the internal oscillator &/or the quirkiness of the Microchip UART window?

---

Have you tried sending 2 separate lines, 1 to clear or give a newline and the second with your data? I would put a little pause in between too. You might research CHAR_PACING too

In this order.
hserout [whatever data, 13,10]

this will work all the time as long as you have sufficient delay between all your HSEROUT, and as long as your baudrate is accurate.

What you want is a ANSI terminal, those who accept ESC character, like the boring Hyperterminal, TeraTerm, RealTerm to name only but those. With an ANSI terminal, you can clear the screen, change font color, background color etc etc etc ( see http://www.pbpgroup.com/modules/wfse...hp?articleid=9 for reference)

Unfortunately, PICKIT USART tool is not an ANSI one, so you have to deal with the pain or work around. If you're a bit familiar with Microsoft C#, you could modify Pickit USART tool (as it is open source anyways) to accept ESC characters, or to clear the screen when you receive, let's say, ASCII 225 or whatever else. That should be easy.
<hr>
I'll redo my explanation about USART tool debugging...

Unless your current hardware don't use Serial communication, there's no need to use a switch, no need for HSEROUT either. What you do is to sit your PICKIT on the regular programming pins (MCLR, PGD, PGC) all the time, then you use DEBUG/SEROUT/SEROUT2 on PGD I/O. For this you must use TRUE mode.

Clear enough now?

I may try to post an example before going to sleep.

Here's a quickie example.

Note: I cut the trace from the pot to RA0 on my board, soldered a wire to the pot output
circuit so I can connect the output from the pot to other A/D input pins.

This leaves RA0 free for serial debugging with the PICKit2 USART tool.

Code:

---

@ device pic16F690, intrc_osc_noclkout, bod_off, wdt_off, mclr_off, protect_off

DEFINE OSC 4

DEFINE DEBUG_REG PORTA
DEFINE DEBUG_BIT 0      ' RA0 = TX out to PICKit2 programmer USART tool
DEFINE DEBUG_BAUD 9600
DEFINE DEBUG_MODE 0    ' 1 = inverted, 0 = true

DEFINE        ADC_BITS 10    ' Set number of bits in result
DEFINE        ADC_CLOCK 1    ' Set clock source Fosc/8 "2uS"
DEFINE        ADC_SAMPLEUS 50 ' Set sampling time in uS

Q CON 1251              ' For 10-bit A/D +Vref = 5V : 5V/1023*256=1.251=Quanta
ADval VAR WORD
Result VAR WORD

OSCCON = %01100000      ' 4MHz internal osc 
ANSEL = %00000100      ' RA2 = A/D in, rest digital
ANSELH = 0
ADCON0 = %10001001      ' Right justify, channel AN2, A/D enabled
CM1CON0 = 0
CM2CON0 = 0

PORTA = %00000001      ' serial out pin idles high
TRISA = %00000100      ' RA2 in, rest out

Main:
  ADCIN 2,ADval
  Result = ADval */ Q
  DEBUG "Raw = ",DEC ADval," Real = ",DEC Result DIG 3,".",DEC3 Result," V",13,10
  PAUSE 500
  GOTO Main

  end

---

Quote:

---

Originally Posted by mister_e

In this order.

Unless your current hardware don't use Serial communication, there's no need to use a switch, no need for HSEROUT either. What you do is to sit your PICKIT on the regular programming pins (MCLR, PGD, PGC) all the time, then you use DEBUG/SEROUT/SEROUT2 on PGD I/O. For this you must use TRUE mode.

Clear enough now?

I may try to post an example before going to sleep.

---

I'm hearing what your saying, but without an example to follow, I'm still left wondering how this is achieved.

To set out my stall again - programming is new to me - I'm more of an old analogue electronics type. I can relate to a switch! I took one look a the PICKIT2 UART Tool connectivity diagram....

http://img13.imageshack.us/img13/3848/pickit2.gif


& one look at the PICKIT2 schematic...

http://img13.imageshack.us/img13/6494/boardhjo.jpg

& saw that it only needed two pins switched...then I can simply go between programming mode & UART tool mode with the flick of a switch. In the absence of anything else meaningful 9to me at least), I followed up that path.

I can't believe just how much of a struggle it is for a newbie to get a 16F690 (probably the chip most newbies are exposed to as it comes with the PICKIT2) to do somethign as bland as send some stuff over a serial connection! (I don't mean about the h/w aspect, I mean getting the correct 'include' files & config, the register settings, the quirks about baud rates when using internal oscillators (as most newbies do)...then there's the h/w aspect .....what a lot of work!

ok,et away with... I've got it working - it did indeed need separate lines with pauses inbetween. This seems to be the least i can get away with...

ADCIN 0, DC_Level_IN ; Read the DC level as presented on RA0 (pin 19)
pause 30
HSEROUT [10]
pause 30
HSEROUT [13]
pause 30
HSEROUT [" Waiting for Threshold, DC Value In = ", DEC DC_Level_IN]

many thanks to all who took the time to help - it really was appreciated.



For the record, anyone finding this thread that's a newbie like me who wants their PICKIT2 board with an onboard PIC 16F690 to send serial data with the HSEROUT command, here's what I did (& to all you old hands, I'm sure there's a lot of stuff in here that ain't optimum - but it works for me!)...


@MyConfig = _XT_OSC & _WDT_ON & _MCLRE_ON & _CP_OFF
@MyConfig = MyConfig & _MCLRE_ON & _BOR_OFF
@ __config MyConfig

Include "modedefs.bas"

DEFINE OSC 4 ; sets the internal oscillator to 4MHZ (best for HSEROUT)

ANSELH=0
ANSEL=0
VRCON = %00000000 ' turns the Vref Module OFF by CLEARING bit7, 6, 4
CM1CON0 =0
CM2CON0 =0
CM2CON1 =0
ADCON0.0 = 1 ' turns the AD Converter OFF by CLEARING bit0
INTCON.0 = 0 ' clears the RABIF Flag (to 0), COULD be 1 on reset (unique to F690)
TRISB.6 = 1 ' some s*** to do with serout that I don't fully understand!
TRISB.7 = 1 ' more s*** to do with serout that I also don't fully understand!

'serial Port stuff...
rcsta.7=1 'SPEN serial port enable bit
define HSER_RCSTA 90h
define HSER_TXSTA 24h
'DEFINE HSER_SPBRG 92
DEFINE HSER_BAUD 2400 ;Set baud rate
DEFINE HSER_CLROERR 1
txsta.7=1 'CSRC : Clock Source Select bit 1 = internal clock
txsta.6=0 'TX9 : 9-bit Transmit Enable bit 0 = 8 bit.
txsta.5=1 'TXEN : Transmit Enable bit
txsta.4=0 'SYNC : USART Mode Select bit 0=asynch
txsta.3=0 ' N/A
txsta.2=1 'BRGH : High Baud Rate Select bit
txsta.1=0 'TRMT : Transmit Shift Register Status bit ( Read only )
txsta.0=0 'TX9D : 9th bit of transmit data. Can be parity bit.


TRISA=%11111111 ; set all Port A pins as inputs
TRISB=%00000000 ; set all Port B pins as OUTPUTS
TRISC=%00000000 ; set all Port C pins as OUTPUTS
PORTA = %00000000 ' Clear the port register latches
PORTB = %00000000
PORTC = %00000000

OK, try another variant. Use your second schematic, and use the code provided by Bruce few post above.

DEBUG is a software alternative to HSEROUT. DEBUG (like SEROUT & SEROUT2), allow you to use almost any I/O of your PIC. This avoid to use switches if your current design don't use those PGD/PGC pins (RA0 and RA1)... also called ICSPDATA and ICSPCLK on your schematic.

Don't give up!

Quote:

---

Originally Posted by mister_e

OK, try another variant. Use your second schematic, and use the code provided by Bruce few post above.

DEBUG is a software alternative to HSEROUT. DEBUG (like SEROUT & SEROUT2), allow you to use almost any I/O of your PIC. This avoid to use switches if your current design don't use those PGD/PGC pins (RA0 and RA1)... also called ICSPDATA and ICSPCLK on your schematic.

Don't give up!

---

Thanks for the encourgaement!

Well, I revisited what Bruce posted up ....& what do you know - it worked!

I then decided to incorporate Bruce's code into my own program - mucho grief ensued. However, if I'd taken a bit more care & actually slowly read your bit that I've bolded above, I'd not have lost two hours of my life! (I too cut the variable resistor wiper on the PICKIT2 board...but, alas, I soldered it onto pin RA1). Why isn't is a good idea to use RA1 for AtoD?


Anyway, once I saw what you said, I resoldered the VR wiper onto RA2....everything turned out sweet (& no hardware switches either - that said, I reckon it wasn't totally wasted time, as I want to get some 'serial in' going down on a couple of my programettes soon)


Many thanks to all!


Hanks

Just a little footnote...the debug command creates delay, which is significant in my PIC program.

Basically, I have a coil winder program (the PIC counts pulses from magnets mounted on a spinning motor & then the PIC pulses out to a stepper which turns a helix (this feeds copper onto the main turning motor - a bit like this from 20secs in http://www.youtube.com/watch?v=Q_Cd_...rom=PL&index=6)

Anyway, without any debug in my code...I get a nice neat wind of copper. But as soon as I use debug...the helix feeding copper wire onto the main turning motor, doesn't keep up ...end result is a lumpy wound coil - as soon as I take out the debug command...it runs fine again.

This is a real downer, because I was using my new found 'Debug' method to put out important info onscreen (No of turns, number of steps until traversal changes direction etc).

What are my options here?

(I'm trying to avoid having to build a logic circuit to keep track of the PIC output pulses using hardware counters!)

Few different ways, first one being to use an higher baudrate and reduce the Pause delay.

Hard to tell more, without having the whole code here.

Hi everyone,

I'm using the pic basic pro demo to learn how to program microcontrolers for a class. I using a Microchip book that tells me how to program the pic16f628A. This is the program the book suggests for a Monostable Oscilator:

HIGH PortB.0
Pause 5000
low PortB.0

end

After I compile the program I get this error message:
fatal c:\pbpdemo\inc\m16f62xa.inc 7: [307] Illegal DEVICE type:confused:

I already tried to use other pics but I get the same error related to their own .inc file. Can anyone please tell me what is wrong or what the error means?

Thanks,
Jorge

Are you using MPLAB or MicroCodeStudio ?

Just some footnotes on this (as one newbie to others who may find this thread via google etc).

If you have a PICKIT2 programmer... you can use it to connect your PIC to your PC (no need to buy MAX232 interfacing chips etc). The Uart tool, is in your pickit2 programmer menu under tools.

To get text/info out of your PIC & onto your PC using the UArt tool, well, as far as I can gather you have two options...

1, The DEBUG command - from my understanding this uses software to get the data out your PIC & onto your PC screen via the Pickit2 Uart tool ...the benefit being it's simple to set up, but don't go this route if you venture into 'interupt' territory else you'll end up with all manner of garble onscreen. Take a look at Bruce's answer to my post further up for sample code that works well.

2. The HSerout command - this uses hardware in my opinion a much better route. Programming wise, it's not really anymore difficult to set up & you shouldn't have problems with interrupts messing with your text. Alas, the downside of using this method with your Pickit2 is that you'll need to wire a switch into your circuit (take a look at the diagram I posted further up to see what I mean)

If you happen to have a 16f690, then the code below will get you started (I haven't commented each line because, truthfully I haven't got much idea what they all do - but I do know that this code works in setting up HSEROUT with a 16F690!)...

@MyConfig = _XT_OSC & _WDT_ON & _MCLRE_ON & _CP_OFF
@MyConfig = MyConfig & _MCLRE_ON & _BOR_OFF
@ __config MyConfig

Include "modedefs.bas"

DEFINE OSC 4
' the following three lines set the serial port up as 9600 working with the 4Mhz oscillator freq above
DEFINE HSER_SPBRG 25
DEFINE HSER_TXSTA 24h
DEFINE HSER_CLROERR 1
ANSELH=0
ANSEL=0
CM1CON0 =0
CM2CON0 =0
CM2CON1 =0
adcon1=0
TRISB.6 = 1
TRISB.7 = 0
TRISC=%00000000 ; set all Port C pins as outputs
rcsta.7=1 'SPEN serial port enable bit
low Portc.1
low Portc.2
low Portc.3

txsta.7=1 'CSRC : Clock Source Select bit 1 = internal clock
txsta.6=0 'TX9 : 9-bit Transmit Enable bit 0 = 8 bit.
txsta.5=1 'TXEN : Transmit Enable bit
txsta.4=0 'SYNC : USART Mode Select bit 0=asynch
txsta.3=0 ' N/A
txsta.2=1 'BRGH : High Baud Rate Select bit
txsta.1=0 'TRMT : Transmit Shift Register Status bit ( Read only )
txsta.0=0 'TX9D : 9th bit of transmit data. Can be parity bit.

loop:
hserout ["Hello ", 13, 10]
pause 400
goto loop
end

(the ISCP connector header that the PIC mates with, needs a switch to 'break' Header pin 4 of from PIC pin 19 to pin 10 & Header pin 5 from PIC pin 18 to 12 - flick the switch to go from 'programming mode' to HSEROUT mode)

Hi,

Yesterday I hooked up a 16F676 with the PICKIT2 as I always do. Debug didn't work!! Only garbage on the PICKIT2 UART window.

After hours and hours of struggle I realized, I didn't include the OSCAL Define.

FIY : 19200 bps works fine with internal 4 MHz

Code:

---

        DEFINE OSCCAL_1K 1              ' MUST INCLUDE
        DEFINE OSC 4                        ' USES INTERNAL 4 MHz OSCILLATOR
        DEFINE DEBUG_REG PORTA        ' PORTA.2 IS PGD/AND Rx AS WELL
        DEFINE DEBUG_BIT 0                ' PICKIT2 Rx (Pin 4)
        DEFINE DEBUG_BAUD 19200      ' Max Baud on Internal Osc ???
        DEFINE DEBUG_MODE 0            ' True

---

BTW, PICKIT2 can Regenerate OSCAL through the same ICSP pins. Find it under the tools menu.

Hi there,

For most of my debugging, I use the PIC-Simulator from OSHONSOFT.

I can track variables and/or any other info I need, emulate an LCD display, set port states and AD values and lots more.

Most of the time, I don't even have to build a proto on the breadboard and it is really time-saving.

IMHO, it is worth the few € it costs and can be an alternative to "hardware" debugging tools.

http://www.oshonsoft.com/pic.html