-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: Anfängerprobleme mit AT90USB162

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.02.2006
    Alter
    30
    Beiträge
    140

    Anfängerprobleme mit AT90USB162

    Anzeige

    Hallo!

    Ich habe ein kleines Anfängerproblem. Welche INCLUDE muss ich für den AT90USB162 verwenden um ein Assemblerprogramm schreiben zu können? Ich verwende AVRStudio 4.13 falls das relevant ist.

    Ich will momentan nur ein paar Leds ein und ausschalten, was ja eigentlich nicht so schwer sein sollte.

    Vor kurzem habe ich mir einen eStick gekauft, falls das jemand kennt (5-10 euro, bei so einem Preis musste ich zuschlagen ^^), da ist eben dieser Controller eingebaut.

    Code:
    .NOLIST                    ; List-Output unterdrücken
    .INCLUDE <m162def.inc>
    
    
    .LIST                      ; List-Output wieder aufdrehen
    ;Registeraufteilung
    .def temp  = r16
    
    
    .DSEG						; Schreibt Daten in den SRAM
    
    
    .CSEG                      ; was nun folgt, gehört in den FLASH-Speicher
    
    .org 0x0000
    	rjmp Initialisierung
    
    Initialisierung:
    ;Stackpointer
    	ldi temp, LOW(RAMEND)
    	out SPL, temp
    	ldi temp, HIGH(RAMEND)
    	out SPH, temp
    ;Aus/Eingänge
    	ldi temp, 0b11111111
    	out DDRB, temp						; Ausgang
    	out DDRC, temp
    
    Hauptprogramm:
    
    	sbi PortC, 2
    
    	sbi PortB, 0
    	cbi PortB, 1
    	sbi PortB, 2
    	cbi PortB, 3
    	sbi PortB, 4
    	cbi PortB, 5
    	sbi PortB, 6
    	cbi PortB, 7
    
    Ende:
    	rjmp Ende
    Diesen Code habe ich getestet, was mcih wundert das absolut nichts am ausgang passiert, weder die DDR bits werden gesetzt, noch die Port bits (HILFE)

    Bitte helft mir, kann ja nicht so schwer sein 4 Leds einzuschalten

    mfg
    Gerko

    EDIT:
    Ok, ich hab jetzt die richtige Include datei gefunden (USB162def.inc klingt irgendwie logisch, ist allerdings im AVR 2 oderner gelagert, warum auch immer)

    das Programm funktioniert auf dem e-Stick allerdings immer noch nicht:

    Code:
    .NOLIST                    ; List-Output unterdrücken
    .INCLUDE <usb162def.inc>
    
    
    .LIST                      ; List-Output wieder aufdrehen
    ;Registeraufteilung
    .def temp  = r16
    
    
    ;.DSEG						; Schreibt Daten in den SRAM
    
    
    .CSEG                      ; was nun folgt, gehört in den FLASH-Speicher
    
    .org 0x0000
    	rjmp Initialisierung
    
    Initialisierung:
    ;Stackpointer
    	ldi temp, LOW(RAMEND)
    	out SPL, temp
    	ldi temp, HIGH(RAMEND)
    	out SPH, temp
    ;Aus/Eingänge
    	ldi temp, 0b11111111
    	out DDRB, temp						; Ausgang
    	sbi DDRC, 2
    
    	sei
    
    Hauptprogramm:
    
    	sbi PortC, 2
    
    	sbi PortB, 0
    	cbi PortB, 1
    	sbi PortB, 2
    	cbi PortB, 3
    	sbi PortB, 4
    	cbi PortB, 5
    	sbi PortB, 6
    	cbi PortB, 7
    
    Ende:
    	rjmp Ende
    Das ist mein code, in der Simulation funktioniert es, allerdings nicht auf dem e-Stick

    Das ist der Schaltplan dazu:

    http://embsys.technikum-wien.at/staf..._schematic.pdf

    ich weiß nicht ganz warum es nicht funktioniert, wenn ich PortC2 setze, müssten die Leds aktiviert sein (so versteh ich das zumindest)

    hat jemand eine Idee was ich noch anders machen muss?

    mfg
    Gerko

  2. #2
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.02.2006
    Alter
    30
    Beiträge
    140
    liegt das vielleicht daran das ich einen AVR Assembler 2 verwenden muss? ist da eigentlich ein unterschied in der programmierung?

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    24.02.2006
    Ort
    3. Planet eines kleinen Sonnensystems in einem Seitenarm der Milchstraße
    Alter
    63
    Beiträge
    622
    Hi,

    der "Assembler 2" ist nur etwas komfortabler, muss aber identischen Code erzeugen -- verwende ihn doch einfach!
    Das "sei" ist unnötig (und potentiell gefährlich); der Rest sieht OK aus. Bist Du Dir sicher, dass der Code im Controller steht, das "Flashen" also geklappt hat? Da der Treiber nicht-invertierend ist und die LEDs mit Vcc verbunden sind, sollten die LEDs an den auf "L" gezogenen Ausgängen leuchten.

    Gruß

    Fred
    Only entropy comes easy. - Anton Checkhov

  4. #4
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.02.2006
    Alter
    30
    Beiträge
    140
    also der AVR simmulator 2 steht für den AT90USB162 komischerweise nicht zur verfügung, ich also kann ich den auch nicht verwenden denk ich...

    zum Flaschen verwende ich das tool das ich dazu gefunden habe (EStickFlashTool) mit dem kann man auch verschiedene Testprogramme draufspielen, die auch funktionieren. Wenn ich mein hex file damit flashe und auf Start drücke geht der controller irgendwie nicht in den Betriebsmodus, sondern bleibt im Programmiermodus (ist dadurch zu erkennen das die Ausgänge anscheinend irgendwas machen, also es leuchen immer andere Leds)

    Es muss doch möglich sein für den E-Stick selber programme zu schreiben!

    das die Leds "invertiert" sind weiß ich, deswegen auf 01010101 zum testen.

    Ich hab das sei jetzt mal rausgenommen aus dem Programm weil ich noch zu faul bin die Interrupttabelle zu schreiben.

    Gibt es vielleicht ein anderes Tool mit dem man diesen Kontroller falschen kann?

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    24.02.2006
    Ort
    3. Planet eines kleinen Sonnensystems in einem Seitenarm der Milchstraße
    Alter
    63
    Beiträge
    622
    Hast Du denn den Quellcode für die Testprogramme? Wie könnte man herausfinden, was das Flash-Tool veranlasst, den Controller freizugeben, damit er auch läuft, was bei Deinen Testprogrammen ja funktioniert? Ich kenne das System nicht, kann Dir also zu alternativen Flash-Tools keine Tipps geben.
    Only entropy comes easy. - Anton Checkhov

  6. #6
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Die USB Controller ahebn meistens eine Bootloader zum programmieren. Vermutlich muß man das im Prgramm berücksichtingen. Sich den Code eines Bespiels anzuschauen macht da wirklich Sinn.

    Der Simulator 2 unterstützt noch nicht viele Chips. Das da ein USB Chip noch nicht geht ist also kein wunder. Wenn es nur um die eigentliche funktion geht kann man den Code ja auch für einen ähnlichen Controller übersetzen und dann simulieren.

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.02.2006
    Alter
    30
    Beiträge
    140
    ES GEHT!

    Danke für eure Hilfe die bestätigung das der Code passt war schon ein großer Schritt. Ich hab jetzt nach einem alternativen Programm zum flashen gesucht und dabei Flip enddeckt. Das ist viel besser als das was dabei war, es hängt sich nicht auf, und vorallem es funktioniert!

    also es leuchten jetzt 4 Leds ^^

    Weiß jemand ob es mit dem µC möglich ist mit dem PC zu kommunizieren wärend es läuft?

    das wäre dann so eine Art neue Herausforderung ^^

    Danke noch mal!

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    24.02.2006
    Ort
    3. Planet eines kleinen Sonnensystems in einem Seitenarm der Milchstraße
    Alter
    63
    Beiträge
    622
    Hi,

    Zitat Zitat von Gerko
    ...Weiß jemand ob es mit dem µC möglich ist mit dem PC zu kommunizieren wärend es läuft?...
    kann ich Dir nicht aus eigener Erfahrung beantworten -- vermutlich aber schon; sieh Dir doch mal die Beispiele hier an.

    Gruß

    Fred
    Only entropy comes easy. - Anton Checkhov

  9. #9
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.02.2006
    Alter
    30
    Beiträge
    140
    Hmm, ich schätze dann werd ich mich mal in das datenblatt einlesen. der chip hat ja USB und Uart, was schon ziemlich cool ist denk ich ^^ Ich werde mal bei gelegenheit berichten wie ich dabei vorankomme.

  10. #10
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.02.2006
    Alter
    30
    Beiträge
    140

    noch ein Problem mit dem AT90USB162

    Hallo!

    Ich komme von einem Proglem zum nächsten!

    Diesmal ist es ein Progblem mit dem Timer, hier ist mal das Programm:

    Code:
    .NOLIST                    ; List-Output unterdrücken
    .INCLUDE <usb162def.inc>
    
    
    .LIST                      ; List-Output wieder aufdrehen
    ;Registeraufteilung
    .def temp   = r16
    
    .CSEG                      ; was nun folgt, gehört in den FLASH-Speicher
    
    .org 0x0000
    jmp Initialisierung ;RESET
    jmp kein_Interrupt ;INT0             ;External Interrupt Request 0
    jmp kein_Interrupt ;INT1             ;External Interrupt Request 1
    jmp kein_Interrupt ;INT2             ;External Interrupt Request 2
    jmp kein_Interrupt ;INT3             ;External Interrupt Request 3
    jmp kein_Interrupt ;INT4             ;External Interrupt Request 4
    jmp kein_Interrupt ;INT5             ;External Interrupt Request 5
    jmp kein_Interrupt ;INT6             ;External Interrupt Request 6
    jmp kein_Interrupt ;INT7             ;External Interrupt Request 7
    jmp kein_Interrupt ;PCINT0           ;Pin Change Interrupt Request 0
    jmp kein_Interrupt ;PCINT1           ;Pin Change Interrupt Request 1
    jmp kein_Interrupt ;USB General      ;USB General Interrupt request
    jmp kein_Interrupt ;USB Endpoint     ;USB Endpoint Interrupt request
    jmp kein_Interrupt ;WDT              ;Watchdog Time-out Interrupt
    jmp kein_Interrupt ;TIMER1 CAPT      ;Timer/Counter1 Capture Event
    jmp kein_Interrupt ;TIMER1 COMPA     ;Timer/Counter1 Compare Match A
    jmp kein_Interrupt ;TIMER1 COMPB     ;Timer/Counter1 Compare Match B
    jmp kein_Interrupt ;TIMER1 COMPC     ;Timer/Counter1 Compare Match C
    jmp kein_Interrupt ;TIMER1 OFV       ;Timer/Counter1 Overflow
    jmp kein_Interrupt ;TIMER0 COMPA     ;Timer/Counter0 Compare Match A
    jmp kein_Interrupt ;TIMER0 COMPB     ;Timer/Counter0 Compare Match B
    jmp TIMER0_OVF       ;Timer/Counter0 Overflow
    jmp kein_Interrupt ;SPI, STC         ;SPI Serial Transfer Complete
    jmp kein_Interrupt ;USART1 RX        ;USART1 Rx Complete
    jmp kein_Interrupt ;USART1 UDRE      ;USART1 Data Register Empty
    jmp kein_Interrupt ;USART1TX         ;USART1 Tx Complete
    jmp kein_Interrupt ;ANALOG COMP      ;Analog Comparator
    jmp kein_Interrupt ;EE READY         ;EEPROM Ready
    jmp kein_Interrupt ;SPM READY        ;Store Program Memory Ready
    
    kein_Interrupt:
    reti
    
    
    Initialisierung:
    ;Stackpointer
    	ldi temp, LOW(RAMEND)
    	out SPL, temp
    	ldi temp, HIGH(RAMEND)
    	out SPH, temp
    ;Aus/Eingänge
    	ldi temp, 0b11111111
    	out DDRB, temp						; Ausgang
    	sbi DDRC, 2
    ;Timer0 aktivieren
    	ldi temp, 0b00000001
    	out TIMSK0, temp
    
    	ldi temp, 0b00000101
    	out TCCR0B, temp
    
    	sei
    
    Hauptprogramm:
    
    	sbi PortC, 2
    
    	ldi temp, 0b01010101
    	out PortB, temp
    
    Ende:
    	rjmp Ende
    
    TIMER0_OVF:
    	push temp
    	in temp, SREG
    	push temp
    
    	cpi temp, 0b01010101
    	breq PC+3
    	ldi temp, 0b01010101
    	rjmp PC+2
    	ldi temp, 0b10101010
    	out PortB, temp
    
    	pop temp
    	out SREG, temp
    	pop temp
    reti
    Die Probleme sind nun, das ich den Timer0 Overflow interrupt nicht ohne Fehlermeldung aktivieren kann. Er schreibt dann immer hin: "error, Operant 1 out of range: 0x6e"

    0x6e ist TIMSK0. Seltsamer weise steht beim TIMSK0 bei der Adresse na(0x6e). Wenn na jetzt not avalable heißt, was den fehler erklären würde, dann frage ich mich, warum steht das da?

    Im Simmulator ist das allerdings kein Problem da man ja einfach den Interrupt so aktivieren kann (per Mausklick), allerdings springt der ausgelöste Interrupt nicht auf die richtige Adresse!!!

    jetzt frage ich mich WARUM ärgert mich der Atmel so sehr?

    Bitte Helft mir, auch wenn es nur eine bestätigung für einen richtigen code ist

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •