AvrStudio 5 Programm zu groß für Attiny 13

Paul B. schrieb:
> Some sections of the file provided does not fit within the device
> memory.
Stell dir vor, so ein paar Zeilen würden da nicht draufgehen, dann wäre 
das Ding völlig unbrauchbar. Scheint also an deinem 
Code/Optimierung/IDE-Overhead zu liegen. Erzähl einfach mal mehr

Ingo L. schrieb:
....

Schon mal danke für deine Antwort!

Ich habe in einem älteren Beitrag mal gelesen dass es irgendeinen 
Optimizer geben soll und man den irgendwo einschalten soll... Habe es 
aber noch nicht gefunden...

> das Ding völlig unbrauchbar. Scheint also an deinem
> Code/Optimierung/IDE-Overhead zu liegen. Erzähl einfach mal mehr

Ich habe eigentlich nichts an den Standart Einstellungen verändert. Der 
Programmer wird erkannt, auch der Attiny13 wie es scheint (Device-ID).

Da ich bisher immer nur Arduinos und NodeMCUs verwendet habe kenne ich 
mich leider nicht gut mit AVR Studio aus.

Hoffe sehr dass ihr mir helfen könnt!

Mein WINAVR2010 sagt: 74 Byte.
Schau mal ins *.lss File, was ist die letzte Adresse.
Ungefähr ist die Codegröße auch die Größe der *.hex / 2,8.

Paul B. schrieb:
> Habe es
> aber noch nicht gefunden...
Project -> Properties -> AVR/GNU C Compiler -> Optimization = Os

Peter D. schrieb:
> Mein WINAVR2010 sagt: 74 Byte.
> Schau mal ins *.lss File, was ist die letzte Adresse.
> Ungefähr ist die Codegröße auch die Größe der *.hex / 2,8.

Auch dir danke für deine Antwort,

laut Windows Explorer hat die Hex Datei eine Größe von 9,20KB. Die .lss 
Datei ist  69,7KB groß.

Die .lss Datei lade ich hoch.

Dieter F.
> Du hast im AVR-Studio Einstellungen gemacht, welche nicht korrekt sind.
>
> Neues GCC-Projekt starten, ATTiny13A wählen, Code reinkopieren, F_CPU
> definieren (als erstes)
>
>

1

> #define F_CPU 1000000

2

> #include <avr/io.h>

3

> #include <util/delay.h>

4

>

>
> speichen und compilieren.

Klappt leider nicht, jetzt kommt auch noch Verifing Flash failed...

Paul B. schrieb:
> Die .lss Datei lade ich hoch.

Wurde offensichtlich mit abgeschalteter Optimierung übersetzt.

Stefan E. schrieb:
> Paul B. schrieb:
>> Die .lss Datei lade ich hoch.
>
> Wurde offensichtlich mit abgeschalteter Optimierung übersetzt.

Und wie schalte ich die an? ;-)

Paul B. schrieb:
> Und wie schalte ich die an? ;-)

-Os

Amateur schrieb:
> Die paar Zeilen sollten immer in den Attiny reingehen.

Nein, ohne Optimierung eben nicht. Dann kommt über die delay-Funktionen 
Float-Arithmetik mit rein.

Peter schrieb:
> Wo -OS?

Als Option im Compiler-Aufruf.

Paul B. schrieb:
> Und wie schalte ich die an? ;-)

Wurde dir doch von Ingo schon gesagt:

Ingo L. schrieb:
> Project -> Properties -> AVR/GNU C Compiler -> Optimization = Os
Studio 5 ist allerdings voller Fehler und Probleme. Wenns irgend geht, 
nimm Studio 7.

> Ingo L. schrieb:

>> AVR/GNU C Compiler

Diesen Punkt gibt es bei mir leider nicht.

