Length limitation for strings : to the developpers ...: Resolved

[Bertrand BAROTH]

(Yes, I know, I am annoying ... :) )
In the help I read : 40 bytes for devices with more RAM than 367 bytes ; this value seems ridiculous if You take a glance at for example an ATMega1284 with 16K Bytes of RAM. So, could it be possible to add one or more "brackets" for this length, if such VERY BIG processors are used ?
Thanks for any answer !

[Anobium]

A string is an array of bytes, so, in theory, strings can be very big. But, the string hanlders may break, like printing a string... the method may assume a max of 256 (a byte length).

We also improved the string length handling - I will need to check with Hugh if any constraints were changed.

From my own experience.. I have used string larger then 40 bytes - have you tried?

[Bertrand BAROTH]

Unfortunately yes, I did, so I found the issue ... I sent a string constant of more than 40 chars via HSerPrint from my 8515 to the Emic-2 ("Train Number ... will depart .... "), the speech ended after about 40 characters and began again ! Unfortunately the test was not significant, with 512 bytes of RAM. So I wonder if using a "bigger" processor (which I must order first ! ) would solve the problem.

[Anobium]

To this. Simply write your own code to HserPrint each character. Treat the string as an array. The first element should have the string length.

for myHandler = 1 to stringName[0]
HserPrint stringName[myHandler]
next

[Anobium]

Edited. Both methods work on the mega328p.

Working code to show a solution. The HSerPrint myString handles the chars correctly, then second method shows all 160 chars.

~~~
'Chip Settings.
#chip mega328p, 16
#option explicit

'USART settings

#define USART_BAUD_RATE 9600
#define USART_TX_BLOCKING

dim myString as string * 255
dim myHandler as word

myString = "0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"

HSerPrint "Start:"
wait 1 s
HSerPrintCRLF 2
HSerPrint myString
HSerPrintCRLF 2
HSerPrint "Next:"
HSerPrintCRLF 2

for myHandler = 1 to myString(0)
HSerPrint chr(myString(myHandler))
next

HSerPrintCRLF 2
~~~

[Bertrand BAROTH]

Thanks, I will order a processor for testing, and post the result ...

[Anobium]

What is your microcprocessor currently?

[Bertrand BAROTH]

Currently I use a 8515, but I can swap to any pin compatible (or not, I would design a new PCB all the way, and I make the tests with my STK200) with more RAM, the most difficult is ... that I must order it ! But I am afraid that your "myString" is not significant : char # 41 = char # 1, and so on. So, if printing begins again with char #1 instead of # 41, You don't see the difference ; try repeating "ABCDEFGHIJ" from # 41 upwards, and then "KLMNOPQRST" from # 81 upwards ...

[Anobium]

ok
I will try different string.

[Bertrand BAROTH]

It's strange, the length of the string transmitted via HSerPrint is the real length of the string used, but the addressing of the characters inside of the string seems to occur modulo 40 ... So the beginning can be repeated.

[Anobium]

May be I dont understand.

My program. No repeats, 180 chars long.

'Chip Settings.
#chip mega328p, 16
#option explicit

'USART settings
#define USART_BAUD_RATE 9600
#define USART_TX_BLOCKING

dim myString as string * 255
dim myHandler as word

myString = "Thankful_for_the_change_of_subject,_Cynthia_launched_into_a_description_of_her_latest_conquests_with_the_cat,_again_tucking_that_nagging_doubt_to_the_back_of_her_mind."

HSerPrint "Start:"
wait 1 s
HSerPrintCRLF 2
HSerPrint myString
HSerPrintCRLF 2
HSerPrint "Next:"
HSerPrintCRLF 2

for myHandler = 1 to myString(0)
HSerPrint chr(myString(myHandler))
next

HSerPrintCRLF 2

Provides

Start:

Thankful_for_the_change_of_subject,_Cynthia_launched_into_a_description_of_her_latest_conquests_with_the_cat,_again_tucking_that_nagging_doubt_to_the_back_of_her_mind.

Next:

Thankful_for_the_change_of_subject,_Cynthia_launched_into_a_description_of_her_latest_conquests_with_the_cat,_again_tucking_that_nagging_doubt_to_the_back_of_her_mind.

Please post your code, the minimum that reproduces the error.

[Bertrand BAROTH]

With my current processor the error seems unfortunately to be "normal" (512 bytes of RAM) ; as soon as I get my new processor, I will test and post the result ...
Happy New Year !

