Arduino IDE produceert andere Hex-file dan Atmel Studio ?

[kitao]

Mijn vraag
Zie topic titel en hoe dit op te lossen en hoe dit kan.
Relevante software en hardware die ik gebruik
Zie topic titel + Simulide
Wat ik al gevonden of geprobeerd heb
https://www.visualmicro.com/forums/YaBB.pl?num=1529594395
Zie laatste post daarvan. Is echter uit 2018 en welke versies er nu met elkaar compatibel zouden zijn weet ik niet.
In Atmel laad ik dit programma :
https://raw.githubusercon...LED/master/MyAtmelBlink.c
In Arduino IDE laad ik datzelfde programma.
Beiden compileren goed.
Helaas zit er een klein verschil in de respectievelijke hex-files. Het is niet veel verschil maar genoeg om de Atmel hex in Simulide een slechte led-output te geven terwijl de Arduino Ide Hex prima draait.

Hex Arduino IDE

code:

:100000000C9434000C943E000C943E000C943E0082
:100010000C943E000C943E000C943E000C943E0068
:100020000C943E000C943E000C943E000C943E0058
:100030000C943E000C943E000C943E000C943E0048
:100040000C943E000C943E000C943E000C943E0038
:100050000C943E000C943E000C943E000C943E0028
:100060000C943E000C943E0011241FBECFEFD8E04C
:10007000DEBFCDBF0E9440000C944F000C940000E6
:100080003D9A90E288B1892788B92FEF39E688E157
:10009000215030408040E1F700C00000F3CFF894D9
:0200A000FFCF90
:00000001FF

Hex Atmel

code:

:100000000C9434000C943E000C943E000C943E0082
:100010000C943E000C943E000C943E000C943E0068
:100020000C943E000C943E000C943E000C943E0058
:100030000C943E000C943E000C943E000C943E0048
:100040000C943E000C943E000C943E000C943E0038
:100050000C943E000C943E000C943E000C943E0028
:100060000C943E000C943E0011241FBECFEFD8E04C
:10007000DEBFCDBF0E9440000C944F000C940000E6
:100080003D9A90E288B1892788B92FE936E881E066
:10009000215030408040E1F700C00000F3CFF894D9
:0200A000FFCF90
:00000001FF

Regel 9 zit verschil in.

[kitao]

Inmiddels in Atmel Studio 7 via Help gekeken voor updates. Die bleken er te zijn, het heet nu Microchip Studio.
Deze geïnstalleerd (duurde wel een uur) en daarmee werd Atmel Studio 7 overschreven / vervangen door Microchip Studio.
De hex-file die daar uit komt rollen (in mapje debug) is nog slechter

code:

:100000000C9434000C943E000C943E000C943E0082
:100010000C943E000C943E000C943E000C943E0068
:100020000C943E000C943E000C943E000C943E0058
:100030000C943E000C943E000C943E000C943E0048
:100040000C943E000C943E000C943E000C943E0038
:100050000C943E000C943E000C943E000C943E0028
:100060000C943E000C943E0011241FBECFEFD8E04C
:10007000DEBFCDBF0E9440000C9451000C940000E4
:1000800087B1806287B998B180E2892788B92FE962
:1000900086E891E0215080409040E1F700C00000E8
:0600A000F2CFF894FFCF3F
:00000001FF

Hoe kunnen programma's van een dezelfde code, zie hieronder, meerdere verschillende hex-files maken ???

https://raw.githubusercon...LED/master/MyAtmelBlink.c

Het blink voorbeeld komt hiervandaan
YouTube: Atmel Programming Tutorial 1 - 1st Programming and Blink a LED
Github pagina staat eronder.

Verschil tussen zijn opstelling en de mijne is dat de mijne een virtuele gesimuleerde 328 is.
Dat verklaart voor mij echter nog niet waarom de hex-files maar liefst 3x van elkaar verschillen.

Ik heb ook nog Visual Studio aanwezig staan. Heb even geprobeerd maar het project builden is daar iets anders en ben vergeten hoe dat ook alweer ging. Zal een andere dag worden en waarschijnlijk een volgende mutatie no. 4 als ik het zo bekijk. Lijkt wel roulette waar het balletje nu weer op belandt.
.

[ Voor 27% gewijzigd door kitao op 21-01-2021 22:28 ]

[kitao]

Importeren is dan wel gelukt zonder problemen en draait ook goed.
YouTube: Importing Arduino Sketches Into Atmel Studio 7
Het is een begin maar heb je nog steeds twee Ide's voor nodig.
Atmel Studio 7 of sinds kort Microchip Studio geeft dan iets meer voordeel kwa debug mogelijkheden.

