- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: USART simulieren im Atmelstudio6

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    23.01.2014
    Beiträge
    10

    USART simulieren im Atmelstudio6

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Hallo,

    ich bin nach etlichen Jahren Abstinenz wieder zum MCU Programmieren gekommen.
    Ich habe die letzten Jahre vorwiegend Elektronikschaltungen entwickelt und programmieren "lassen".
    Früher habe ich selber meistens mit Microchip und in Assembler gearbeitet, leider nur wenig mit den Atmels und dem AVR Studio 4.

    Leider habe ich meine C Kenntnisse nie so wirklich gepflegt bzw. ausgebaut (ich hatte ja einen Programmierer).
    Jetzt wollte ich das nachholen und habe mir das Atmelstudio6 zugelegt.
    Leider sieht das alles etwas ungewohnt aus und ich komme nicht wirklich voran.

    Ich wollte für ein kleines Heimprojekt (Haus Bus zum Üben) eine „minimale“ Kommunikation über eine RS485 Hardware realisieren.
    Als MCU habe ich mir den ATMega64 ausgeguckt, und schon ein klein wenig Code geschrieben.

    Da ich noch keine Hardware zum Üben habe wollte ich das mal mit dem Simulator durchtesten.

    Ich komme aber nie in die ISR (der Breakpoint wird nie erreicht).
    Den Registereintrag RXC0 kann ich zwar setzen, aber zur ISR führt das nicht.

    Was mache ich falsch? Geht das überhaupt?
    Das UDR0 kann ich auch nicht beschreiben um dort etwas zu sehen.

    Über Hilfe würde ich mich freuen.
    Bitte aber berücksichtigen, dass ich mit C üblichen Vorgehensweisen noch nicht so vertraut bin.


    Code:
    #include <avr/io.h>
    #include <avr/iom64.h>
    #include <stdio.h>
    #include <avr/interrupt.h>
    
    /*	F_CPU = 16000000UL	MCU Frequenz 16MHz externes Quarz 
    	global gesetzt unter AVR/GNU C Compiler - Symbols*/
    
    #define USART_BAUD_RATE 9600							//gewünschte Baudrate
    
    #define USART_BAUD_CALC (F_CPU/(USART_BAUD_RATE*16L)-1)      //berechnet Registerwerte für Baudrate
    
    #define LOW(x) ((x) & 0xFF)			                                      //LOW-Byte
    #define HIGH(x) (((x) >> 8) & 0xFF)	                                              //HIGH-Byte
    
    volatile uint8_t data=0x00;			                                              //nur zum Anschauen im Watch
    
    ISR (USART0_RX_vect)				                                      //Interrupt wenn empfang abgeschlossen
    {
    	data=UDR0;
    	UDR0=data;
    	
    }
    
    
    
    int main(void)
    {									
    	
    	
    	DDRA=0b00000000;
    	DDRB=0b11111111;
    	DDRC=0b11111111;
    	DDRD=0b10111011;
    	DDRE=0b10111110;
    	DDRF=0b11111111;
    	DDRG=0b11111;
    	
    	
    	UBRR0H = HIGH(USART_BAUD_CALC);					//Setzen des HIGH-Byte vom USART-Register für Baudrate
    	UBRR0L = LOW (USART_BAUD_CALC);					//Setzen des LOW-Byte vom USART-Register für Baudrate
    
    	UCSR0B = (1<<RXEN0) | (1<<TXEN0) | (1<RXCIE0);	               //Empfangen, Senden und Empfangsinterrupt aktivieren
    	UCSR0A = (1<<MPCM0);							       //Bit zur "SLAVE" Kennzeichnung !/nur Adressen ansehen, Daten ignorieren							
    	
    	//Codierungsbits abfragen und RRS485-ID Adressierung festlegen
    	
    	
    	sei();											       //Interruptfreigabe
    	
    	
    	while(1)
    	{
    
    					
    			PORTG  =0b10101;				//setzt Port G Bitmuster		nurm zum Anschauen im IO View				
    			PORTG ^=(1<<PG1);				//toggelt Port G Bit 1
    			
            }
    	
    }

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    23.01.2014
    Beiträge
    10
    Hallo,?

    Hat denn keiner eine Idee?

    Ich wäre sehr froh wenn sich mal jemand meldet.
    Hits habe ich schon eine Menge, aber noch keine Antworten.

    Gruß an alle

  3. #3
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    09.02.2005
    Ort
    München
    Alter
    39
    Beiträge
    389
    Kommunikation zu Simulieren ist immer schwierig mit dem Simulator. Das die ISR aufgerufen wird müsstest du das Interrupt-Flag händisch aktivieren.
    Aber du kannst ja mit anderen Sachen mal starten und wenn die Hardware da ist mit der UART Schnittstelle weiter machen.

    Kleiner Tipp


    Code:
    DDRD=0b10111011;
    so würde ich das nicht schreiben ist einfach unübersichtlich.
    lieber

    Code:
    DDRD = (1<<PD7)|(1<<PD5)|(1<<PD4)|(1<<PD3)|(1<<PD1)|(1<<PD0);
    Dauert zwar länger zum schreiben, aber liest sich viel schneller als Bits zählen

    Sonst sieht eigentlich ganz gut aus für den Anfang.


    Gruß Matthias

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    23.01.2014
    Beiträge
    10
    Danke für den Tipp mit der Bit Zählerei (da hab ich mich schon öfter verzählt ).

    Das Flag händisch zu setzen hatte ich schon versucht. Hat nichts gebracht.

    Ich habe schon begonnen mir Gedanken über den Rest zu machen (Aufbau des Protokolls, FIFO-Register usw.).
    Ist ne zähe Sache, wenn man nebenbei erst noch C (neu) lernen muss.

    Gruß Marcus

  5. #5
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    09.02.2005
    Ort
    München
    Alter
    39
    Beiträge
    389
    Fang erst mal klein an. LEDs an/aus, Taster, Timer, PWM, ... . So kannst du dich schrittweise einarbeiten und an die C Syntax gewöhnen.. Wenn du zu komplex startest wirst du früher oder später frustriert aufgeben.

    Gruß Matthias

  6. #6
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    Zitat Zitat von marcus.m Beitrag anzeigen
    Das Flag händisch zu setzen hatte ich schon versucht. Hat nichts gebracht.
    Debug -> Options and Settings -> Tools -> Tool Settings -> Mask interrupts while stepping


    BTW:
    Code:
    #include <AVR/iom64.h>
    Dies hat in deinem Code nichts zu suchen. Du inkludierst immer nur <avr/io.h>.
    MfG
    Stefan

  7. #7
    Neuer Benutzer Öfters hier
    Registriert seit
    23.01.2014
    Beiträge
    10
    Debug -> Options and Settings -> Tools -> Tool Settings -> Mask interrupts while stepping

    und dann?

    Default ist auf True, Ändern auf False bringt auch nichts.

    Das #include <avr/iom64.h> habe ich drin, weil ich mit dem ATMega64 arbeiten will.

    Ohne hatte ich nicht alle Ports bis G zur Verfügung,
    die kamen erst nach dem Einbinden von iom64.h

    Gruß Marcus

    @Stone
    ...LEDs an/aus, Taster, Timer, PWM, ...

    Ports "wackeln" kann ich schon.

    - - - Aktualisiert - - -

    Code:
    /****************************************************************************
     **             - iom64.h -
     **
     **     This file declares the internal register addresses for ATmega64.
     **
     **     Used with iccAVR and aAVR.
     **
     **     Copyright IAR Systems 2002. All rights reserved.
     **
     **     File version: $Revision: 1.8 $
     **
     ***************************************************************************/
    
    #ifdef  __IAR_SYSTEMS_ICC__
    #ifndef _SYSTEM_BUILD
    #pragma system_include
    #endif
    #endif
    Gruß Marcus

    - - - Aktualisiert - - -

    Das mit dem DDRn Register ist echt praktisch.
    Kann man mit den internen PullUp kombinieren (wer will).

    Code:
    int main(void)
    {									
    	
    	RS485_Adresse=0x00;
    	
    	
    	
    	DDRA =(0<<PA7) | (0<<PA6) | (0<<PA5) | (0<<PA4) | (0<<PA3) | (0<<PA2) | (0<<PA1) | (0<<PA0); //Richtung
    	PORTA=(1<<PA7) | (1<<PA6) | (1<<PA5) | (1<<PA4) | (1<<PA3) | (1<<PA2) | (1<<PA1) | (1<<PA0); //int. PullUp
    	DDRB =(1<<PB7) | (1<<PB6) | (1<<PB5) | (1<<PB4) | (1<<PB3) | (1<<PB2) | (1<<PB1) | (1<<PB0); //Richtung
    																					 
    	DDRC =(1<<PC7) | (1<<PC6) | (1<<PC5) | (1<<PC4) | (1<<PC3) | (1<<PC2) | (1<<PC1) | (1<<PC0); //Richtung
    	
    	DDRD =(1<<PD7) | (0<<PD6) | (1<<PD5) | (1<<PD4) | (1<<PD3) | (0<<PD2) | (1<<PD1) | (1<<PD0); //Richtung
    	PORTD=		      (1<<PD6)						            | (1<<PD2)			                 ; //int. PullUp
    	DDRE =(1<<PE7) | (0<<PE6) | (1<<PE5) | (1<<PE4) | (1<<PE3) | (1<<PE2) | (1<<PE1) | (0<<PE0); //Richtung
    	PORTE=		     (1<<PE6)											     | (1<<PE0); //int. PullUp
    	DDRF =(1<<PF7) | (1<<PF6) | (1<<PF5) | (1<<PF4) | (1<<PF3) | (1<<PF2) | (1<<PF1) | (1<<PF0); //Richtung
    	
    	DDRG =						        (1<<PG4) | (1<<PG3) | (1<<PG2) | (1<<PG1) | (1<<PG0); //Richtung
    ".. verrutscht leider immer in der Ansicht"

    Gruß Marcus

  8. #8
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    Zitat Zitat von marcus.m Beitrag anzeigen
    Das #include <avr/iom64.h> habe ich drin, weil ich mit dem ATMega64 arbeiten will.

    Ohne hatte ich nicht alle Ports bis G zur Verfügung,
    die kamen erst nach dem Einbinden von iom64.h
    Dann kompilierst du nicht für den richtigen Controller (in den Projekt-Einstellungen einstellen). Das erklärt dann auch die nicht funktionierenden Interrupts.

    Nochmal: Du inkludierst immer nur <avr/io.h>, niemals die Controller spezifischen Header.
    Und schon gar nicht besorgst du dir von irgendwo her einen Header, der noch nicht mal für den von dir verwendeten Compiler gedacht ist. Oder was genau wolltest du uns mit dem Posten des IAR-Headers sagen?
    MfG
    Stefan

  9. #9
    Neuer Benutzer Öfters hier
    Registriert seit
    23.01.2014
    Beiträge
    10
    ...Header, der noch nicht mal für den von dir verwendeten Compiler gedacht ist. Oder was genau wolltest du uns mit dem Posten des IAR-Headers sagen?
    Hatte die falsche Datei geöffnet. Ich benutze natürlich den aus dem AtmelStudio.

    Den Controller habe ich schon vorher eingerichtet.
    Klicke auf die Grafik für eine größere Ansicht

Name:	Atmelstudio1.png
Hits:	9
Größe:	47,2 KB
ID:	27320

    Nach dem entfernen des #include <avr/iom64.h> ist nach dem "Build" wieder der iom64.h dabei.
    Ist das normal?

    Gruß
    Marcus

  10. #10
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    Zitat Zitat von marcus.m Beitrag anzeigen
    Nach dem entfernen des #include <avr/iom64.h> ist nach dem "Build" wieder der iom64.h dabei.
    Ist das normal?
    Ja. Es wird ja über <avr/io.h> automatisch eingebunden. Du sollst es nur nicht selber direkt einbinden, weil es nicht nur unnötig ist, sondern schlimmstenfalls andere Fehler überdeckt (wie eben einen falschen eingestellten Controller).
    MfG
    Stefan

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Asuro Simulieren
    Von robo.fr im Forum Asuro
    Antworten: 42
    Letzter Beitrag: 05.02.2014, 22:38
  2. NiboBee simulieren
    Von robo.fr im Forum Sonstige Roboter- und artverwandte Modelle
    Antworten: 1
    Letzter Beitrag: 01.06.2010, 14:25
  3. Regelstrecke simulieren
    Von Wüstenblume im Forum Elektronik
    Antworten: 14
    Letzter Beitrag: 05.06.2008, 21:58
  4. Luftströmung simulieren
    Von Black Scorpion im Forum Software, Algorithmen und KI
    Antworten: 0
    Letzter Beitrag: 24.04.2008, 15:25
  5. Kinematik Simulieren
    Von BlackDevil im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 12
    Letzter Beitrag: 25.12.2007, 17:55

Stichworte

Berechtigungen

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

Labornetzteil AliExpress