Migration von Arduino zu AVRStudio4 (AVRToolchain)

schmeiss doch einfach den Bootloader raus und den BOOTRST vektor

oder nur den BOOTRST vektor dann kannst du leicher zurück, kannst aber 
auch den Bootsektor sichern.

und dann gehst wie immer

1

#define AUSL_DDR      DDRD

2

#define AUSL_LED_PORT  PORTD

3

#define _camAUS      1      // PD1

4

#define _camAF        0      // PD0

5

#define CAM_F        6

6

#define CAM_S        7

7

8

if(!(AUSL_DDR & (1 << _camAUS | 1 << _camAF)))

9

{  AUSL_DDR |= (1 << _camAUS | 1 << _camAF);

10

  AUSL_LED_PORT &= ~(1 << _camAUS | 1 << _camAF);

11

}

12

AUSL_LED_PORT |= (1 << _camAUS);

1

#include <avr/io.h>

2

3

#define OUTPUTPIN    PB7

4

#define OUTPUTPORT_DIRECTION  DDRB

5

#define OUTPUTPORT_WRITE  PORTB

6

#define OUTPUTPORT_READ    PINB

7

8

void main (void) {

9

10

  OUTPUTPORT_DIRECTION = 0x00 | (1<<OUTPUTPIN);

11

  OUTPUTPORT_WRITE |= (1<<OUTPUTPIN);

12

13

  while(1) {

14

15

  }

16

}

glaub der Code ist soweit fein - der soll nur einmalig einen hoch 
bekommen, dann gehts weiter mit Timer und Toggle.

1

schmeiss doch einfach den Bootloader raus und den BOOTRST vektor

2

3

oder nur den BOOTRST vektor

^^ja, so hat ichs mir gedacht, aber wie ... aber wie? Dachte mit 
BOOTRST-fuse auf 0 wärs getan :p

aktuelle Fusesetting:

efuse: 0xFF
hfuse: 0x99
lfuse: 0xEF

<=>

CKSEL0-3 = 0 (external Clock)
BOOTRST = 0
BOOTSZ0 = 1
BOOTSZ1 = 1

EESAVE = 0
WDTON = 0
SPIEN = 1
JTAGEN = 1
SUT0 = 1 (glaub das hieß Softstart)
SUT1 = 0

Robert T. schrieb:

> ^^ja, so hat ichs mir gedacht, aber wie ... aber wie? Dachte mit
> BOOTRST-fuse auf 0 wärs getan :p

Ist es auch.
Sicher, dass du am richtigen Pin misst?

Nuja - hab jetzt nicht den ohmschen von Bord- zu uC-Pin gemessen - werd 
heut abend versuchen, mal alle Hände in die Luft zu heben (bis auf die 2 
Leitungen zum USB-uC, die sonst kollidieren könnten), dann sollten 
diverse Pins ja mit hoch gehen.

Das Pin-Mapping ist eigentlich in 
https://www.arduino.cc/en/Hacking/PinMapping2560 beschrieben (das 
Sainsmart Bord ist Arduino-kompatibel, sodass zB. PB7 mit der LED "L" 
verbunden sein muss)
Die Eagle-Files vom Arduino Mega2560-Bord sagen das gleiche.
Aber hast schon recht, ich nehme bisher nur an, dass das Mapping dem 
genannten Link entsprechen - gemessen hab ichs noch nicht.

Hab den Sohn nun an der Backe und heut Abend dann die Frau (was nicht 
nur schlecht ist) - ich danke schonmal fürs "Sicherheit geben", dass ich 
nicht zu doof bin, die kleinsten Handgriffe hinzubekommen. Tatsächlich 
hab ich schon über einige Jahre hinweg komplexere Programme für C51, 
C166 und ATCAN geschrieben, aber Bootloader nie angefasst und Gras 
gewachsen ist auch derweil.

Alla - Danke und ich meld mich nachm Layout Durchmessen

LG
Robert

AVRStudio6 läuft auf meinem Rechner zäh - werd nicht wenig auf der 
Arbeit (im Hausmeisterkabuff) mit nem noch älteren Laptop arbeiten.

AVRStudio4 hat damals gut funktioniert und ist "schlank", aber glaube 
Hauptargument ist: ich bin die Umgebung gewohnt.

@PinMapping und eigentliches Problem: Ja f.. die H..! Hab nen andren 
Pin, den ich über Arduino auf Bitebene angesprochen hatte dauergetogglet 
- funzte.
Hab dann den ursprünglichen an der LED hängenden genommen ... funzt 
auch.
Weiß jetzt nicht, warum es zuvor nicht ging, aber nudenn ... bin 
glücklich erstmal :)
(vllt waren die Steckbrett-Kontakte schuldig, auf die ich die Pins 
rausgezogen hab)

