Verschil in HEX grootte

Ik kwam er achter met mijn neef die in BASCOM (BASIC) programmeert dat de HEX files die de Arduino IDE produceert vele malen groter zijn dan die van BASCOM.
Een test met ons programmaatje waarmee je met een druk op de knop een ASCII code verzend op de seriële poort kwam tot de schokkende uitkomst:
Arduino: 1868 bytes
BASCOM: 658 bytes

Dat is een behoorlijk verschil als je een ATTiny2313 gebruikt met maar 2048 bytes!

Die ervaring heb ik ook.

Moet wel zeggen dat ik geen uitgebreide identieke programma's in zowel bascom als arduino geschreven heb en dus ook niet weet voor hoever de vergelijking dan nog opgaat. Als "afgekickte Basic-verslaafde" ga ik wel voor C++, daar de ondersteuning talloze malen groter is. Google maar eens wat met Bascom erbij of met Arduino. Onder die laatste houd het aantal resultaten haast niet op.

Gelukkig kan ik duits, daar is redelijk wat te vinden voor Bascom-projectjes. In Oost-europesche landen en Rusland is ook het een en ander te vinden, maar het doorspitten van vertaalde pagina's levert me teveel hoofdpijn op..

Wat ik serieus mis bij Arduino is het gemak waarmee je zo'n beetje elke... 8 bit AVR-controller kan gebruiken. Bij Bascom heb je geen gemekker met zoeken naar bootloaders en specifieke instellingen. Onder Bascom kan je zelfs 8051-controllers gebruiken en zo'n beetje alle instellingen zijn een fluitje van een cent. Foutjes, waardoor de controller zonder HV-programmer niet meer te herstellen is, zijn helaas ook sneller gemaakt.

Op zich heb ik nog een stapeltje 2313's en die... programmeer ik met Bascom. Verder ben ik verknocht aan de Atmega8. Zo'n beetje de goedkoopste, net wat meer ruimte, net wat meer pootjes en standaard onder Arduino te gebruiken.

Het viel ons gewoon op dat een simpel programma als Blink al zoveel verschil maakte. Dat je met de Arduino software "ook" voor de Tiny's kan programmeren is mooi meegenomen, maar niet optimaal dus.

Tijd om echt die-hard C te leren programmeren voor die chips. Of gewoon voor de iets duurdere Mega's te gaan. :slight_smile:
Maar het is ook wel een goede les om echt te leren programmeren onder geheugen-arme omstandigheden!
Doet me een beetje denken aan de tijd dat ik websites maakte die door een 56K modem (of nog minder) moesten. Daar ging je op elke byte letten. Nu heeft vrijwel iedereen breedband, dus kijk je niet meer zo erg naar de grootte van de JPG's die in je site hangen... (Tenzij je een mobiele website maakt)

armandzwan:
Tijd om echt die-hard C te leren programmeren voor die chips.

Arduino is gewoon C/C++. Dus Arduino programmeren is "die-hard C programmeren".
Arduino is gewoon een set functies (in een framework) die het leven gemakkelijker maken. Alle code is open source dus je kan makkel?k de "geheugen gebruikende code" verwijderen.
Een voorbeeld van "geheugen verslindende code" is de String klasse. Gebruik je geen variabelen van het type String en je spaart heel wat uit omdat de compiler dan de String klasse niet mee neemt in de hex file.
Natuurlijk is er ook een framework en dat neemt ook plaats. Als je het merendeel van het framework echter gebruikt kom je vaak beter uit om het gewoon te gebruiken.
Gezien je ervaring zal je zelf wel weten dat het niet altijd makkelijk is om te kiezen tussen aanpassen of opnieuw beginnen.
Met vriendelijke groet
Jantje

Hier is de Engelse versie van dit draadje:

Zo te zien is het dus zeer wel mogelijk om je programma erg klein te maken. Maar dan moet je natuurlijk een hoop zelf doen...

Het is altijd weer het bekende verhaal... Hoe meer er voor je gedaan wordt, hom duurder het is in resources. Als afstammeling van het machine code/assemblertijdperk leer je gauw genoeg dat sommige programma's vrij duur zijn in resource gebruik. Dit omdat er nu eenmaal een aantal zaken standaard worden opgezet terwijl ze dat mogelijk helemaal niet nodig hebben. Blink is zo'n voorbeeld. Amper statements en toch vrij veel code. Ik dank dat als iemand er een assembly programma van maakt dat het nog veel minder wordt. Mooiste voorbeeld die ik nog kan herinneren was een schaakprogramma op mijn KIM-1 [1976](6502 processor) dat moest draaien in 1K ram geheugen waar dan nog wel wat routines weren gebruikt uit het toch wel 2K ROM geheugen (iets van 10%). Dat schaak programma kon 8 levels diep vooruit rekenen. Oh ja en van die 1K RAM had je eigenlijk effectie 512 bytes ter beschikking.
Datzelfde programma zou tegenwoordig vermoedelijk vele kilobytes nodig hebben....
Maar ook de performance lijdt onder de extra toeters en bellen... Mooi voorbeeld was de intropducite van de 4GL talen in de 80'er jaren. Alles was veel eenvoudiger voor de gebruiker.... maar ook veel langzamer......En ondanks alle optimizers ten spijt.... stnadaardisatie heeft nu eenmaal zijn prijs.