Hallo Ihr Lieben, nachdem ich mich eine kleine Weile mit Arduino rumgeärgert habe, möchte ich mein Sainsmart 2560 Board gerne mit AVRStudio programmieren & simulieren können. Ich kann den Mega2560 per ISP flashen und auslesen (auch die Fuses), aber wenn ich ein pimmeliges Programm flashe wie: mach ma PB7 High oder Low, passiert nüscht. Meine Annahme: Der Arduino-Bootloader, der drauf ist, kackt quer. Ich hab auch schon ein wenig an den Fuses rumgespielt (default Fuses geladen), aber ohne Erfolg. Nun hab ich gelesen, dass eventuell die kompletten Interruptvektor-Adressen verschubst sein könnten; diese müsste man dann durch ein kleines Programm wieder zurechtschubsen: Aber wenn ich nichtmal nicht einen Pin (ohne IRQ) hochziehen kann, hab ich keine Hoffnung, dass ein kleine Routiene zum Zuge kommt, die iwelche Adressen wieder richtig schubst, abgesehen davon, dass ich mich schwertue zu wissen, welche Adressen wie wohingeschubst gehören. Nun ist mein Equipment um den uC herum nicht das edelste, sodass Fehlerquellen von allen Seiten streuen könnten Folgende Hardware/Software ist am Start. Board: Sainsmart Mega2560 http://www.sainsmart.com/sainsmart-mega2560-development-board-for-arduino.html ISP-Programmer: USBasp (ebay aus Übersee) (Oszi: DSO203) AVRStudio 4.19 mit AVRToolchain Burn-O-Mat 2.1.1 zum Bedienen des USBasp Mein Code schafft es im Simulator den gewünschten Pin auf high zu setzen. Das Board sollte eigentlich funktionieren - zuletzt habe ich über Arduino ein Touchpanel erfolgreich angesteuert und ausgelesen. Als mir das Board dann beim Timer-IRQ immer einen Systemneustart hergezaubert hat, hat ich den Hals voll von Arduino und wollte mehr Kontrolle. Danke fürs Beraten Robert
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); |
:
Bearbeitet durch User
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
Hallo Robert, als Alternative zur Arduino IDE würde ich dir Atmel Studio 6 ( http://www.atmel.com/microsite/atmel_studio6/ ) in Verbindung mit Visual Micro ( http://www.visualmicro.com/ ) empfehlen. Gruß Klaus
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.