Diagnostics hardware
Moderators: David Barker, Jerry Messina
Diagnostics hardware
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.
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..
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: Diagnostics hardware
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?
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
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
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..
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: Diagnostics hardware
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.
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
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
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..
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: Diagnostics hardware
> 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.
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.
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Re: Diagnostics hardware
I would second that approach, if possible...
Re: Diagnostics hardware
I've thought about it, but that's about as far as i have gotten . 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
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..
Re: Diagnostics hardware
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
any thoughts?
Rich
Hmmm..
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: Diagnostics hardware
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
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
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
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..
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: Diagnostics hardware
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.
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
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 DMAJerry Messina wrote: ↑Sun Jun 21, 2020 3:08 pmIf 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.