Page 1 of 1

Diagnostics hardware

Posted: Fri Jun 19, 2020 11:54 am
by richardb
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.

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 1:07 pm
by Jerry Messina
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?

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 1:27 pm
by richardb
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

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 2:10 pm
by Jerry Messina
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.

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 3:01 pm
by richardb
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

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 5:03 pm
by Jerry Messina
> 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.

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 5:44 pm
by David Barker
I would second that approach, if possible...

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 5:53 pm
by richardb
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

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 7:48 pm
by richardb
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

Re: Diagnostics hardware

Posted: Fri Jun 19, 2020 10:41 pm
by Jerry Messina
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

Re: Diagnostics hardware

Posted: Sun Jun 21, 2020 11:43 am
by richardb
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

Re: Diagnostics hardware

Posted: Sun Jun 21, 2020 3:08 pm
by Jerry Messina
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.

Re: Diagnostics hardware

Posted: Sun Jun 21, 2020 7:08 pm
by octal
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:

Re: Diagnostics hardware

Posted: Fri Jul 17, 2020 5:38 am
by richardb
Thanks