Bei mir gibt es nur Build, Build Events, Toolchain, Memory, Device, 
Debugging, Advanced :-(

InFo schrieb:
> Wird das Programm erfolgreich kompilliert?
>
>
> Paul B. schrieb:
>> Programmer ist der hier:
> 
https://www.amazon.de/Programmer-USB-AVRISP-XPII-Compatible/dp/B00KM6ZA9I>>/ref=sr_1_2?ie=UTF8&qid=1494422266&sr=8-2&keywords=isp+programmer
>
> Im Titel steht AVRISP XPII compatible
> Ist es möglich, dass das ein China-clon des AVRISP mkII ist? Stimmen
> Verpackung, Lieferumfang und Gehäuseoberfläche mit den Bildern überein?

Also laut den Rezensionen funktioniert er einwandfrei mit AVR Studio, 
das wird direkt auf einer CD mitgeliefert... Auch die Treiber sind für 
AVR Studio.

Paul B. schrieb:
>> Ingo L. schrieb:
>
>>> AVR/GNU C Compiler
>
> Diesen Punkt gibt es bei mir leider nicht.
>
> Bei mir gibt es nur Build, Build Events, Toolchain, Memory, Device,
> Debugging, Advanced :-(

Könnt ihr mir sagen wo ich den Punkt von Ingo finde?

Wäre sehr dankbar wenn ich es ans laufen bekomme...

Hallo,

es funktioniert :-).

Die LED blinkt. Habe jetzt gerade die (Programmier-) Kabel fest an einen 
Sockel gelötet, jetzt kann ich leichter zwischen Schaltung u. 
Programmieren wechseln.


Jetzt kann ich mit dem AVR Studio lernen anfangen :-)

Stefan U. schrieb:
> AVR Studio 7 ist kostenlos, wenn du dafür keinen neuen Computer kaufen
> musst. Das war bei mir der Grund, Alternativen auszuprobieren.

Bei mir läuft Win7 in einer Virtuellen Maschine (Parallels unter OSX),
habe leider noch nichts vergleichbares wie AVR Studio für Mac gefunden, 
auch die Treiberinstallation ist dort komplizierter (aber nur für 
Mikrocontroller!!!)

Gibt es so was:
https://www.conrad.de/de/usb-programmer-myavr-mymultiprog-mk2-bausatz-191522.html?gclid=CNLisJX35dMCFYK77QodaKELKw&insert_kz=VQ&ef_id=WEEMPAAAAcD@h@Rf:20170510181449:s

schon für ISP Programmer (vllt. hat das jmd. sogar selbst gebaut?), also 
ich meine eine Platine mit allen möglichen Sockeln die dann richtig 
verbunden sind?

Dieter F. schrieb:
> Oh, ich bin nicht der einzige 7.0-Nutzer hier :-)
Mögl. doch :-P Bei mir läuft noch Studio 4. Ich bin aber auch ein zäher 
Kunde.
>
> Aber das geht auch in 5.0 oder 6.x.

Meine Versuche mit 5.0 haben mich dazu gebracht, wieder auf Studio 4 
zurückzugehen. Aber schon Version 6 ist deutlich besser als die 
berüchtigte Nummer 5.

Dieter F. schrieb:
> Paul B. schrieb:
>> es funktioniert :-)
>
> Schön, was hast Du gemacht?

Toolchain/AVR.../Debugging/Other debugging flags (AVR Studio 5), da dann 
die Zeile von oben eingeben (-Os)

Dieter F. schrieb:
> Paul B. schrieb:
>> Toolchain/AVR.../Debugging/Other debugging flags (AVR Studio 5), da dann
>> die Zeile von oben eingeben (-Os)
>
> Und warum hattest Du dann den Default-Wert -O1 überschrieben? Nur so,
> als Information ...

Du fragst mich Sachen...

Dieter F. schrieb:
> Und warum hattest Du dann den Default-Wert -O1 überschrieben?

Ich wäre mir da nicht so sicher, dass er was überschrieben hat. Ich 
meine mich zu erinnern, dass es eine der "Unarten" von Version 5 war, 
beim Debug-Target mit -O0 zu übersetzen.

Jetzt das nächste Problem:

Wollte gerade eine fertige .hex Datei aus dem Internet (für Attiny 13) 
auf den Attiny übertrage. Habe deswegen im Flash Dialog des LED Blink 
Projekts einfach eine andere .hex Datei ausgewählt. Leider klappt das 
nicht.


Gibt es eine andere Möglichkeit bzw. woran liegt es?

Einfach was kopieren ist nicht immer möglich.

Du benötigst dafür auch exakt die gleiche Hardware.

Nimmst Du ein "Blink"-Programm das definitiv funktioniert und kopierst 
es auf andere Hardware, kann es leicht sein, dass da nichts blinkt.