Wo wir beim Thema Fuses und Bootloader sind .....

Der Resetvector ist "disabled" (also auf erste Adresse hinter Bootsektor 
zeigend) wegen besagtem Flag, gelle?

Und im Bootsektor steht nach wie vor der Arduino-Loader? Ob ichs machen 
sollte/will/werde etc sei mal dahingestellt, aber welche Schritte müsste 
ich unternehmen, um den Bootloader komplett wegzufegen?

LG
Robert

Robert T. schrieb:

> Der Resetvector ist "disabled" (also auf erste Adresse hinter Bootsektor
> zeigend) wegen besagtem Flag, gelle?

Richtig.
Was nichts anderes heisst, als das der µC bei der Adresse 0x0000 im 
Speicher seine Arbeit anfängt und nicht bei der eingestellten Adresse im 
Bootsektorbereich.

> Und im Bootsektor steht nach wie vor der Arduino-Loader?

Kommt drauf an. Da müsste man jetzt die Protection Bits überprüfen. Der 
Flash-Bereich, in dem der Bootloader steht, kann gegen überschreiben 
geschützt werden. Erwarten würde ich, dass dieser Schutz bei einem 
Original-Arduino auch aktiviert ist.
Wenn also dein Brennprogramm das Koommando gibt 'Flash löschen', dann 
wird dadurch der Bootloader eben nicht gelöscht. Sind die Schutzbits 
nicht gesetzt, dann bedeutet 'Flash löschen' dann auch wirklich: 
komplettes Flash löschen, wodurch der Bootloader Geschichte ist.

> Ob ichs machen
> sollte/will/werde etc sei mal dahingestellt, aber welche Schritte müsste
> ich unternehmen, um den Bootloader komplett wegzufegen?

Alle Brennprogramme haben normalerweise eine 'Clear' Funktion. Alles was 
nicht explizit mittels Fuse Bits geschützt ist, ist dann auch wirklich 
gecleared.

Danke Euch zwei Beiden für die netten Ratschläge. So 100% verstanden hab 
ich noch nicht warums mal nicht ging und nun geht, aber ich hab was über 
den Bootvektor gelernt :)

Bin jetzt schon weiter, als ich mit dem Arduino je gekommen bin (1. 
Timer-IRQ funzt).

@Klaus: nicht dass ich jemals wieder auf Arduino wollte. Aber hab mir 
Deinen 2. Link mal angeschaut ... wird dann konkurrenzfähig, wenn man 
Register im Simulator abbilden kann. Memspace scheint im Gegensatz zur 
ArduinoIDE schon einsehbar zu sein.
Generell ist das Arduino-Zeugs in meiner Welt eine schlechte Lösung. 
Glaub Urgedanke ist, Menschen das Autofahren ohne Führerschein zu 
ermöglichen und man hat dann Knöpfchen wie "Fahre 1Meter50 vorwärts" 
implementiert - wer 1Meter20 fahren mag, hat Pech gehabt und wenn man 
dann noch gleichzeitig den Knopf "Fenster runter" drückt, weiss man 
garnicht mehr, ob noch irgendwas fährt.
Meine Anwendung soll ein Ladegerät für den Modellbaubereich sein. 
Touchpanel+Shield war dabei - Arduino-Bibs gabs als Download - 
beeindruckend wie schnell man Sinuskurven zeichnen und Buttons drücken 
konnte.
Aber ebenfalls beeindruckend, wie lange die Abfrage dauerte, ob ne 
Eingabe am Touchpad anliegt. Dann krabbelt man sich durch den Code und 
stellt iwann fest die TFT-Lib nutzt Bit-Operatoren für Lese- und 
Schreibzugriffe, das serielle Touchpad nutzt den HighEnd-Befehl 
digitalWrite/Read, der glaub 1mS anstelle 1uS dauert - hält jmd den 
Finger aufs Panel, grübelt der also (geschätzt) 1/20 Sekunde rum.
Ein einhergehender Nachteil ist die große Flut Ahnungsloser, die 
Tutorials schreiben ... hab mal eins gesehen, in dem ein Spanier gezeigt 
hat, wie schlecht die Löcher auf meinem Board platziert sind und dass 
Schraubenköpfe mit Steckerleisten kollidieren. Gleiches gilt für IPhone- 
und Mutti-Foren; zu viele Menschen, die glauben zu wissen wies geht, was 
das Suchen nach Information müßig macht.