I can see the error. These files really help. The USART is not being initialised correctly for this specific chip. This is easily resolvable but it will require some patience by you. The cause is that this chip may have one of the chips that Hugh tested many years ago, or, when we implemented hardware USART support is was not on the list of chips to be tested.
Anyway.... we can add our own initialisation routine to resolve. This routine may not resolve first go. Once it does work we can move into the USART library. If this fails and you simply want to get going ... change to using Software Serial communications method.
Use the following code - this is intended to only support transmit. It will take more work to resolve receive.
Oké
So if I understand correctly this should be modified in GCB?
But until then I can use the code below to continue.
I'm going to try this out this week. In any case, I'm glad to hear that we know what's going on and where the problem is coming from.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi I'm back.
Not been able to work much on the project in recent weeks. Today I went further.
I've tried the code you showed me before, but it doesn't work.
I'm also wondering if this code wouldn't conflict with the compiler now built into GCB?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Questions?
I don't use the bootloader myself because I program the ATmega32U4 directly with my Atmel-ICE programmer.
In other words: do you want to receive the board with or without the Arduino bootloader?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I changed the Great Cow Basic USART library. But, since making the change I have discussed with the Developer of OshenSoft and I think I need to handle this chip differently. So, I still need the board.
The issue is. Most AVRs have a USART0, in Great Cow BASIC we would call this Number #1. But, this chip does not have a USART0 but is starts with USART1. So, we discussed last night and I will align with the same convention where GCB will have to use USART2 not USART (which implies USART1). The change I made was a test to prove that this is just a library issue.
So, we know it works. This this is just about writing the library and testing.
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oké
These files tell me you have selected a Mega328p at 16 mHz on that software.
But, you chose #chip mega32u4, 16 for Great Cow BASIC
If the target chip is a Mega328p then used #chip mega328p 16 in Great Cow BASIC
sorry my mistake I sent you the wrong file!
For the uno I had created the same file as test.
I can see the error. These files really help. The USART is not being initialised correctly for this specific chip. This is easily resolvable but it will require some patience by you. The cause is that this chip may have one of the chips that Hugh tested many years ago, or, when we implemented hardware USART support is was not on the list of chips to be tested.
Anyway.... we can add our own initialisation routine to resolve. This routine may not resolve first go. Once it does work we can move into the USART library. If this fails and you simply want to get going ... change to using Software Serial communications method.
Use the following code - this is intended to only support transmit. It will take more work to resolve receive.
Last edit: Anobium 2022-03-05
Oké
So if I understand correctly this should be modified in GCB?
But until then I can use the code below to continue.
I'm going to try this out this week. In any case, I'm glad to hear that we know what's going on and where the problem is coming from.
Hi I'm back.
Not been able to work much on the project in recent weeks. Today I went further.
I've tried the code you showed me before, but it doesn't work.
I'm also wondering if this code wouldn't conflict with the compiler now built into GCB?
Post the project in a ZIP. the Small BASIC source and the Great Cow BASIC program.
I can look for you.
Here are the files.
Thanks
I think I need one of the board here. I ported to an UNO and it worked - of course.
Willing to send me one?
I am cannot sort the UART library without one. I am guessing on what is happening. I am guessing that the library is not setting some bit somewhere.
You mean send an arduino leonardo to you. I can do that.
If that helps to a permanent solution. Would you like to send or email me the address?
I have sent you a personal message with my details.
Questions?
I don't use the bootloader myself because I program the ATmega32U4 directly with my Atmel-ICE programmer.
In other words: do you want to receive the board with or without the Arduino bootloader?
It would be best with a bootloader for speed at this end. But, I can program most MCUs. :-)
Okay then I'll give the Leonardo back its bootloader again.
I sent you an email earlier. Did you receive it?
Just to make sure you got it
Yes. I responded. Load the bootloader please
Try this please. Does this HEX work ?
Oké So this seems to work fine!
Obviously I don't know what you did? But it seems to be the right solution.
I changed the Great Cow Basic USART library. But, since making the change I have discussed with the Developer of OshenSoft and I think I need to handle this chip differently. So, I still need the board.
The issue is. Most AVRs have a USART0, in Great Cow BASIC we would call this Number #1. But, this chip does not have a USART0 but is starts with USART1. So, we discussed last night and I will align with the same convention where GCB will have to use USART2 not USART (which implies USART1). The change I made was a test to prove that this is just a library issue.
So, we know it works. This this is just about writing the library and testing.
Evan