Es reicht schon aus einen anderen Port zu verwenden.

Sebastian S. schrieb:
> Einfach was kopieren ist nicht immer möglich.
>
> Du benötigst dafür auch exakt die gleiche Hardware.
>
> Nimmst Du ein "Blink"-Programm das definitiv funktioniert und kopierst
> es auf andere Hardware, kann es leicht sein, dass da nichts blinkt.
>
> Es reicht schon aus einen anderen Port zu verwenden.


Es klappt ja gar nicht das Programm zu flashen.

Paul B. schrieb:
> Es klappt ja gar nicht das Programm zu flashen.

- Hast du die Tiefkühltruhe wieder verschlossen?
- Ist der Backofen vorgeheizt?
- Die Pizza aus der Verpackung genommen?

Alles ja? Hm. Dann weiß ich auch nicht, warum der Flashvorgang nicht 
klappt.

Noch eine Frage:

Wollte jetzt gerade mein erstes Programm selber schreiben.

Wollte wie hier im AVR Tutorials die include Dateien einbinden 
(tn13Adef.inc), auch im Include Pfad unter Project Options habe ich den 
Ordner mit einbezogen:

Hier mein Versuch:


#include <avr/io.h>
#include "tn13Adef.inc"

sb1 ddrb, 1


Es scheitert daran dass er die Include Datei nicht findet. Gibt es da 
einen Trick?

Und: mit .include wie im AVR tutorial habe ich es auch probiert...

Unterscheide zwischen C und Assembler und schwöre sämtliche Stimmen in 
deinem Kopf auf eins davon ein.

Paul B. schrieb:
> #include <avr/io.h>
> #include "tn13Adef.inc"

Lass das 2. Include weg, das wird nicht gebraucht bzw. ist falsch. 
Weder in C noch uin C++ noch in (GNU)-Assembler.

Johann L. schrieb:
> Paul B. schrieb:
>> #include <avr/io.h>
>> #include "tn13Adef.inc"
>
> Lass das 2. Include weg, das wird nicht gebraucht bzw. ist falsch.
> Weder in C noch uin C++ noch in (GNU)-Assembler.

Also kann ich die Pins einfach so "anschalten"?

Paul B. schrieb:
> Also kann ich die Pins einfach so "anschalten"?

Paul, du mischst da zwei Sachen miteinander, nämlich C und Assembler.
In C reicht es aus,

1

#include <avr/io.h>

zu schreiben, da der Build Prozess sich die benötigte Definition des 
benutzten Prozessors selber raussucht, die er aus den 
Projekteinstellungen weiss.
In Assembler ist das anders, da schreibst du am Anfang z.B.

1

; this is for the ATtiny 13

2

.NOLIST                ; Disable listfile generation 

3

.include "tn13def.inc"

4

.LIST

Der Tiny13A unterscheidet sich im Programmiermodell nicht vom 13 ohne A, 
deswegen inkludiert man die o.a. Datei.

Matthias S. schrieb:
> Paul B. schrieb:
>> Also kann ich die Pins einfach so "anschalten"?
>
> Paul, du mischst da zwei Sachen miteinander, nämlich C und Assembler.
> In C reicht es aus,

1

> #include <avr/io.h>

> zu schreiben, da der Build Prozess sich die benötigte Definition des
> benutzten Prozessors selber raussucht, die er aus den
> Projekteinstellungen weiss.
> In Assembler ist das anders, da schreibst du am Anfang z.B.

Kommt auf den Assembler an.  Im GNU-Assembler schreibt man:

1

#include <avr/io.h>

Und mit nicht-GNU würd ich erst garnicht anfangen...

Johann L. schrieb:
> Kommt auf den Assembler an.  Im GNU-Assembler schreibt man:
> #include <avr/io.h>
> Und mit nicht-GNU würd ich erst garnicht anfangen...

Aber nur, wenn du da den Präprozessor auch drüber laufen lässt, sonst 
kommst du mit #define und #include nicht weit.

Nicht-Gnu respektive Atmel-Assembler ist im Atmel Studio komischerweise 
der Standard ;)

Oliver

Dieter F. schrieb:
> es sollte ungefähr so aussehen
> (Siehe Bild)

