Real time data monitor/control for PIC16 micros

[mazurov]

All,

I just finished first working alpha of RTDM protocol implementation for PIC16 MCUs - very useful when debugging/tuning real time code  and previously only available for dsPIC and friends. All relevant info here -> https://www.circuitsathome.com/mcu/using-data-monitor-and-control-interface-with-pic16-mcu-2

Enjoy!

/felis

[dannyf]

Some suggestions:

1) this isn't new. There are a number of such implementations floating around.
2) low-end PICs are not the best place to implement this, due to their lack of a vectored interrupt controller. I would think about AVR for this.
3) You may think about the use of a frame and a mechanism to reset a frame transmission. This allows you to sustain transmission over a long period of time.
4) within each frame, you may think about transmission of several data items (4-8 for example). A frame can be either of fixed length for simplicity or variable length for efficiency.
5) on the host end, offer both a graphic interface AND a text interface.
6) I would split the crc routines out in case a user wants to hook in a his/her own encryption / error correction routines.

The space on a PIC16 will be the limiting factor for something like this.

[dannyf]

BTW, if you implement the host on a device with a screen (a smartphone), you essentially have a (low speed) scope.

[mazurov]

Some suggestions:

1) this isn't new. There are a number of such implementations floating around.

You have links? I wrote mine mainly because I was unable to find an implementation

2) low-end PICs are not the best place to implement this, due to their lack of a vectored interrupt controller. I would think about AVR for this.

AVR (Atmega) is too slow for this. Besides, the protocol is implemented specifically for the tool available only in MC-specific IDE so any AVR vs. PIC discussion is not going to last very long. There is an implementation for dsPICs which even allows DMA transfers at runtime.

{quote]

5) on the host end, offer both a graphic interface AND a text interface.

[/quote]

The host end is developed by different people, I'm just using it. The protocol (also developed by different ppl) is very lightweight, you only transfer a memory address, number of bytes and direction to the target and you get raw data back.

The space on a PIC16 will be the limiting factor for something like this.

I noticed that.

[mazurov]

BTW, if you implement the host on a device with a screen (a smartphone), you essentially have a (low speed) scope.

Once again, I'm not doing the host piece but merely extending the functionality of the existing one.