[Bertrand BAROTH]

Meanwhile I solved the problem with another method : I split the string in several substrings, send them successively to Emic-2, using the handshake after each HSerPrint (Emic-2 responds with ":" when ready). The voice is a little bit "chopped", but it works ... All the way I will test with a "bigger" processor ...

[Bertrand BAROTH]

Last news : I am still using my "old" 90S8515. If I include the string as a constant in HSerPrint, it "folds" after 40 characters and begins again. The trick is, as Anobium wrote, to dimension a variable as a string of defined maximum length : Dim .... As String * (length), to assign a constant value to the string variable and then transmit it (as a variable) to HSerPrint. Declaring a length of 192 bytes causes an "Out of Memory Error" at compilation. But a length of 80 characters is OK (even with the 8515) and the text is spoken correctly by the Emic - 2 if I use this method.
I think that if one transmits the string as a constant to HSerPrint even on Mega 1284, he will still have the issue with the 40 characters.

[Anobium]

Please post the code

[Bertrand BAROTH]

Here it is, as Attachment. There is no "Wait" after each word in the loop, because 1 s is enough for Emic - 2 to finish the spoken word at the rate of W280, and a "Waiting" would add supplementary noticeable delay (the length of the spoken word), the transmission time for the string itself adds already some slight delay (but on the other sife the purpose is not an ultra precise chrono ... )
Baratin means "smooth talk", Sortie means Output and Tampon means Buffer ; with Emic-2 each string representing speech should be preceded with an "S" and terminated with a LF.

[Anobium]

Where do i look for string issue?
I am looking a string constant?

[Bertrand BAROTH]

The issue occurs if You put the text directly into HSerPrint :
HSerPrint ("STrain ... minutes")
instead of HSerPrint (Baratin)

[Anobium]

Can you test this?

This is for a different device - but, I have reduced the RAM to 512.

The results are:

STrain Number 11 25 to Springfield will depart in 5 minutes
STrain Number 11 25 to Springfield will depart in 5 minutes

Test program

#chip 18f24k42, 32
#option Explicit
#config EXTMCLR

    'Generated by PIC PPS Tool for Great Cow Basic
    'PPS Tool version: 0.0.5.25
    'PinManager data: v1.75
    'Generated for 18f25k42
    '
    'Template comment at the start of the config file
    '
    #startup InitPPS, 85
    #define PPSToolPart 18f25k42

    Sub InitPPS

            'Module: UART pin directions
            Dir PORTC.6 Out    ' Make TX1 pin an output
            'Module: UART1
            RC6PPS = 0x0013    'TX1 > RC6

    End Sub
    'Template comment at the end of the config file

    'USART settings
    #define USART_BAUD_RATE 9600
    #define USART_TX_BLOCKING

    Dim Baratin As String * 80
    Baratin = "STrain Number 11 25 to Springfield will depart in 5 minutes"

    HSerPrintCRLF 2
    HSerPrint "STrain Number 11 25 to Springfield will depart in 5 minutes"
    HSerPrintCRLF
    HSerPrint  Baratin
    HSerPrintCRLF

[Bertrand BAROTH]

As I wrote, if I put the text directly into the HSerPrint, it repeats from the beginning after character 40 ... With the method You suggested, and which I used in my sample program, it works. The only difference I see in Your program is that You send the CRLF separately .... I will order an ATMega1284 and make the test on it, with the method that fails, and I will post the result.

[Anobium]

OK. Please adapt the program above when you test then I will be able to test very quickly.

[Bertrand BAROTH]

I adapted the prg to 90S8515 ; there are issues when not sending the CRLF automatically, and I had to insert a delay at the beginning and before the second HSerPrint. The results were absolutely ... RANDOM ! Sometimes the end of the sentence was not intelligible, or the beginning was repeated, or it was spoken only once ... and he result varied if I executed the prg from STK200 environment or with a cold start on the board with ISP cable disconnected.
Don't forget : the issues are an interaction between the HSerPrint and the Emic-2, which holds data in its buffer from the previous run and needs special control codes.
So I wrote my own test program (attached), sending the text once as a constant and once as a variable. The results are both OK, and I tested with swapping the 2 HSerPrint's : it was OK, too.
Now I have a method which works, using always HSerPrint (variable) and I will be satisfied with it : in practice the text will be concatenated from several specific "subtexts".
Thanks for Your efforts ...