I wrote a prog using Elechouse's SimpleVR (connected to Serial1) and AdaFruits's SoundFX (connected to Serial2) on my STK200 board, the final version should be used with my railroad layout. If I use the software routines it works fine (I use GCB with the newest patch) : see attached file Parole.gcb, line #69 is for debugging. Now I modified the prog to use the RS232 hardware routines, Parole_hard.gcb (BTW I don't understand the signification of lines 8 and 13 which I copied from an example for PIC). As You can see the first lines to be executed in conjunction with a serial interface are 58 to 62, but line 63 is never reached ...
Meanwhile I edited ... Unfortunately it is not possible to add 2 attachments in "post creating" mode (the second one replaces the first), only in edit mode !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In fact the synopsis of the prog is very simple : In main routine the ports are first initialized, then the prog calls the procedure Recevoir_train (), which immediately calls Select_ vocabulaire (1), and in this procedure the Ser1Send are called at the beginning, there shouldn't be any "collision" because USART1_TX_BLOCKING ; then the Attendre_OK () procedure is called, which simply waits for the SimpleVR to send back the char 0x0A ... Then the Led7 on PortB should be lit ... but it doesn't in the "hardware" version. So I think that the bug is either in the Ser1Send or in the Ser1Receive routine ; or maybe there is a stack overflow ?
Last edit: Bertrand BAROTH 2022-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not understand what the issue is. Are you saying there is a bug in the software serial implementation? You said ". So I think that the bug is either in the Ser1Send or in the Ser1Receive routine ?".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I remembered that I had already such issues with Mega162, You sent me a modified file usart.h on Oct 08 2021 (attached). I used it again ... AND IT WORKS ! It seems that the corresponding modifications were not kept in the file in the newest patch ...
Could You please include the corresponding modifications (I saw that it was related with baud rate calculation) in the newest patch ? I don't know if there are no other modifications made since 7 months, otherwise I would use the "old" file ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Meanwhile I have removed the instruction to light the led. The file related with "Old.asm" (the usart.h from the newest patch) does not work ; those related with "working.asm" and "current.asm" are OK.
PS : a few "posts" ago, I made a mistake, I wrote about a bug in Ser1Send etc, in fact it should be HSerSend ; errare humanum est.
Users may wish to define USART1_BAUD_RATE to use USART 1 as this makes logical sense in the context that USART2_BAUD_RATE, USART3_BAUD_RATE etc exist, But, all the USART1 methods() use USART_BAUD_RATE - so, if USART_BAUD_RATE is not defined then USART1 is not operational.
Fix:
If users define USART1_BAUD_RATE the updated usart.h library has a script that will automatically create the correct CONSTANTs for USART1. "
Hello again (unfortunately)
I wrote a prog using Elechouse's SimpleVR (connected to Serial1) and AdaFruits's SoundFX (connected to Serial2) on my STK200 board, the final version should be used with my railroad layout. If I use the software routines it works fine (I use GCB with the newest patch) : see attached file Parole.gcb, line #69 is for debugging. Now I modified the prog to use the RS232 hardware routines, Parole_hard.gcb (BTW I don't understand the signification of lines 8 and 13 which I copied from an example for PIC). As You can see the first lines to be executed in conjunction with a serial interface are 58 to 62, but line 63 is never reached ...
? ? ?
Last edit: Bertrand BAROTH 2022-05-07
What is the issue? Is this just an example of your code?
Meanwhile I edited ... Unfortunately it is not possible to add 2 attachments in "post creating" mode (the second one replaces the first), only in edit mode !
If this is a hardware serial issue. You will need to strip the code down to the bare essential to demonstrate the issue.
It would take me many many hours to understand the program.
I think I will go on using the software routines ... All the way they use less prog memory !
Good idea
In fact the synopsis of the prog is very simple : In main routine the ports are first initialized, then the prog calls the procedure Recevoir_train (), which immediately calls Select_ vocabulaire (1), and in this procedure the Ser1Send are called at the beginning, there shouldn't be any "collision" because USART1_TX_BLOCKING ; then the Attendre_OK () procedure is called, which simply waits for the SimpleVR to send back the char 0x0A ... Then the Led7 on PortB should be lit ... but it doesn't in the "hardware" version. So I think that the bug is either in the Ser1Send or in the Ser1Receive routine ; or maybe there is a stack overflow ?
Last edit: Bertrand BAROTH 2022-05-07
Sorry, do not understand. You think there is a bug in Ser1Send or Ser1Receive. I thought the issue was in Hardware USART.
Last edit: Anobium 2022-05-07
I adapted the prog in MikroPascal, using hardware USART1 and 2, it works ; so the processor is not the source of the issue.
This may be a language issue.
I am not implying the mcu is the issue.
I do not understand what the issue is. Are you saying there is a bug in the software serial implementation? You said ". So I think that the bug is either in the Ser1Send or in the Ser1Receive routine ?".
The software gets "hung up", it never reaches the line where the led should be lit, but it reaches with the software USART routines.
Last edit: Bertrand BAROTH 2022-05-07
Now I remembered that I had already such issues with Mega162, You sent me a modified file usart.h on Oct 08 2021 (attached). I used it again ... AND IT WORKS ! It seems that the corresponding modifications were not kept in the file in the newest patch ...
This is using hardware USART. I am so confused.
Could You please include the corresponding modifications (I saw that it was related with baud rate calculation) in the newest patch ? I don't know if there are no other modifications made since 7 months, otherwise I would use the "old" file ...
I have compared the current USART.h and the one you posted. I cannot see what is the issue.
I probably have messed up the management of the .h file.
Do exactly this.
Attach all three to a post.
Meanwhile I have removed the instruction to light the led. The file related with "Old.asm" (the usart.h from the newest patch) does not work ; those related with "working.asm" and "current.asm" are OK.
PS : a few "posts" ago, I made a mistake, I wrote about a bug in Ser1Send etc, in fact it should be HSerSend ; errare humanum est.
PPS : look at this thread from Oct 08 2021 :
https://sourceforge.net/p/gcbasic/discussion/596084/thread/740b65fdeb/
At the end You wrote this explanation :
"The root cause is:
Users may wish to define USART1_BAUD_RATE to use USART 1 as this makes logical sense in the context that USART2_BAUD_RATE, USART3_BAUD_RATE etc exist, But, all the USART1 methods() use USART_BAUD_RATE - so, if USART_BAUD_RATE is not defined then USART1 is not operational.
Fix:
If users define USART1_BAUD_RATE the updated usart.h library has a script that will automatically create the correct CONSTANTs for USART1. "
Last edit: Bertrand BAROTH 2022-05-08
Looks likes release control problem.
I will analyse and try to sort.
Finally, which usart.h should I use ? This from Oct 2021 or this from Your recent post ?
This is my next piece of work to resolve and answer.
I can do Tuesday morning (London time).
Hopefully resolved. Get the latest release and test please.
:-)
Seems OK, at least with Mega162. Thanks ...
Excellent.