Pin + Port an Library weitergeben

library schrieb:
> Für die meisten wird die Frage wahr. blöd vorkommen aber ich hoffe Ihr
> könnt mir helfen.

kaum. Um was für einen µC geht es dann wirklich?

Soll es wirklich eine lib (Library) oder nur eine extra C(PP) Datei 
werden?

> Ich dachte erstmal an sowas wie:
> #define PIN1 PB1
> Aber das kann es auch nicht sein oder?
> Weil ich muss ja dann auch noch DDRx und PORTx in der Library festlegen

dann könnte man einfach

#define LED_PIN PB1
#define LED_PORT PORTA

Peter II schrieb:
> Soll es wirklich eine lib (Library) oder nur eine extra C(PP) Datei
> werden?
Es soll eine Library werden.

Peter II schrieb:
> Um was für einen µC geht es dann wirklich?
In meinem Testfall verwende ich einen ATmega328p.

Ralf G. schrieb:
> Wie hast du das sonst umgesetzt?
Ich hab das so in dieser Art noch nie gebraucht.

MFG

library schrieb:
> Es soll eine Library werden.

Der Begriff wird im Zusammenhang mit Arduino und ausserhalb
der Arduino-Welt ganz unterschiedlich aufgefasst.

Deshalb erst mal genau sagen was du willst.

library schrieb:
> Es soll eine Library werden.

dann kannst du nicht mit defines arbeiten, weil libs unabhängig vom 
Projekt gebaut werden. Damit kannst du nur Zeiger auf Ports verwenden, 
damit sind die zugriffe nicht optimal weil SBI, CBI usw. nicht 
funktionieren.

Ein Weg:
Arduino hält Aufdrösel Tabellen im Flash, mit den zugehörigen 
Funktionen, welche auf diesen Tabellen reiten.

Mein Weg: https://www.mikrocontroller.net/attachment/highlight/319176

Vielleicht kannste dir ja bei den beiden Varianten was abschauen.

Mitlesa schrieb:
> Der Begriff wird im Zusammenhang mit Arduino und ausserhalb
> der Arduino-Welt ganz unterschiedlich aufgefasst.

Mit Arduino hab ich gar nichts am Hut.
Ich arbeite mit AVR-Studio (C), ISP und immer selbstaufgebauter 
Hardware.

Wenn C++ "erlaubt" ist: Library-"Objekt" als Template anlegen, beim 
instantiieren PORT/PIN/Bitmask als Template-Parameter übergeben.

Oder, wenn man's "schön" machen will, eine Template-Abstraktion 
"GPIO-Pin" dazwischenlegen, dann lässt sich das Template auch z.B. mit 
GPIOs an einem I²C-Expander verwenden.

Dank C++ Template-Magie geht das ganze ohne Laufzeit-Overhead.

Aber: du musst den Quelltext mit rausrücken. (was nicht gleichbedeutend 
mit "OpenSource" ist. War früher ganz üblich dass man bei gekaufter 
Software den Quelltext mit dazubekommen hat)

Hi,

du kannst auch darueber nachdenken die entsprechenden Operationen, z.B. 
Pin Chip-Select setzen, als Funktionszeiger an deine Library zu 
uebergeben. Dann kannst du das ganze sogar durch Dummys ersetzen oder 
auf andere Hardwarearchitekturen übertragen. Habe ich gerade mit Code 
gemacht der sowohl auf einem Atmel AVR als auch auf einem ARM mit 
embedded Linux laufen soll.

Planlos schrieb:
> Dank C++ Template-Magie geht das ganze ohne Laufzeit-Overhead.

nur wird es keine wirkliche Library, er müsste ein Großteil vom Code in 
der Headerdatei schreiben.

Peter II schrieb:
> nur wird es keine wirkliche Library, er müsste ein Großteil vom Code in
> der Headerdatei schreiben.

Wo ist das Problem dabei?
Angst dass der Compiler zu lange braucht, oder der Build-Prozess zuviel 
Strom frisst?

Planlos schrieb:
> Wo ist das Problem dabei?

nur das ich es sehr unschön finde in Headerdateien viel Programmcode zu 
haben. Es ist wird daraus dann keine lib.

Das kann man auch einfach mit C und einer Headerdatei und defines lösen, 
dafür braucht man nicht einmal Templates.

Ich habe grad was in einer Library gefunden:

1

#define I2C_SDL_LO      cbi( SDAPORT, SDA)

2

#define I2C_SDL_HI      sbi( SDAPORT, SDA)

Was ist wenn man es so macht?

MFG