Data Streaming

[virusx2]

Hi everyone,
Have anyone used the Data Streaming future with ICD-U64 and CCS IDE or mplab x? I am about to buy the ICD-U64 and i was wondering if the data streaming feature works with no errors.

[virusx2]

Anyone..???

[Ttelmah]

For myself, the reason to use a comm port for debugging, is to allow the chip to run in 'real' mode, without the ICD connected, so the idea of using the ICD for this seems pointless...

[virusx2]

So you suggest me to use rs communication for debugging..?

[temtronic]

'debugging' means different things to different programmers.

Some use the ICD or IDE to test,others try a 'simulator', most will use an LED or comport.

It generally depends on the complexity of the code and the overall performance. Sometimes a simple test LED to confirm 'this section works' is fine. The PC POST cards did this.

If you need to confirm real data from sensors, math functions, etc. then a comport tied to a PC is simple,cheap,fast and reliable.

'Data streaming' means nothing to me. Heck, this reply is 'data streaming'. Without some idea of what your 'data ' is, 'streaming' is ambiguous. Are you talking about a few bytes over hours or kilobytes of data per second?

Jay

[Douglas Kennedy]

The ICD U64 with the IDE performs several functions.
A) it will program a PIC ( aka release mode)
B) it will support debugging with real input ( say from a sensor) the simulator in MPLAB is cumbersome since sensor data has to be predefined to simulate, The debugger allows for break points and mouse over display of variables. Watch windows register dumps etc.
C) a monitor screen can display via the ICD U64 any thing sent via a debugger stream. #use rs232( debugger) it defaults often to pin B3 and allows data to flow via printf or getc both to and from the monitor screen.
It gives a trace capability to the monitor.
D) the debugger in the IDE takes up space so rarely the need may be to trace in the actual release environment. The release environment can be powered by the ICD-U64 and the release traced via the debugger stream without the debugger code ( mouse over, break, watch etc) being loaded.
The ICD-U64 for me is good value.

[Ttelmah]

The 'streaming' function of the ICD, allows you to use the ICD connections as a virtual com port.
The problem is that sometimes having the ICD plugged in, makes things behave differently.
This is why I prefer the 'real' port....

[Douglas Kennedy]

There is often several good ways to do things.

The real uart port has advantages but if it is just to debug in the release environment it takes up a the uart 2 pins for I/O. Now the ICD stream is a software uart by default so it doesn't steal a real uart port just one pin ( B3) for I/O.

I don't see the release ICD stream as being used for anything other than debugging since it needs the ICD-64 connection and again only rarely since debugging is going to always be in the development environment.