[RobIII]

kitao schreef op donderdag 21 januari 2021 @ 22:01:
Hoe kunnen programma's van een dezelfde code, zie hieronder, meerdere verschillende hex-files maken ???

Sterker nog: strict gezien is het niet eens gegarandeerd dat een enkele compiler 2 keer dezelfde output genereert bij dezelfde input. Ook kan je applicatie code bevatten die undefined behaviour triggered in een compiler. Het is aan compilers om machinecode te genereren zodat het higher level concept (je while lus bijvoorbeeld) vertaald wordt in machine code; daarbij kun je vaak verschillende aanpakken kiezen of bepaalde optimalisaties toepassen en dus kan het voorkomen dat compiler A andere code genereert dan compiler B. Uiteraard moet dat wel "binnen de regels" zodat de output (het programma) dezelfde, 'intended', werking blijft houden. De vraag is dan ook: waarom ben je überhaupt "zoek de verschillen" aan 't spelen? Heb je een concreet probleem met de output? Werkt je programma wel als het gecompiled wordt met compiler A en niet met compiler B?

[ Voor 16% gewijzigd door RobIII op 22-01-2021 10:02 ]

[SymbolicFrank]

Je kunt meestal via een parameter de compiler ook een tekstbestand met de assembly laten genereren. Kijk of je dat aan kunt zetten en post de bestanden die daar uitkomen.

[Comp-Freak]

kitao schreef op donderdag 21 januari 2021 @ 19:27:
Helaas zit er een klein verschil in de respectievelijke hex-files. Het is niet veel verschil maar genoeg om de Atmel hex in Simulide een slechte led-output te geven terwijl de Arduino Ide Hex prima draait.

In lijn met wat RobIII al zegt: verschillende compilers of andere instellingen zullen andere machinecode opleveren voor exact dezelfde code. De build omgeving en compiler in de Arduino IDE is heel anders dan wanneer je AVR-GCC gebruikt in Atmel studio. Met Microchip studio heb je ook nog eens de optie om te wisselen naar Michrochips XC8 compiler.

Uiteraard mooi en leerzaam dat je naar je machinecode (en assembly?) kijkt en het vergelijkt met je eigen code, maar in dit geval lijkt het vooral dat je probeert om een brakke simulator/emulator heen te werken die niet alle machinecode even goed emuleert. Dat wil niet zeggen dat de uitvoer van een compiler en assembler "nog slechter" is.

Dus dat er verschillen zijn ligt in de lijn der verwachting. Het probleem dat je ondervind kan je dus oplossen door óf een andere simulator/emulator* te kiezen, óf bewust een bepaalde toolchain te gebruiken omdat je perse wil simuleren, óf uit te vogelen waarom bij bepaalde uitvoer je simulator faalt.

*: je kunt hetzelfde bereiken door een debugger op je hardware aan te sluiten. Dan draait je code in ieder geval op de echte hardware.

[kitao]

RobIII schreef op vrijdag 22 januari 2021 @ 09:53:
[...]

Sterker nog: strict gezien is het niet eens gegarandeerd dat een enkele compiler 2 keer dezelfde output genereert bij dezelfde input. Ook kan je applicatie code bevatten die undefined behaviour triggered in een compiler. Het is aan compilers om machinecode te genereren zodat het higher level concept (je while lus bijvoorbeeld) vertaald wordt in machine code; daarbij kun je vaak verschillende aanpakken kiezen of bepaalde optimalisaties toepassen en dus kan het voorkomen dat compiler A andere code genereert dan compiler B. Uiteraard moet dat wel "binnen de regels" zodat de output (het programma) dezelfde, 'intended', werking blijft houden. De vraag is dan ook: waarom ben je überhaupt "zoek de verschillen" aan 't spelen? Heb je een concreet probleem met de output? Werkt je programma wel als het gecompiled wordt met compiler A en niet met compiler B?

Heb je een concreet probleem met de output? Werkt je programma wel als het gecompiled wordt met compiler A en niet met compiler B?

Ja, dat klopt. Ik zal nog eens de opzet uitvouwen. Ik heb als simulatieprogramma Simulide
https://www.simulide.com/p/home.html
Daar zit een hele riks Pic's in en Avr's en Arduinobordjes. Ik gebruik Simulide als experimenteerbord om wat elektronica bij te leren want heb het geduld en de motivatie niet meer om het op breadboards uit te proberen. Ik heb hier nog wel aardig wat echte componenten liggen maar heb die in een paar dozen opgeborgen. Dit terzijde maar ben dus enkel met sims bezig, ook met de Proteus demo-versie.

