Kompilierfehler für ATtiny85

[Definitionssache (Gast)]

Hallo,

ich habe vor ein paar Monaten in Atmel Studio einen Code für einen 
ATtiny85 geschrieben. Der hat auch wunderbar funktioniert.

Nun versuche ich den selben Code nur mit Toolchain und Makefile zu 
kompilieren, aber offenbar fehlen ein paar Definitionen:

main.cpp:157:2: error: 'UCSR0C' was not declared in this scope
  157 |  UCSR0C =  (1 << UCSZ01) | (1 << UCSZ00);    // Set frame: 8data, 1 stop
      |  ^~~~~~
main.cpp:157:18: error: 'UCSZ01' was not declared in this scope; did you mean 'CS01'?
  157 |  UCSR0C =  (1 << UCSZ01) | (1 << UCSZ00);    // Set frame: 8data, 1 stop
      |                  ^~~~~~
      |                  CS01
main.cpp:157:34: error: 'UCSZ00' was not declared in this scope; did you mean 'CS00'?
  157 |  UCSR0C =  (1 << UCSZ01) | (1 << UCSZ00);    // Set frame: 8data, 1 stop
      |                                  ^~~~~~
      |                                  CS00

Hat die tn85def.inc was damit zu tun und wie bekomme ich sie ins 
Makefile eingebunden?

Danke für die Hilfe

[Karl M. (Gast)]

Guten Morgen, da du anscheinend ein C Programm schreiben möchtest, muss 
keine Assembler Datei eingebunden werde, bzw. Verwendet werden. Zeig 
dein gesamtes Projekt nebst den C-Dateien und Makefile, dann kann man 
dir auch helfen.

[PittyJ (Gast)]

Oft muss man Include-Pfade mit in einer Kommandozeile eingeben.

[Peter D. (peda)]

Definitionssache schrieb:
> main.cpp:157:2: error: 'UCSR0C' was not declared in this scope

Da hatter recht, im ATtiny85 gibt es kein Register 'UCSR0C'.

[Karl M. (Gast)]

Peter D. schrieb:
> Definitionssache schrieb:
> main.cpp:157:2: error: 'UCSR0C' was not declared in this scope
>
> Da hatter recht, im ATtiny85 gibt es kein Register 'UCSR0C'.

Danke Peter, das ist ja witzig ich habe nicht gesehen dass der Attiny85 
gemeint ist, der hat nämlich gar keinen USART.

[Sebastian S. (amateur)]

>Hallo,

>ich habe vor ein paar Monaten in Atmel Studio einen Code für einen
>ATtiny85 geschrieben. Der hat auch wunderbar funktioniert.

Ich finde es immer wieder wunderbar (im wahrsten Sinne des Wortes) wenn 
ich so etwas lese.

Code, der ein nicht existentes Register anspricht und sogar 
funktioniert;-)

[kyrk.5 (Gast)]

Sebastian S. schrieb:
> Code, der ein nicht existentes Register anspricht und sogar
> funktioniert;-)

Sowas habe ich nicht gehabt, aber etwas ähnliches allerdings mit PIC32.
PC 1 mit XC32 2.10 und Legacy Peripherie drivers
PC 2 mit XC32 2.30 ohne Legacy Peripherie drivers

PC 1 kompiliert. PC 2 natürlich nicht. Klar da die Librarys fehlen. Da 
der Kompiler die Librarys durch den Linker Script als optional bekommt, 
gibt es anstelle von fehlende Libraryfile nur verschiedene Compiler und 
Linker Errors.

Man kann natürlich alles schon erklären wenn man bisschen reingeguckt :) 
Aber erste mal war mir nicht klar dass der Legacy driver fehlen würde 
und habe mich gewundert... Es hat doch davor schön kompiliert und jetzt 
auf einmal nicht mehr.

[M. K. (sylaina)]

kyrk.5 schrieb:
> Man kann natürlich alles schon erklären wenn man bisschen reingeguckt :)
> Aber erste mal war mir nicht klar dass der Legacy driver fehlen würde
> und habe mich gewundert... Es hat doch davor schön kompiliert und jetzt
> auf einmal nicht mehr.

Wenn der Entwicklungsumgebung Treiber fehlen ist dass das eine, wenn man 
aber auf einem Mikrocontroller Peripherie anspricht die es gar nicht 
gibt ist das ein völlig anderes Problem. Nicht vorhandene Peripherie 
bekommt man auch nicht mit Treibern implementiert. Aus dem Motor meines 
Autos wird ja auch nicht ein 1.000 PS Monster nur weil ich nen anderes 
Logo auf die Motorhaube klebe ;)

[Peter D. (peda)]

M. K. schrieb:
> Nicht vorhandene Peripherie
> bekommt man auch nicht mit Treibern implementiert.

Auf großen CPUs mit OS klappt das schon.
Man konnte z.B. unter 32Bit-Windows DOS-Programme starten, die direkt 
auf die Registeradressen der 16550 UART zugegriffen haben.
Der Treiber hat dann diese Zugriffe abgefangen und deren Funktion auf 
dem USB-RS232 Konverter implementiert.

[M. K. (sylaina)]

Peter D. schrieb:
> Auf großen CPUs mit OS klappt das schon.

Was abfangen und simulieren, ja das geht natürlich. Aber das sieht hier 
IMO nicht so aus als sei das hier geplant gewesen.

[Definitionssache (Gast)]

Wie ich inzwischen herausfinden durfte, ist der Code gar nicht mehr für 
einen ATtiny gedacht sondern wurde für einen ATmega328P umgeschrieben. 
Dann klappt es auch mit dem kompilieren.

[spess53 (Gast)]

Hi

>Wie ich inzwischen herausfinden durfte, ist der Code gar nicht mehr für
>einen ATtiny gedacht sondern wurde für einen ATmega328P umgeschrieben.

Das widerspricht deiner anfänglichen Aussage:

>ich habe vor ein paar Monaten in Atmel Studio einen Code für einen
>ATtiny85 geschrieben. Der hat auch wunderbar funktioniert.

MfG Spess

[Definitionssache (Gast)]

spess53 schrieb:
> Hi
>
> Wie ich inzwischen herausfinden durfte, ist der Code gar nicht mehr für
>>einen ATtiny gedacht sondern wurde für einen ATmega328P umgeschrieben.
>
> Das widerspricht deiner anfänglichen Aussage:
>
> ich habe vor ein paar Monaten in Atmel Studio einen Code für einen
>>ATtiny85 geschrieben. Der hat auch wunderbar funktioniert.
>
> MfG Spess

Nun tut es nicht, wenn man in Betracht zieht, dass ich es schlicht 
vergessen habe.

[spess53 (Gast)]

Hi

>Nun tut es nicht, wenn man in Betracht zieht, dass ich es schlicht
>vergessen habe.

Ja, Ja. Wer keine Ausrede hat, wird erschossen.

MfG Spess

[Einer K. (Gast)]

spess53 schrieb:
> Ja, Ja.

Ihm hat doch schon längst zugegeben/eingesehen, dass er da einen Bock 
geschossen hat, sich geirrt hat.

Wieso musst du da noch so ausgiebig nach treten?

Das ist keine Frage an dich, auf die ich eine Antwort sehen möchte, denn 
jede Form der Rechtfertigung, für so ein Verhalten, kann nur 
gruselig/igitt sein.

[M. K. (sylaina)]

Arduino Fanboy D. schrieb:
> Wieso musst du da noch so ausgiebig nach treten?

Weil wir hier im Mikrocontroller-Forum sind, da ist das leider normal :(