Some preliminaries : the ADAFruit (Sound FX) is a sample player board, it answers first with a string which can here be considered as garbage and when it has finished playing the wav file it responds "done" followed by chr (10) . My testing board is the (old) STK200, 8 Leds are connected to PortB, so I can see the progress of the prog. The first version, using soft UART on the pins of the hardware UART, works fine, it reaches line 51 (see attachment).
And if I use hardware UART instead it locks at line 41 (see attachment) ; either the command string is corrupted during transmission (or even not transmitted), or the issue is in the HSerReceive. Same issue with 90S8515 ... What doesn't work if I use the hardware routines ?
then, change to Hsersend "A" - this proves a char are being handled correctly.
then, change to HserPrint "ABCDEF" - this proves chars are being handled correctly.
So, does the send basics work?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately I can't test this, I can only test with my boards (I have no suitable serial cable for real RS232 frome the STK200, and no serial connector on my computer, to use terminal).
But as far as I can see, or rather (not) hear, no sound comes from the ADAFruit, so it seems that it's not (only) the handshake (HSerReceive) which doesn't perhaps work, but even the command string is not sent correctly (the ADAFruit board is OK, it works with the software version).
Last edit: Bertrand BAROTH 2021-01-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I succeeded using an USB to serial adapter, and monitoring the outgoing stream from the STK200 with GCBasic's terminal program (which in fact is very fine) ; I switched it to ASCII mode for the incoming stream.
With the first prog, I plugged in the adapter and quickly "connected" it. I saw :
PMESSAG02WAV
which is the correct string.
Now I disconnected, unplugged the adapter, programmed the processor with the second prog, and did the same procedure again ; now I got garbage : (copied from the screen and saved to noteblock)
<0>f ff˜<0>æ<0>x~f<0>†f<0>
and saw a "FRAME ERROR" at the bottom of the window ...
? ? ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the serial stream inverted? I think is may be an inverted as serial worked
1. Software
2. Serial (non inverted) USB-TTL converter
So,
1. Post the software config for the serial.
2. Look at data sheet to invert hw usart signal. It will be one bit in a serial register (if implemented)
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the data sheet of the Mega8515 there is no option for data inverting ; and the configuration for the USB to serial adapter was the same in both cases. I wonder if the data transmitted by GCBasic itself to the USART are inverted ?
Last edit: Bertrand BAROTH 2021-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is the code for Mega 162. I added the delay command, assuming that the issue was perhaps caused by a malfunction of the TX_Blocking. I got this :
ˆ8
Finally I wonder if something is rotten ... not in Denmark :), but in the ATmel hardware !
OK. Go back the software serial and complete this test. Change the one line in the software code from off to on If this causes the same error on the terminal then we know the root cause.
#Define SER1_INVERT On
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The final conclusion : in a desperate latest test I installed MikroBasic, modified the program in accordance with the corresponding syntax, re-programmed my Mega162, connected to the terminal ... and got garbage again ! So now I am sure : the U(S)ART in the old Atmel's is crap ! I must add here that I had a similar discussion on another forum, and heard from a guy who tried to develop a BlueTooth interface with the Atmel ... without success ! No comment ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In fact I tested the hardware serial receive with Mikrobasic too, and another board : it works ; so it seems that the bug is only in the hardware part for sending ; and so finally I will use the software routines ! Thanks to Atmel for the wasted time, GRRR ! :(
Last edit: Bertrand BAROTH 2021-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A bad news : in my former test with MikroBasic I had left the config of the 162 with internal clock ...
Now I switched to external clock ... and it works fine, I see my correct text and hear the message when I connect the Adafruit. So finally the error is inside GreatCow Basic !
Last edit: Bertrand BAROTH 2021-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To summarize :
1) The "software" version compiled with GCBasic works.
2) The "hardware" version compiled with GCBasic doesn't work.
3) The "hardware" version compiled with MikroBasic works.
Last edit: Bertrand BAROTH 2021-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do actually know the The "hardware" version compiled with MikroBasic is really hardware solution? If you have the ASM then we can review the differences.
And, re 2) That is because the signal is not inverted.
So, does MikroBasic invert?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that the baudrate is false ; I think that UART operates in Normal mode, so UBRRL should be 25 ; but at line 449 it seems that it initialized with 51.
Finally there seem to be two issues (I attach the Source) :
1) At lines 40 - 41 : HSerSend does not accept concatenation, so I had to send the LF separately ; Ser1Print seems to accept concatenations.
2) The "new" prog works with Mega162, but not 90S8515 : In the ASM code, the value for UBRLL is still 51, but 90S DOES NOT accept double speed, so I think that the value should be 25 as described in the datasheet.
I think that my various garbages in the terminal program were caused by the fact that the Mega processors were perhaps configured to iInternal clock, and that it I did not notice it (wrong baud rate).
Murphy says "Things go worse under pressure" :)
I have already tried #2 : the answer : UBRLL is not defined (in GCBasic) ! In fact, You should modify the formula for UBRRL in a next version of GCBasic ...
Last edit: Bertrand BAROTH 2021-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some preliminaries : the ADAFruit (Sound FX) is a sample player board, it answers first with a string which can here be considered as garbage and when it has finished playing the wav file it responds "done" followed by chr (10) . My testing board is the (old) STK200, 8 Leds are connected to PortB, so I can see the progress of the prog. The first version, using soft UART on the pins of the hardware UART, works fine, it reaches line 51 (see attachment).
Last edit: Bertrand BAROTH 2021-01-31
And if I use hardware UART instead it locks at line 41 (see attachment) ; either the command string is corrupted during transmission (or even not transmitted), or the issue is in the HSerReceive. Same issue with 90S8515 ... What doesn't work if I use the hardware routines ?
Last edit: Bertrand BAROTH 2021-01-31
What version of the compiler / Great Cow BASIC?
Hardware USART compiles here. What is the error message?
Line 41 sets up PORTB....
I am still using RC37, there is no error message at compilation, the program simply "hangs".
OK. The version is good.
Do the basics work? Remove the sub. Does the char 54 get sent ?
then, change to Hsersend "A" - this proves a char are being handled correctly.
then, change to HserPrint "ABCDEF" - this proves chars are being handled correctly.
So, does the send basics work?
Unfortunately I can't test this, I can only test with my boards (I have no suitable serial cable for real RS232 frome the STK200, and no serial connector on my computer, to use terminal).
But as far as I can see, or rather (not) hear, no sound comes from the ADAFruit, so it seems that it's not (only) the handshake (HSerReceive) which doesn't perhaps work, but even the command string is not sent correctly (the ADAFruit board is OK, it works with the software version).
Last edit: Bertrand BAROTH 2021-01-31
OK - I would be using the software serial. Case closed. :-)
Now I succeeded using an USB to serial adapter, and monitoring the outgoing stream from the STK200 with GCBasic's terminal program (which in fact is very fine) ; I switched it to ASCII mode for the incoming stream.
With the first prog, I plugged in the adapter and quickly "connected" it. I saw :
PMESSAG02WAV
which is the correct string.
Now I disconnected, unplugged the adapter, programmed the processor with the second prog, and did the same procedure again ; now I got garbage : (copied from the screen and saved to noteblock)
<0>f f
f˜<0>æ<0>x~f<0>†f<0>and saw a "FRAME ERROR" at the bottom of the window ...
? ? ?
OK good.
Is the serial stream inverted? I think is may be an inverted as serial worked
1. Software
2. Serial (non inverted) USB-TTL converter
So,
1. Post the software config for the serial.
2. Look at data sheet to invert hw usart signal. It will be one bit in a serial register (if implemented)
Evan
In the data sheet of the Mega8515 there is no option for data inverting ; and the configuration for the USB to serial adapter was the same in both cases. I wonder if the data transmitted by GCBasic itself to the USART are inverted ?
Last edit: Bertrand BAROTH 2021-02-02
You are asking the question that I ask.
Share your software serial code to reveal... else... I am guessing.
Got a Protocol Analyser? this will stop the guessing.
Here is the code for Mega 162. I added the delay command, assuming that the issue was perhaps caused by a malfunction of the TX_Blocking. I got this :
ˆ8
Finally I wonder if something is rotten ... not in Denmark :), but in the ATmel hardware !
Last edit: Bertrand BAROTH 2021-02-02
OK. Go back the software serial and complete this test. Change the one line in the software code from
offtoonIf this causes the same error on the terminal then we know the root cause.#Define SER1_INVERT OnThe final conclusion : in a desperate latest test I installed MikroBasic, modified the program in accordance with the corresponding syntax, re-programmed my Mega162, connected to the terminal ... and got garbage again ! So now I am sure : the U(S)ART in the old Atmel's is crap ! I must add here that I had a similar discussion on another forum, and heard from a guy who tried to develop a BlueTooth interface with the Atmel ... without success ! No comment ...
But, the answer is to use software serial surely?
In fact I tested the hardware serial receive with Mikrobasic too, and another board : it works ; so it seems that the bug is only in the hardware part for sending ; and so finally I will use the software routines ! Thanks to Atmel for the wasted time, GRRR ! :(
Last edit: Bertrand BAROTH 2021-02-02
A bad news : in my former test with MikroBasic I had left the config of the 162 with internal clock ...
Now I switched to external clock ... and it works fine, I see my correct text and hear the message when I connect the Adafruit. So finally the error is inside GreatCow Basic !
Last edit: Bertrand BAROTH 2021-02-02
I do not follow. This doe not make sense from what you have shared.
So, test HW Serial works via the USBTTL again. Does this work ?
To summarize :
1) The "software" version compiled with GCBasic works.
2) The "hardware" version compiled with GCBasic doesn't work.
3) The "hardware" version compiled with MikroBasic works.
Last edit: Bertrand BAROTH 2021-02-02
Do actually know the The "hardware" version compiled with MikroBasic is really hardware solution? If you have the ASM then we can review the differences.
And, re 2) That is because the signal is not inverted.
So, does MikroBasic invert?
I think that the baudrate is false ; I think that UART operates in Normal mode, so UBRRL should be 25 ; but at line 449 it seems that it initialized with 51.
Why would this be the case?
The test to the USBTLL worked at the correct BPS?
Finally there seem to be two issues (I attach the Source) :
1) At lines 40 - 41 : HSerSend does not accept concatenation, so I had to send the LF separately ; Ser1Print seems to accept concatenations.
2) The "new" prog works with Mega162, but not 90S8515 : In the ASM code, the value for UBRLL is still 51, but 90S DOES NOT accept double speed, so I think that the value should be 25 as described in the datasheet.
I think that my various garbages in the terminal program were caused by the fact that the Mega processors were perhaps configured to iInternal clock, and that it I did not notice it (wrong baud rate).
Murphy says "Things go worse under pressure" :)
Last edit: Bertrand BAROTH 2021-02-02
I have already tried #2 : the answer : UBRLL is not defined (in GCBasic) ! In fact, You should modify the formula for UBRRL in a next version of GCBasic ...
Last edit: Bertrand BAROTH 2021-02-02