Daarnaast probeer ik opnieuw weer wat assembly op te pakken dus heb daar ook een Ide voor nodig. Zo ben ik destijds bij Atmel Studio terecht gekomen als IDE.

Afin, lang verhaal kort, ik probeer gisteren de eerder genoemde video na te bouwen en led knipperde wel in Simulide maar veels te snel. Ik probeer dat zelfde programma van die meneer uit in de Arduino Ide en led knippert gewoon goed. Dus ging ik zoeken naar de verschillen en kwam tot de conclusie dat de verschillen in de hex-files zitten. De micro's in de sim worden namelijk met een hex-file 'gefirmwared'.
Maar jij en Comp-Freak leggen dus mooi uit dat dit niet perse het geval hoeft te zijn. En het blijkt nu dat je gelijk hebt. Vandaag zit ik namelijk zijn tweede video te bekijken en daar gaat het over de klok.

YouTube: Atmel Programming Tutorial 2 - Fuses and Using an External Oscillator

Heb de simulatie atmega328 klok van 16 Mhz op 8 gezet, led ging nog steeds veels te snel maar op 1Mhz draait het helemaal prima. Het lag dus helemaal niet aan de hex-files maar aan een verkeerde kloksnelheid.

@Comp-Freak
Ook jij bedankt voor je antwoord. Maar makkelijk gezegd van kies maar een goeie simulator. Geld groeit hier niet aan de boom zoals mss bij jou wel. Anyway, bedankt voor je inbreng en je tips

@SymbolicFrank
Ik weet niet helemaal precies wat je bedoelt maar voorlopig kan ik weer vooruit. Tnx

Al weet ik nog steeds niet helemaal waarom de kloksnelheid voor de Arduino Ide blijkbaar geen verschil maakt of die stond wellicht al op 16Mhz. Maar dat is iets voor een andere keer.

[ Voor 5% gewijzigd door kitao op 22-01-2021 16:13 ]

[jammo]

Het verschil in kloksnelheid kan komen door

code:

#ifndef F_CPU                   // if F_CPU was not defined in Project -> Properties
#define F_CPU 1000000UL         // define it now as 1 MHz unsigned long
#endif

Als F_CPU al gedefinieerd is (met een andere waarde) gebruik je een andere clock snelheid dan die je hier probeert te definiëren.

Probeer daar eens

code:

#ifdef F_CPU
#undef F_CPU
#define F_CPU 1000000L
#endif

[SymbolicFrank]

Het C programma wordt omgezet in machine code, de code die rechtstreeks door de microcontroller wordt uitgevoerd. Assembly is daar de leesbare versie van.

De meeste compilers kun je zo configureren, dat ze een bestandje maken met die code er in. Dan kun je vergelijken wat ze gedaan hebben.

[kitao]

jammo schreef op vrijdag 22 januari 2021 @ 16:39:
Het verschil in kloksnelheid kan komen door

code:

#ifndef F_CPU                   // if F_CPU was not defined in Project -> Properties
#define F_CPU 1000000UL         // define it now as 1 MHz unsigned long
#endif

Als F_CPU al gedefinieerd is (met een andere waarde) gebruik je een andere clock snelheid dan die je hier probeert te definiëren.

Probeer daar eens

code:

#ifdef F_CPU
#undef F_CPU
#define F_CPU 1000000L
#endif

Ok, bedankt voor het meekijken
Heb jouw bovenste code uit gecomment en daaronder jouw onderste code gezet (in Microchip Studio).
Dit geeft foutmelding :
Severity Code Description Project File Line
Warning #warning "F_CPU not defined for <util/delay.h>" [-Wcpp] AtmelBlink30 c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\util\delay.h 92

Het instellen van de klok vindt trouwens plaats in Simulide zelf, misschien/waarschijnlijk dat het via een externe code-aansturing helemaal geen invloed daarop heeft. Een kristal zit er bijvoorbeeld niet in om zelf een externe klok op de micro te kunnen zetten. Toch is het best een leuk programma en heb er eerder best uitgebreide schakelingen mee opgebouwd.



In het vak linksboven wordt de klok ingesteld als Mhz.

Ben er een tijdje uitgeweest, heb er iets meer dan anderhalfjaar niets meer aan gedaan en ben vrijwel alles vergeten. Deze regel vanuit het origineel was mij niet eens opgevallen bijvoorbeeld en al helemaal niet dat het over de klok ging. Excuus daarvoor.

