Diagnostics hardware

Discuss PIC and electronic related things

Moderators: David Barker, Jerry Messina

Post Reply
richardb
Posts: 306
Joined: Tue Oct 03, 2006 8:54 pm

Diagnostics hardware

Post by richardb » Fri Jun 19, 2020 11:54 am

HI All i hope your all doing ok,

I have a question regarding debug/ diagnostics, i think i my have asked this before but here goes.


I quite often use the programming header pins to send diagnostics info to a terminal to see if there is a problem or while degugging, the main problem for me with this is speed as the program has to stop for maybe 2mS just to send one value.

has anyone else built any hardware to help debug like an spi or i2c to usb device or something else??

Any suggestions Would be welcomed


Rich.
Stay safe.
Hmmm..

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Diagnostics hardware

Post by Jerry Messina » Fri Jun 19, 2020 1:07 pm

Unless I want some sort of runtime log of events I use the ICSP debugger w/any of the pickits or ICD's.
That way there's pretty much no overhead in code size or time.

How are you sending stuff out the ICSP pins? Software UART? If so, what speed?

richardb
Posts: 306
Joined: Tue Oct 03, 2006 8:54 pm

Re: Diagnostics hardware

Post by richardb » Fri Jun 19, 2020 1:27 pm

HI Jerry,

Generally 56k baud for comm's or sometimes i will use an i2c display, there can often be corruption with suart if i'm using interrupts or i have to disable the interrupt while sending the rs232.

But mostly i'm talking about run time so that i can leave some diagnostics code in place, and perhaps a service engineer can plug in something to debug a problem. for example we have a product that has 3 pics in it, one for usb and general control and another that does simple motion control, there really is no time to send rs232.

Thanks


Rich
Hmmm..

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Diagnostics hardware

Post by Jerry Messina » Fri Jun 19, 2020 2:10 pm

Well, if you're sending date out a UART they you could always crank up the speed, but that depends on your pic, clock, etc.
Most of the PC USB-TTL uart interfaces I use w/pics work up to about 230K baud with no problems, and 460K if you're careful.

If you want to send stuff out using SPI or I2C, I think the big problem is finding a decent PC USB-to-whatever adapter that works well as a slave.
Most I've used are pretty good on the master side, but slave side not so much.

richardb
Posts: 306
Joined: Tue Oct 03, 2006 8:54 pm

Re: Diagnostics hardware

Post by richardb » Fri Jun 19, 2020 3:01 pm

thanks for the feedback.

I normally use the fastest pic i can because the projects are never power limited.

I might try and create something with an fpga/cpld , I'm not after sustaind performance just a shorter period of interruption.


Thanks Again

Richard
Hmmm..

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Diagnostics hardware

Post by Jerry Messina » Fri Jun 19, 2020 5:03 pm

> just a shorter period of interruption.

Have you thought about just making the transmitter interrupt driven?

Write your message to a buffer, enable the TX interrupt and let it send things out while you go about your business.

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: Diagnostics hardware

Post by David Barker » Fri Jun 19, 2020 5:44 pm

I would second that approach, if possible...

richardb
Posts: 306
Joined: Tue Oct 03, 2006 8:54 pm

Re: Diagnostics hardware

Post by richardb » Fri Jun 19, 2020 5:53 pm

I've thought about it, but that's about as far as i have gotten :D. having said that i never seem to have free hardware to do it, but maybe with more modern micro i could use pps.

I've been using the 18F47j53 more recently which may have pps, i know I've used it in the not to distant past in something .


Rich
Hmmm..

richardb
Posts: 306
Joined: Tue Oct 03, 2006 8:54 pm

Re: Diagnostics hardware

Post by richardb » Fri Jun 19, 2020 7:48 pm

I seem to remember someone has done this before but i cant seem to be able to find a reference to it in the forums.

any thoughts?

Rich
Hmmm..

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Diagnostics hardware

Post by Jerry Messina » Fri Jun 19, 2020 10:41 pm

The 47J53 does have PPS for UART2.

You can use the PPS Tool included with recent compiler updates to help set it up. You'll find a copy in the Tools\PPSTool folder

richardb
Posts: 306
Joined: Tue Oct 03, 2006 8:54 pm

Re: Diagnostics hardware

Post by richardb » Sun Jun 21, 2020 11:43 am

Thanks jerry, bizarrly the project i was working on had already had this done to it, so i was actually using hardware serial output on the programming header using the pps module you suggested.

I would just like to point out that id done most of the work for this a year agoand had forgotten about this, I'd done it because of itterrupt corruption.


so i might look into doing either interrupt buffered send or maybe a non blocking send routine.

I might ask a few tips about this later, but i assume checking ReadyToSend and sending the byte if ready only takes a few clock cycles?


Rich
Hmmm..

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: Diagnostics hardware

Post by Jerry Messina » Sun Jun 21, 2020 3:08 pm

If you setup the TX to be interrupt-driven you'll get an intr when the TXREG is ready to accept a char,
so about the only thing you need to check after loading the TXREG is if you're at the end of your transmit message,
and if you are then disable the TXIE until you 're ready to send the next message.

It's pretty quick, so it doesn't disrupt much at all.

User avatar
octal
Registered User
Registered User
Posts: 586
Joined: Thu Jan 11, 2007 12:49 pm
Location: Paris IDF
Contact:

Re: Diagnostics hardware

Post by octal » Sun Jun 21, 2020 7:08 pm

Jerry Messina wrote:
Sun Jun 21, 2020 3:08 pm
If you setup the TX to be interrupt-driven you'll get an intr when the TXREG is ready to accept a char,
so about the only thing you need to check after loading the TXREG is if you're at the end of your transmit message,
and if you are then disable the TXIE until you 're ready to send the next message.

It's pretty quick, so it doesn't disrupt much at all.
This is almost the only way to do it correctly unless frequent interrupts can disturb your productive code. If you can afford using a new PIC18F, you can do better (and easier) with DMA :wink:

richardb
Posts: 306
Joined: Tue Oct 03, 2006 8:54 pm

Re: Diagnostics hardware

Post by richardb » Fri Jul 17, 2020 5:38 am

Thanks
Hmmm..

Post Reply