Are you saying that LED is not turning off or on from the application?
Connect Terminal to the ttl/usb port. Reset the AVR board. Does the Terminal show the 'Small Basic Responder"? if not, you have not connected the TX between the chip and the USB/TTL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed the LED does not want to go on or off via the software of the small basic program.
I'm just worried that my USB/TTL device isn't working properly! In my windows device manager there is also a text that PL2303HXA has been phased out since 2012.
So in other words I don't trust it! And another thing I also noticed that when I use the serial monitor in Arduino (just like the terminal of GCB) I see the message Com port busy.
So, all things considered, I'm afraid that we have a problem too. So I'm going to order a new USB/TTL first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime I have also read the text below. What is the difference between serial and serial1?
Apparently you have to take this into account with the Leonardo! But it's not clear to me what exactly you should do with this. https://www.arduino.cc/en/Main/Arduino_BoardLeonardo Note that on the Leonardo, the Serial class refers to USB (CDC) communication; for TTL serial on pins 0 and 1, use the Serial1 class.
Could you tell me what the difference is?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It took a while, but now I have a new USB to TTL converter. This one works as it should and doesn't have the old problems I had before.
But I can't get the communication with the Arduino board and thus the ATmega32u4 going.
It works perfectly with the Arduino uno. So I don't understand what could be wrong with this one?
Let me explain what I've been doing in the meantime. I have reduced the code as far as possible to just establish communication between PC and board.
This means that I send a message back to the PC by means of "HserPrint. This code works flawlessly with the Uno but not with the Leonardo. (see the code below)
I do not see any difference. at this time.
Just to be clear, I'm not currently working with Aduino's bootloader! So I program the chip directly with my Atmel-ICE programmer. So in other words I use the Leonardo board purely as a test board. But it seems to me that this shouldn't matter?
What is the simplest way to know if I can communicate with the chip properly?
Can it get any simpler than this? Just to make sure it's not the chip or board?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
;ProgramcompiledbyGreatCowBASIC(0.99.012022-01-27(Windows64bit):Build1073)forMicrochipMPASM;Needhelp?SeetheGCBASICforumsathttp://sourceforge.net/projects/gcbasic/forums,;checkthedocumentationoremailw_cholmondeleyatusersdotsourceforgedotnet.;********************************************************************************;ChipModel:MEGA32U4;Assemblerheaderfile.INCLUDE"m32u4def.inc";SREGbitnames(forAVRAssemblercompatibility,GCBASICusesdifferentnames)#define C 0#define H 5#define I 7#define N 2#define S 4#define T 6#define V 3#define Z 1;********************************************************************************;Setasidememorylocationsforvariables.EQUCOMPORT=278.EQUPRINTLEN=279.EQURXEN=280.EQUSERDATA=281.EQUSTRINGPOINTER=282.EQUSYSPRINTDATAHANDLER=283.EQUSYSPRINTDATAHANDLER_H=284.EQUSYSPRINTTEMP=285.EQUSYSSTRINGPARAM1=256;********************************************************************************;Registervariables.DEFSYSBITTEST=r5.DEFSYSBYTETEMPA=r22.DEFSYSBYTETEMPB=r28.DEFSYSBYTETEMPX=r0.DEFSYSCALCTEMPA=r22.DEFSYSCALCTEMPX=r0.DEFSYSREADA=r30.DEFSYSREADA_H=r31.DEFSYSSTRINGA=r26.DEFSYSSTRINGA_H=r27.DEFSYSSTRINGB=r28.DEFSYSSTRINGB_H=r29.DEFSYSSTRINGLENGTH=r25.DEFSYSVALUECOPY=r21.DEFSYSTEMP1=r1.DEFSYSTEMP2=r2.DEFSYSTEMP3=r3.DEFSYSTEMP4=r16;********************************************************************************;Vectors;Interruptvectors.ORG0rjmpBASPROGRAMSTART;Reset.ORG2reti;INT0.ORG4reti;INT1.ORG6reti;INT2.ORG8reti;INT3.ORG14reti;INT6.ORG18reti;PCINT0.ORG20reti;USB_GEN.ORG22reti;USB_COM.ORG24reti;WDT.ORG32reti;TIMER1_CAPT.ORG34reti;TIMER1_COMPA.ORG36reti;TIMER1_COMPB.ORG38reti;TIMER1_COMPC.ORG40reti;TIMER1_OVF.ORG42reti;TIMER0_COMPA.ORG44reti;TIMER0_COMPB.ORG46reti;TIMER0_OVF.ORG48reti;SPI_STC.ORG50reti;USART1_RX.ORG52reti;USART1_UDRE.ORG54reti;USART1_TX.ORG56reti;ANALOG_COMP.ORG58reti;ADC.ORG60reti;EE_READY.ORG62reti;TIMER3_CAPT.ORG64reti;TIMER3_COMPA.ORG66reti;TIMER3_COMPB.ORG68reti;TIMER3_COMPC.ORG70reti;TIMER3_OVF.ORG72reti;TWI.ORG74reti;SPM_READY.ORG76reti;TIMER4_COMPA.ORG78reti;TIMER4_COMPB.ORG82reti;TIMER4_OVF;********************************************************************************;Startofprogrammemorypage0.ORG84BASPROGRAMSTART:;InitialisestackldiSysValueCopy,high(RAMEND)outSPH,SysValueCopyldiSysValueCopy,low(RAMEND)outSPL,SysValueCopy;CallinitialisationroutinesrcallINITSYSrcallINITUSART;Startofthemainprogram;-----Configuration;#option Explicit;#define TXEN TXEN1;#define UDRE UDRE1;USARTsettings;#define USART_BAUD_RATE 9600;#define USART_TX_BLOCKING;HSerPrint"Small BASIC Responder"ldiSysStringB,low(SYSSTRINGPARAM1)ldiSysStringB_H,high(SYSSTRINGPARAM1)ldiSysReadA,low(StringTable1<<1)ldiSysReadA_H,high(StringTable1<<1)rcallSYSREADSTRINGldiSysValueCopy,low(SYSSTRINGPARAM1)stsSysPRINTDATAHandler,SysValueCopyldiSysValueCopy,high(SYSSTRINGPARAM1)stsSysPRINTDATAHandler_H,SysValueCopyldiSysValueCopy,1stsCOMPORT,SysValueCopy;SYSSTRINGPARAM*1rcallHSERPRINT303BASPROGRAMEND:sleeprjmpBASPROGRAMEND;********************************************************************************;Overloadedsignature:STRING:byte:,Source:usart.h(1467)HSERPRINT303:;PrintLen=PrintData(0)ldsSysStringA,SysPRINTDATAHandlerldsSysStringA_H,SysPRINTDATAHandler_HldSysValueCopy,XstsPRINTLEN,SysValueCopy;IfPrintLen<>0thenldsSysCalcTempA,PRINTLENtstSysCalcTempAbreqENDIF1;WriteData;forSysPrintTemp=1toPrintLenldiSysValueCopy,1stsSYSPRINTTEMP,SysValueCopySysForLoop1:;HSerSend(PrintData(SysPrintTemp),comport)ldsSysTemp1,SysPRINTDATAHandlerldsSysTemp2,SYSPRINTTEMPaddSysTemp1,SysTemp2movSysStringA,SysTemp1ldsSysTemp1,SysPRINTDATAHandler_HldiSysTemp4,0adcSysTemp1,SysTemp4movSysStringA_H,SysTemp1ldSysValueCopy,XstsSERDATA,SysValueCopyrcallHSERSEND293;next;#4p Positive value Step Handler in For-next statementldsSysTemp2,PRINTLENldsSysTemp3,SYSPRINTTEMPsubSysTemp2,SysTemp3movSysTemp1,SysTemp2movSysBYTETempA,SysTemp1ldiSysBYTETempB,0rcallSYSCOMPEQUALcomSysByteTempXsbrsSysByteTempX,0rjmpENDIF2;SetLoopVartoLoopVar+StepValuewhereStepValueisapositivevalueldsSysTemp1,SYSPRINTTEMPincSysTemp1stsSYSPRINTTEMP,SysTemp1rjmpSysForLoop1;ENDIFENDIF2:SysForLoopEnd1:;EndIfENDIF1:;CRret;********************************************************************************;Overloadedsignature:BYTE:byte:,Source:usart.h(918)HSERSEND293:;AVRUSART1Send;ifcomport=1ThenldsSysCalcTempA,COMPORTcpiSysCalcTempA,1brneENDIF3;WaitWhileUDRE=OffSysWaitLoop1:ldsSysBitTest,UCSR1AsbrsSysBitTest,UDRE1rjmpSysWaitLoop1;EndIfENDIF3:;----------------------------------------------------ret;********************************************************************************;Source:system.h(156)INITSYS:;;'Turn off all ports;PORTB=0ldiSysValueCopy,0outPORTB,SysValueCopy;PORTC=0ldiSysValueCopy,0outPORTC,SysValueCopy;PORTD=0ldiSysValueCopy,0outPORTD,SysValueCopy;PORTE=0ldiSysValueCopy,0outPORTE,SysValueCopy;PORTF=0ldiSysValueCopy,0outPORTF,SysValueCopyret;********************************************************************************;Source:usart.h(583)INITUSART:;Setbaudrate;EnableTXandRX;RXEN=OnldiSysValueCopy,1stsRXEN,SysValueCopy;TXEN=OnldsSysValueCopy,UCSR1BsbrSysValueCopy,1<<TXEN1stsUCSR1B,SysValueCopyret;********************************************************************************;Source:system.h(2997)SYSCOMPEQUAL:;DimSysByteTempA,SysByteTempB,SysByteTempXasbyte;clrSysByteTempXclrSYSBYTETEMPX;cpseSysByteTempA,SysByteTempBcpseSYSBYTETEMPA,SYSBYTETEMPB;returnret;comSysByteTempXcomSYSBYTETEMPXret;********************************************************************************;Source:system.h(1490)SYSREADSTRING:;DimSysCalcTempAAsByte;DimSysStringLengthAsByte;DimSysCalcTempXAsByte;Getlength;lpmSysCalcTempA,Z+;lpmlpm;movSysCalcTempA,SysCalcTempXmovSYSCALCTEMPA,SYSCALCTEMPX;SysReadA+=1incSYSREADAbrnePC+2incSYSREADA_H;stY+,SysCalcTempAstY+,SYSCALCTEMPA;rjmpSysStringReadCheckrjmpSYSSTRINGREADCHECKSYSREADSTRINGPART:;lpmSysCalcTempA,Z+;lpmlpm;movSysCalcTempA,SysCalcTempXmovSYSCALCTEMPA,SYSCALCTEMPX;SysReadA+=1incSYSREADAbrnePC+2incSYSREADA_H;addSysStringLength,SysCalcTempAaddSYSSTRINGLENGTH,SYSCALCTEMPA;ChecklengthSYSSTRINGREADCHECK:;Iflengthis0,exit;cpiSysCalcTempA,0cpiSYSCALCTEMPA,0;brneSysStringReadbrneSYSSTRINGREAD;retret;CopySYSSTRINGREAD:;Copychar;lpmSysCalcTempX,Z+;lpmlpm;SysReadA+=1incSYSREADAbrnePC+2incSYSREADA_H;stY+,SysCalcTempXstY+,SYSCALCTEMPX;decSysCalcTempAdecSYSCALCTEMPA;brneSysStringReadbrneSYSSTRINGREADret;********************************************************************************SysStringTables:StringTable1:.DB21,83,109,97,108,108,32,66,65,83,73,67,32,82,101,115,112,111,110,100,101,114;********************************************************************************
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as my knowledge goes, these are the basic settings for an Arduino. So I just kept this one. And from Microchip Studio you have no choice but this 8Mhz setting. Everything above 8Mhz will in principle agree with this setting.
I'm not an ASM expert either and I'm not sure what exactly you mean by the last comment?
Now I don't know where to look? What are my options?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not understand this? The Arduino board runs at 16 Mhz. That's a fact.
It cannot be the intention that you change this to the internal clock.
Then you're going to bring the board down in its capabilities.
Or am I misunderstanding you now?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right now I don't know what I'm doing, and I hate that.
I'm just doing something and that has no basis.
I'm afraid it's over my head at the moment.
I need a little more info to get it right.
You have the Extended, High and the Low variant and actually the question is what must be there to make it work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to stop this for now. I'm quite frustrated and don't understand why this has to be so complicated.
Thank you for your patience I will try again tomorrow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well you're going to like this!
I wrote a program in OshenSoft AVR Basic this morning. See the code below. With the following result on the terminal. It's starting to look like something isn't right in GCB. I cannot draw any other conclusion.
Sorry good morning,
I didn't understand this yesterday. With the comment you just made.
Maybe this is because English is not my native language?
The attached files are those from yesterday's experiment.
Are you saying that LED is not turning off or on from the application?
Connect Terminal to the ttl/usb port. Reset the AVR board. Does the Terminal show the 'Small Basic Responder"? if not, you have not connected the TX between the chip and the USB/TTL
Indeed the LED does not want to go on or off via the software of the small basic program.
I'm just worried that my USB/TTL device isn't working properly! In my windows device manager there is also a text that PL2303HXA has been phased out since 2012.
So in other words I don't trust it! And another thing I also noticed that when I use the serial monitor in Arduino (just like the terminal of GCB) I see the message Com port busy.
So, all things considered, I'm afraid that we have a problem too. So I'm going to order a new USB/TTL first.
In the meantime I have also read the text below. What is the difference between serial and serial1?
Apparently you have to take this into account with the Leonardo! But it's not clear to me what exactly you should do with this.
https://www.arduino.cc/en/Main/Arduino_BoardLeonardo
Note that on the Leonardo, the Serial class refers to USB (CDC) communication; for TTL serial on pins 0 and 1, use the Serial1 class.
Could you tell me what the difference is?
You get a new USB/TTL and I will see if i still have a board.
The cdc refers to the USB capability. When the bootloader hand over to tje user code the usb ceases to work and the user must handle the USART.
It took a while, but now I have a new USB to TTL converter. This one works as it should and doesn't have the old problems I had before.
But I can't get the communication with the Arduino board and thus the ATmega32u4 going.
It works perfectly with the Arduino uno. So I don't understand what could be wrong with this one?
Let me explain what I've been doing in the meantime. I have reduced the code as far as possible to just establish communication between PC and board.
This means that I send a message back to the PC by means of "HserPrint. This code works flawlessly with the Uno but not with the Leonardo. (see the code below)
At the working Uno I see the message coming in via the Terminal of Great Cow Basic.
But not at the Leonardo board.
Ummm....
Try this - two defines to remap the UNO bit to the bits on the mega32u4
I do not see any difference. at this time.
Just to be clear, I'm not currently working with Aduino's bootloader! So I program the chip directly with my Atmel-ICE programmer. So in other words I use the Leonardo board purely as a test board. But it seems to me that this shouldn't matter?
What is the simplest way to know if I can communicate with the chip properly?
Can it get any simpler than this? Just to make sure it's not the chip or board?
Can you upload your ASM ? I need to see it.
See below!
What are the fuses you are setting?
Read in from Microchip Studio!
I am no expert on this chip but that looks like 8mHz... and the program is 16mHz
And, the ASM program is not setting the frequency in INITSYS.
As far as my knowledge goes, these are the basic settings for an Arduino. So I just kept this one. And from Microchip Studio you have no choice but this 8Mhz setting. Everything above 8Mhz will in principle agree with this setting.
I'm not an ASM expert either and I'm not sure what exactly you mean by the last comment?
Now I don't know where to look? What are my options?
OK.
You need to set the fuses to internal clock OSC RC, and, set the program to 8 MHz.
That could work, It will use the internal clock.
I do not understand this? The Arduino board runs at 16 Mhz. That's a fact.
It cannot be the intention that you change this to the internal clock.
Then you're going to bring the board down in its capabilities.
Or am I misunderstanding you now?
Ignore the UNO stuff. This is not a 328p.
So, write the hex with those fuses and the change to the program. Get the basic working first, then, later figure out ext osc.
Right now I don't know what I'm doing, and I hate that.
I'm just doing something and that has no basis.
I'm afraid it's over my head at the moment.
I need a little more info to get it right.
You have the Extended, High and the Low variant and actually the question is what must be there to make it work.
Select the drop down Low Sut CkSel select the Internal OSc RC, slowest time.
leave everything else as is.
Just did it but no results.
I'm going to stop this for now. I'm quite frustrated and don't understand why this has to be so complicated.
Thank you for your patience I will try again tomorrow.
Last setting!
Well you're going to like this!
I wrote a program in OshenSoft AVR Basic this morning. See the code below. With the following result on the terminal. It's starting to look like something isn't right in GCB. I cannot draw any other conclusion.
And I used this setting for the fuses.
My previous old settings.
Morning,
I did say GCB was not setting the OSC or handling Usart corre
correctly.
Upload the whole working project. Then, we
can resolve.
Sorry good morning,
I didn't understand this yesterday. With the comment you just made.
Maybe this is because English is not my native language?
The attached files are those from yesterday's experiment.
Sorry my error.
I want all the file in a ZIP from OshenSoft AVR Basic project. All the files in the OshenSoft AVR Basic in one zip.