#define F_CPU 1000000UL // define it now as 1 MHz unsigned long

[ Voor 10% gewijzigd door kitao op 23-01-2021 12:49 ]

[kitao]

SymbolicFrank schreef op vrijdag 22 januari 2021 @ 20:12:
Het C programma wordt omgezet in machine code, de code die rechtstreeks door de microcontroller wordt uitgevoerd. Assembly is daar de leesbare versie van.

De meeste compilers kun je zo configureren, dat ze een bestandje maken met die code er in. Dan kun je vergelijken wat ze gedaan hebben.

Ja bedankt, kwam er hier iets over tegen
https://www.microchip.com/forums/m951787.aspx
kan het momenteel even niet reproduceren maar geeft niet, ik gebruik momenteel WinApe. Dat is wat speelser zeg maar. Althans, in combinatie met deze website

https://chibiakumas.com/

En ook bedankt voor je Pdf, is tenminste geen 600+ pagina encyclopedie

Ps, het eerste voorbeeldje uit dat boek ..

code:

.NOLIST
.INCLUDE "8515def.inc"
.LIST

loop:

    RJMP loop

.. compileert inmiddels ook op microchip studio. Dus komt van pas

@SymbolicFrank
Loopt toch nog niet helemaal lekker. Heb een andere pdf gevonden die beter aansluit bij Studio hoop ik
HANDLEIDING AVR-ASSEMBLER PROGRAMMEREN - 25 september 2018
https://ds.opdenbrouw.nl/inlmic/handleiding_INLMIC.pdf

Ja, ik had ook het programma uit jouw pdf kunnen downloaden maar heb er al een paar staan, raakt vol hier.
Misschien later met wat meer oefening dat ik het alsnog kan inzetten.

*********

Mooi, die draait, dit zocht ik al twee dagen



In de handleiding hierboven staat :
Selecteer bij Selected debugger/programmer JTAGICE mkII en bij interface JTAG
Kies in plaats daarvan simulator

Bedankt voor dat extra zetje Frank, het heeft geholpen
.

[ Voor 36% gewijzigd door kitao op 23-01-2021 14:46 ]

[kitao]

Comp-Freak schreef op vrijdag 22 januari 2021 @ 13:28:
[...]


In lijn met wat RobIII al zegt: verschillende compilers of andere instellingen zullen andere machinecode opleveren voor exact dezelfde code. De build omgeving en compiler in de Arduino IDE is heel anders dan wanneer je AVR-GCC gebruikt in Atmel studio. Met Microchip studio heb je ook nog eens de optie om te wisselen naar Michrochips XC8 compiler.

Uiteraard mooi en leerzaam dat je naar je machinecode (en assembly?) kijkt en het vergelijkt met je eigen code, maar in dit geval lijkt het vooral dat je probeert om een brakke simulator/emulator heen te werken die niet alle machinecode even goed emuleert. Dat wil niet zeggen dat de uitvoer van een compiler en assembler "nog slechter" is.

Dus dat er verschillen zijn ligt in de lijn der verwachting. Het probleem dat je ondervind kan je dus oplossen door óf een andere simulator/emulator* te kiezen, óf bewust een bepaalde toolchain te gebruiken omdat je perse wil simuleren, óf uit te vogelen waarom bij bepaalde uitvoer je simulator faalt.

*: je kunt hetzelfde bereiken door een debugger op je hardware aan te sluiten. Dan draait je code in ieder geval op de echte hardware.

De Simulide is gratis en kunnen best leuke dingen mee gemaakt worden. Ja, je moet regelmatig opslaan, stort nogal eens in maar tenminste kan er opgeslagen worden, wat in Proteus demo niet kan. Evenmin geeft P in de demo toegang tot micro's. En de goedkoopste versie P is € 200,- . Daar krijg je een Arduino omgeving voor.
https://www.labcenter.com/pricing/
Dat ik best graag wil hebben maar komt nu even niet goed uit die twee flappen die je er voor neer moet leggen.
Heb vanmorgen een Simulide opstelling aan elkaar geknoopt, volgens andermans schema althans.
En dat draait best goed hoor, reageert op ieder knopje en ook zoals het de bedoeling zou moeten zijn volgens de schemamaker.

Mocht jij trouwens nog een simulator weten dan hoor ik dat graag van je.
LTSpice heb ik al staan, maar ik weet niet of zoiets als dit hieronder daar ook gaat.

kitao in "Het grote 'breadbord computer' topic"