The attached program produces garbage, Tampon_leds is corrupted if I activate the serial routines ; if I cancel them with a "comment" in the "envoi ... " and "attente ..." sub's, everything works OK (excepted for the fact that I can't hear nothing ...). Very strange ...
The problem is not if the data are transmitted : in fact, they are, Emic speaks ... But there are "side effects", as I wrote some other variables are modified ! On the STK200, Port B is for PushButtons and Port D for control Leds. It looks as if inside softserial, memory allocation of variables would generate conflicts with other variables of user's prog. I tested with GCB 04, 05 and Minimal 06, same error.
In fact, the error is (at least) inside SerXPrint (I used the prog without Attente_Emic, replacing it with a delay) and the wrong value tranferred to Tampon_leds is related with the variable Gare or gare_locale. Hope this helps for debugging ...
I downloaded SoftSerial_20190205 and installed the four files, still the same ...
Meanwhile I tested with hardware RS232, removing the jumpers for Pushbuttons at PD0 and PD1 ; the result was worse : not only Tampon_leds but Tampon_emic too were corrupted, resulting in unintelligible noise.
Last edit: Bertrand BAROTH 2020-06-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since it is probable that there are some bugs (allocation of RAM) in the AVR part of softserial (and hardware RS232) routines (I could not find any in my prog, I made the test I described above, the errors appeared only when the serial routines were activated), are You planning to make an update in a near future ? I saw there was such a modification last year, I think for the PIC part, as most users of GCBasic seem to program this processor family ...
Thanks in advance for any answer ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A prog was attached to the first post. You can test it without Emic hardware by removing the call to Attente_emic (which waits for Emic finishing) inside of Annoncer_train, so no timeout will occur.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I need the minimum program. The smallest program to create the issue. Then, I can debug. Please try the attachment - this has the init. the serial in/out. Does this create the issue?
Your attachment does not create the issue, the leds 0 and 3 are immediately lit ; normal, if the "envoi ..." at line 55 corrupts the Tampon_leds, this cannot be seen because it is assigned a value later (line 59) and is written to Port at line 64. So I modified Your prog to the new attachment. And now the Tampon_leds was never corrupted. But I modified line 62 to send 64 times "A" ; and not only was the sentence repeated several times ( ? ) but tampon_leds was corrupted too at line 65 (lower nibble 0x1, Leds 1, 2 and 3 on). It seems that there is a kind of "buffer overflow" if one sends via RS232 a string longer than a "particular" value (32 ? ) ... Look for the same issue in the hardware routines.
The problem does not come from the Emic, it has a buffer of 1024 bytes. But if You make the test without connecting it take care, don't forget to cancel the lines which activate a waiting for answer via RS232, otherwise there will be an endless loop in "Attente ... " and the prog can never reach line 63 !
If this is the real cause, maybe a possibility would be a "#define Serial_buffer_size", to avoid the need of a minimum amount of RAM to use the RS232 routines ?
Using a longer string (> 38 chars here) and merge the string while using HSerPrint (SerNPrint the same) the value of the byte variable is changed while never touched by code.
Workaround: Merge String before sending via Print.
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks ... In fact the idea is working because the Emic concatenates the incoming strings in its input buffer and begins with speaking only when the complete string is terminated by a CR. I attach the final prog (I must admit, it looks a little bit "strange", but it works) ... As You understood the routines will be used in my model railroad layout control program, and a side effect could cause a "splendid" accident or short-circuit on a turnout. I attach the final test program. But You could add the information of maximal length in a future version of help file.
And, since I am sure that there will be no side effects if I use only strings "not too long", maybe I will replace the "synthetic" , but a little "robotic" voice of the Emic : some modellers compared the samples that I published on a model forum with the voice of a Cylon warrior in "Battlestar Galactica", end of the 70's ... With the Adafruit sample player the commands are only 13 characters in length : "P" (for "Play") + 8 for file name + 3 for extension + LF ...
Resolved
The attached program produces garbage, Tampon_leds is corrupted if I activate the serial routines ; if I cancel them with a "comment" in the "envoi ... " and "attente ..." sub's, everything works OK (excepted for the fact that I can't hear nothing ...). Very strange ...
Last edit: Anobium 2021-11-15
I am not the expert on Soft Serial.. but, try this to isolate the issue.
Do you get
Helloon the terminal?The problem is not if the data are transmitted : in fact, they are, Emic speaks ... But there are "side effects", as I wrote some other variables are modified ! On the STK200, Port B is for PushButtons and Port D for control Leds. It looks as if inside softserial, memory allocation of variables would generate conflicts with other variables of user's prog. I tested with GCB 04, 05 and Minimal 06, same error.
In fact, the error is (at least) inside SerXPrint (I used the prog without Attente_Emic, replacing it with a delay) and the wrong value tranferred to Tampon_leds is related with the variable Gare or gare_locale. Hope this helps for debugging ...
I downloaded SoftSerial_20190205 and installed the four files, still the same ...
Meanwhile I tested with hardware RS232, removing the jumpers for Pushbuttons at PD0 and PD1 ; the result was worse : not only Tampon_leds but Tampon_emic too were corrupted, resulting in unintelligible noise.
Last edit: Bertrand BAROTH 2020-06-26
Since it is probable that there are some bugs (allocation of RAM) in the AVR part of softserial (and hardware RS232) routines (I could not find any in my prog, I made the test I described above, the errors appeared only when the serial routines were activated), are You planning to make an update in a near future ? I saw there was such a modification last year, I think for the PIC part, as most users of GCBasic seem to program this processor family ...
Thanks in advance for any answer ...
We are updating very soon but we have not seen these errors before. We are currenlty adding more AVRs and we have tested and tested AVRs.
I need a program with the minimum amount of code to reproduce the issue.
Write a program - minimal code and let us have a look.
:-)
A prog was attached to the first post. You can test it without Emic hardware by removing the call to Attente_emic (which waits for Emic finishing) inside of Annoncer_train, so no timeout will occur.
Sorry, may be I am not being clear.
I need the minimum program. The smallest program to create the issue. Then, I can debug. Please try the attachment - this has the init. the serial in/out. Does this create the issue?
Your attachment does not create the issue, the leds 0 and 3 are immediately lit ; normal, if the "envoi ..." at line 55 corrupts the Tampon_leds, this cannot be seen because it is assigned a value later (line 59) and is written to Port at line 64. So I modified Your prog to the new attachment. And now the Tampon_leds was never corrupted. But I modified line 62 to send 64 times "A" ; and not only was the sentence repeated several times ( ? ) but tampon_leds was corrupted too at line 65 (lower nibble 0x1, Leds 1, 2 and 3 on). It seems that there is a kind of "buffer overflow" if one sends via RS232 a string longer than a "particular" value (32 ? ) ... Look for the same issue in the hardware routines.
The problem does not come from the Emic, it has a buffer of 1024 bytes. But if You make the test without connecting it take care, don't forget to cancel the lines which activate a waiting for answer via RS232, otherwise there will be an endless loop in "Attente ... " and the prog can never reach line 63 !
If this is the real cause, maybe a possibility would be a "#define Serial_buffer_size", to avoid the need of a minimum amount of RAM to use the RS232 routines ?
Last edit: Bertrand BAROTH 2020-06-27
I can reproduce the issue on an Arduino Uno:
Using a longer string (> 38 chars here) and merge the string while using HSerPrint (SerNPrint the same) the value of the byte variable is changed while never touched by code.
Workaround: Merge String before sending via Print.
Frank
Thanks ... In fact the idea is working because the Emic concatenates the incoming strings in its input buffer and begins with speaking only when the complete string is terminated by a CR. I attach the final prog (I must admit, it looks a little bit "strange", but it works) ... As You understood the routines will be used in my model railroad layout control program, and a side effect could cause a "splendid" accident or short-circuit on a turnout. I attach the final test program. But You could add the information of maximal length in a future version of help file.
And, since I am sure that there will be no side effects if I use only strings "not too long", maybe I will replace the "synthetic" , but a little "robotic" voice of the Emic : some modellers compared the samples that I published on a model forum with the voice of a Cylon warrior in "Battlestar Galactica", end of the 70's ... With the Adafruit sample player the commands are only 13 characters in length : "P" (for "Play") + 8 for file name + 3 for extension + LF ...
Last edit: Bertrand BAROTH 2020-06-28
Guys - well done. I did not recognise the bug. This bug is planned to be fixed in the next release. Just awaiting Hugh to complete a few last items.
See https://sourceforge.net/p/gcbasic/discussion/579125/thread/8aafd62637/#da98 item #5 "String concat errors"
This issue has been reported mulitple times. Below is the bug reference note I have:
I will add Frank's new example to the reference notes for this bug.
This now yields A123 - as expected.
Now yeilds
Finally I found that the best solution was to send the string one character at once in a loop :
Sub Envoi_tampon_emic ()
' Envoie le contenu du Tampon_emic
Dim compteur_local As Byte
Dim char_local As String * 1
Tampon_emic = Tampon_emic + chr (13)
For compteur_local = 1 to Len (Tampon_emic)
char_local = Mid (tampon_emic, compteur_local, 1)
Ser1Print (char_local)
Next
End Sub
Last edit: Bertrand BAROTH 2020-07-07