serial transmit data truncation 16F18855

[temtronic]

Since you are using Delphi, have it display the incoming data from the PIC.
Like Mr. T, I suspect your unnamed 'monitoring software' is buggy.....

[dDelage]

[temtronic]

Well I'm confused, I was under the impression that you wrote the PC side,using Delphi, but you mention an 'app logging data to a file' ?
So ,to clarify,are you using software someone else wrote ?

[dDelage]

[temtronic]

OK, to test the PIC... use 'RealTerm'. It will allow you to send/receive/ log data to/from the PIC..no need for the Delphi 'app'.

I used it a lot for several greenhouse projects,made it easy to log time/temperature data(I sent in CSV format) every second for testing, every minute in real use.

as for the current Delphi app, do you have the original source code ?

I used Delphi for a custom keyboard tester. Keyboard had 163 keys, sent ASCII via RS232( yeah REAL RS232...) so press a key on kbd, display on PC screen, send 'commands' to kbd to turn on/off the LEDs. Nice thing about Delphi was it would work on any PC as a stand alone program.

[dDelage]

I downloaded & installed RealTerm, and the truncation is gone. whew!

But, as Clippy once told me, "Problems that go away by themselves can come back by themselves." I wanted to find the reason that the string was truncated at 100 characters. I found a spot in the Delphi app that copies the first 100 characters of the serial data variable and puts the result back into that variable. Problem solved from the Delphi side, but I really wonder how that Serial Port Monitor software showed the same 100 chars. I'm guessing it somehow got a pointer to that memory location, and when the string changed in the Delphi app, it also changed in the Serial Port Monitor app. I didn't think that kind of thing was possible since Windows 95, but who knows?

I also still wonder why the first printf() from my test code gets sent as one serial message, but all subsequent printf()s get mashed into a second serial message. Even if I put a delay statement after the second printf(), it and all the rest go as a single message.

However, I think I need to leave that in the past. This is all for debugging a change to my serial ISR, and none of these printf()s will be used in the real app & firmware.

This could be implied from the text I just wrote, but for clarity I'll directly answer your question. Yes, I do have the Delphi app source code.

Question about RealTerm: at some point I will need to inspect serial data between the Delphi app and the PIC. Does RealTerm let me do that? and if so, how?

Thanks!

[dDelage]

[Ttelmah]

There is an explanation of the fuses with the compiler. Look for fuses.txt

You were handling the string incorrectly in two ways. The first is that
=, does not 'copy' a string. It will load the pointer on the left with the
contents of the pointer on the right. To 'copy' you have to use strcpy
or memcpy. The second though is fundamental to the PIC. Because the
PIC uses the Harvard processor architecture, it has two separate memory
'spaces'. The ROM and the RAM. On standard chips these are all in one
large area of memory, but on the PIC they are separate. Problem then
is that if you have a constant string "Hello", this is in the ROM, not the
RAM. The PASS_STRINGS option makes the compiler automatically
'virtualise' references to constant strings, as if they were in the RAM.
Allows you to have pointers to these.
Do a search here you will find a lot of threads about the implications
of the architecture.

The NOPPS1WAY, allows the PPS settings to be changed more than once.
I noted the assembler on your chip did seem to be changing it twice,
so this may be needed.

The internal oscillator _is_ and RC oscillator.

The timer options set quite a few other bits in other registers. These
are coded as other bits in the defined values.

[temtronic]

re: Realterm
yes, you can have Realterm do a 'split screen' where everything going TO the PIC is displayed as well as everything coming FROM the PIC.
you can also send a precoded line of text or a file TO the PIC. It should show what the Delphi ap sends. I assume it captures the UART data ? Others may know how it works, I was just happy it did exactly what I needed it to !
Realterm has a zillion features,so there is a learning curve BUT is was always 'stable'
Hint: If you want to capture the incoming data to a file, put that file ON THE DESKTOP ! makes it a lot easier to find......

[dDelage]

[Ttelmah]

Lest start with the = for a string. Point is that on a normal 'PC' system, what
this results in is a lot of wasted space. Your declaration of the data array
is wasted!....

Understand, you declare this: "some text". On the PIC, this results in
the characters for 'some text" being stored in ROM. On the PC this
results in a RAM array being created, holding this text.
Now you then declare:
char data[32];

and later say:

data="some text".

What happens at this point is that the 32 character array in RAM, is
effectively 'lost'. Still there, but 'data' no longer points to it. Instead
it now points to the "some text" array held elsewhere in RAM. You have
just thrown away 32 byte of memory!...

If instead you declared

char * data;

'data' would now be a pointer, and when you did

data="some text", this pointer would now point at the 'some text' array.

So what you are doing, 'works' on a PC, but is incorrect programming. In
C (it is supported in C++).

No, you don't need the PASS_STRINGS line, but it makes string in the
PIC behave in a perceptually similar way to the way they would work
on a Von Neumann machine.

Yes, RC stands for resistor capacitor. One of the simplest oscillators to
make, and about the only one that is easy to build internally in a chip.
On the PIC all the internal oscillators are RC oscillators, but they are tuned
at the end of manufacture to make their accuracies 'reasonable'.

Key on all the 'what do things mean' is the data sheet. If you look the
top bit of the four bits selecting the prescaler is actually the bit to turn
the timer 'on'. So the '0x80' is saying 000 to the prescaler bits (=/1), and
turn the timer on. Selecting the clock on it's own, does not turn on the
timer. So it won't work. It may however be that the compiler will
automatically turn on the enable bit (I'd gave to look at the assembler
to see).