Nein, so sollte es sicherlich nicht aussehen (das worauf der rote Pfeil 
zeigt).

Johann L. schrieb:
> Und mit nicht-GNU würd ich erst garnicht anfangen...

Ah, anscheinend ein Linux Fuzzi. Hier gehts um Atmel Studio 5 mit dem 
AVR Assembler. Für Windows. Mit AVRASM. Oder AVRASM2. Ohne GNU.

Matthias S. schrieb:
> Johann L. schrieb:
>> Und mit nicht-GNU würd ich erst garnicht anfangen...
>
> Ah, anscheinend ein Linux Fuzzi. Hier gehts um Atmel Studio 5 mit dem
> AVR Assembler. Für Windows. Mit AVRASM. Oder AVRASM2. Ohne GNU.

Und wieso geht es damm um Optimierungen?

Matthias S. schrieb:
> Johann L. schrieb:
>> Und mit nicht-GNU würd ich erst garnicht anfangen...
>
> Ah, anscheinend ein Linux Fuzzi. Hier gehts um Atmel Studio 5 mit dem
> AVR Assembler. Für Windows. Mit AVRASM. Oder AVRASM2. Ohne GNU.

Nein. Stell dir mal vor: Die GNU-Tool laufen sogaaar und Windows.  Und 
unter MacOS und unter... Auch wenn is nicht in dein Weltbild passt.

Johann L. schrieb:
> Und wieso geht es damm um Optimierungen?

Wir waren schon längst woanders. Wenn ich dich erinnern darf:

Matthias S. schrieb:
> Paul B. schrieb:
>> Also kann ich die Pins einfach so "anschalten"?
>
> Paul, du mischst da zwei Sachen miteinander, nämlich C und Assembler.
> In C reicht es aus,#include <avr/io.h>
> zu schreiben, da der Build Prozess sich die benötigte Definition des
> benutzten Prozessors selber raussucht, die er aus den
> Projekteinstellungen weiss.
> In Assembler ist das anders, da schreibst du am Anfang z.B.; this is for
> the ATtiny 13
> .NOLIST                ; Disable listfile generation
> .include "tn13def.inc"
> .LIST
> Der Tiny13A unterscheidet sich im Programmiermodell nicht vom 13 ohne A,
> deswegen inkludiert man die o.a. Datei.

Johann L. schrieb:
>> Ah, anscheinend ein Linux Fuzzi. Hier gehts um Atmel Studio 5 mit dem
>> AVR Assembler. Für Windows. Mit AVRASM. Oder AVRASM2. Ohne GNU.
>
> Nein. Stell dir mal vor: Die GNU-Tool laufen sogaaar und Windows.  Und
> unter MacOS und unter... Auch wenn is nicht in dein Weltbild passt.
Ach?

Du hast anscheinend nicht verstanden, worum es geht. Paul hat Atmel 
Studio unter Windows installiert. Da ist der AVRASM bei. Der AVRASM ist 
eben kein GNU Assembler und versteht dewegen das hier:

1

.NOLIST                ; Disable listfile generation

2

.include "tn13def.inc"

3

.LIST

Nun verstanden?
Das hat nichts mit Weltbild oder so zu tun. Bei mir laufen in munterer 
Vielfalt Debian Linux, WindowsXP und 7, MacOS 7, MacOS 9 und MacOSX...

Matthias S. schrieb:
> Johann L. schrieb:
>> Und mit nicht-GNU würd ich erst garnicht anfangen...
>
> Ah, anscheinend ein Linux Fuzzi. Hier gehts um Atmel Studio 5 mit dem
> AVR Assembler.

Ok, hab ich jetzt nirgend gelesen, sondern nur dass C verwendet wurde. 
Und wenn man C mit Assembler kombinieren will, dann scheidet der 
Atmel-Assembler schlichtweg aus.

Das ist auch der Grund, warum es in einem neuen Projekt nicht zweckmäßig 
ist, mit Atmel-Assembler anzufangen -- außer eben aus Faulheit weil's 
eben die Voreinstellung in Atmel Studio ist.

Weil der Code vom Atmel-Assembler inkompatibel mit avr-gcc ist, kann man 
also später das Projekt nicht mit C kombinieren.

Und wenn man das erklärt, ist man gleich ein Linux-Fuzzi?