com buffer problem

[SvenTec]

Hi all,

I got a little problem which I don´t understand. I hope someone here could help me with it.

This my code:

#platform "GOLDELOX-GFX2"

#inherit "4DGL_16bitColours.fnc"

//var buffer[68]; // doesn´t work when declared here !!

func main()

var buffer[68]; // works OK here !!

setbaud(BAUD_9600); // set baud rate

com_Init(buffer, 136, 0); // set buffer size

gfx_MoveTo(0, 40);
print ("rx bytes :");

repeat

com_Init(buffer, 136, 0); // reset buffer

serout(0xff); // request data

pause(1000); // wait

gfx_MoveTo(70, 40);
print (com_Count()); // display rx byte count

forever

endfunc

It send FFhex out the serial port, waits 1 sec. and displays the amount of bytes received.
When the buffer is defined inside the main function it works ok, when outside it doesn´t work
and I can´t figure out why.

Thanks for your help.

Sven

[ESPsupport]

Seems to work fine for me.

Which PmmC version are you using?

What do you mean by doesn't work?

[SvenTec]

Hi,

thanks for the quick reply. The PmmC Version is v2.2.

I just tested it again. When the buffer array is defined

inside the main function the program nicely displays

the amount of received bytes, when placed outside it

only displays zero.

Regards,

Sven

[ESPsupport]

That's the same version I tried with

What is the actual display you are using?

Also, what is the compiler version (double click on C:\Program Files\4D Labs\4D Workshop 3 IDE\DEP\4dcompiler.exe )

[SvenTec]

Hi,

the display is uOLED128-G1h and the compiler version is 2.6.0.5.

Sven

[ESPsupport]

I've tried using the same display and compiler version and still no issues.

Are you, perhaps, interpreting the slight bug in your code as an error (although it will behave the same both ways)?

Change the applicable line to

print (com_Count()," "); // display rx byte count, blanking out any leftovers

[SvenTec]

Hi,

I was testing around a bit yesterday. That program will receive 135 byte of serial data later and because the Workshop Terminal only seems to handle 128 byte I was using some serial port monitor software called HTerm 0.8.1beta.

The program works fine no matter where the buffer is defined with Terminal9600 but using the HTerm and sending the whole string of 135 bytes it only works when the buffer is defined inside the main function. When defined outside the function it keeps working up to 130 send bytes. I don´t get that. In or outside the function should not make any difference to the terminal software???

I think I need to test with another terminal software, is there any free one you could recommend?

Maybe if you like you could try out with the Hterm as well and confirm?

Thanks so far,

Best regards,

Sven

[ESPsupport]

Note sure why you say Workshop terminal only supports 128 bytes, the way I get it to send large amounts of data in 'one hit' is to have the data in the copy/paste buffer and paste it, that seems to paste any amount of data I'm willing to try.

Anyway back to your problem.

We need to define it better...

"If the capacity of a comms buffer is exceeded, when the buffer is defined inside the main function it works ok, when outside it doesn´t work"

It is unclear why you are specifing a 136 byte buffer size (over 25% of Goldeloxes total memory), or why you are trying to blow it.

With further testing I find that it works correctly for a 132 byte buffer size and fails with a larger size.

We will investigate further, thanks for the report

[meldavia]

Hi Sven,

Thanks for your report.
After running some tests using your code it became evident what the problem is.
Goldelox comms buffer is limited to 127 characters.
Although it appears to work properly if the buffer is in the main function you will find
that there is a buffer wrap problem, and a potential to corrupt other local variables,
and possibly the stack.

Limit your buffer size to 64 words, and alter the max size to com_Init(buffer, 127, 0);
and all should be ok. (it would still be possible to use a lead-in character to make the
total packet size 128 as the lead-in char is not buffered)

It is much better to have the buffer as a global due to stack limitations, besides, a local
array in main just hogs the buffer anyway as main never release its locals.
It may be possible to put your buffered comms in another fuction called by main,
in which case the buffer can be initialized etc, and only recieve when you send the 0xFF
- and the buffer would be released when the function returns, freeing up the stack space.

We will make mention of the buffer limitation in the next release of the manual.

[SvenTec]

Hi,

thanks for the reply, at least we know the cause now.

So with the buffer being limited there is no way to receive the full 135 bytes, right?

I could cut some preamble bytes off and use a qualifier but then a checksum calculation
on the full string to insure data integrity isn´t possible anymore.

I have to think about it a bit.

Regards,

Sven

[meldavia]

Yes 135 bytes not possible.

May I suggest a small header sent first, and in that header there is a byte
that indicates the 'number of data packets to follow', and make the data
packet size 64bytes.

[steve4690]

:-( Serial comms was a bit flaky when I was last actively posting in '09(ish. before I started by house build.) Buffer handling was a bit... buggy (sorry!)

Looking forward to having a bit of time to have a play again. I've missed the 4D world.

Steve

[Atilla]

Good to have you back Steve . Try the new Workshop4 IDE with 4 new development environments, huge improvement from our old IDE.

Regards,