Hallo zusammen, weiß vielleicht jemand, ob es möglich ist, beim Keil-Compiler im Zusammenhang mit dem C164 direkt Binärzahlen anzugeben, oder muß man sich wie beim GCC ein Makro dazu schreiben? Ich denke mir das z.B. so: Var = b00101000 Gruß, Ralf
Das ist doch gerade der Witz an C, seine Portabilität ! Warum soll der Keil es anders machen als der GCC. Peter
>Das ist doch gerade der Witz an C, seine Portabilität ! Was ist denn an einer Binärzahl nicht portabel? >Warum soll der Keil es anders machen als der GCC. Weil der ein Schweine-Geld kostet und man für die etlichen tausend Mark, die das Gurkenteil gekostet hat, auch was erwarten kann. Eine Antwort auf obige Frage würde mich auch interessieren. Wie sieht denn so ein Makro aus? Grüße Oliver
So ein Makro könnte folgendermaßen aussehen (bei Bedarf verlängern):
#define BIN(x) \
((x%10)\
|(((x/10)%10)<<1)\
|(((x/100)%10)<<2)\
|(((x/1000)%10)<<3)\
|(((x/10000)%10)<<4)\
|(((x/100000)%10)<<5)\
|(((x/1000000)%10)<<6)\
|(((x/10000000)%10)<<7)\
)
Nicht eher so?
#define BIN(x) \
((x&1)+\
(x>>1&1)<<1+\
(x>>2&1)<<2+\
(x>>3&1)<<3+\
(x>>4&1)<<4+\
(x>>5&1)<<5+\
(x>>6&1)<<6+\
(x>>7&1)<<7\
)
x soll ja als Binärzahl eingebbar sein, z.B.
01100
Hallo, danke für die Hilfe! So ein Makro habe ich bereits. Ich dachte nur, dass der Compiler es für das Geld schon anbieten würde. Habe dazu aber nichts in der Doku gefunden. Dann werde ich wohl mit dem Makro leben müssen. Gruß, Ralf
hallo,
ich bin zwar etwas am thema vorbei, aber evtl. hilft der nachfolgende
ansatz beim setzen von einzelnen bits.
läuft zwar unter c++, ist aber für den gcc kein problem.
in anhang habe ich auch noch die erzeugten assemblerfiles für den avr
und auch einen hitachi beigelegt.
ein kleines problem ist die undefinierte reihenfolge der bits.
der vorteil ist das leichte ändern der bitreihenfolge. wenn ein ausgang
mit einem anderen portpin geschaltet werden soll, ist nur die
reihenfolge in der structur zu ändern.
ich würde mich freuen, wenn das mal jemand auf einem arv laufen lassen
kann. ich habe nur die hitachi's und damit läuft es ohne probleme.
oryx
// Parameter beim compilieren
// avr-gcc -S -mmcu=atmega32 -O3
struct port
{
union
{
unsigned char bit_8;
struct
{
unsigned p0_0 : 1;
unsigned p0_1 : 1;
unsigned p0_2 : 1;
unsigned p0_3 : 1;
unsigned p0_4 : 1;
unsigned p0_5 : 1;
unsigned p0_6 : 1;
unsigned p0_7 : 1;
} bit;
};
};
port test;
int main(void)
{
test.bit_8 = 0x00;
test.bit.p0_1 = true;
test.bit.p0_2 = true;
test.bit.p0_7 = true;
return 0;
}
@Oliver, Du hast das Prinzip der Portabilität nicht verstanden: Ein Standard ist nur deshalb ein Standard, weil sich viele danach richten und nicht jeder sein extra Süppchen kocht. Und gerade teure professionelle Compiler versuchen so nahe wie möglich am ANSI-Standard zu bleiben und der kennt nun mal kein "Var = b00101000". Das BIN() Macro tuts ja auch voll, so daß niemand seinen Compiler mit Gewalt unportabel machen muß. Sonst wäre ja C auch nicht so verbreitet. @Oryx, das dürfte auf den meisten Compilern laufen (z.B. WINAVR, Keil C51). Allerdings kan manchmal der erzeugte Kode sehr umständlich sein. Der WINAVR unterstützt aber auch das mir vom 8051 vertraute direkte Setzen von I/O-Ports, z.B.: PORTA = BIN(11110000); DDRB = 1<<PB7^1<<PB6; PORTB |= 1<<PB7; PORTB &= ~(1<<PC6); und erzeugt auch den kürzest möglichen Code dafür. Peter
Hi also beim 8051 sollte doch zum setzen eines Bit's P3_2 = 1; reichen. Hat doch Bitadressen. Zumindest der SDCC akzeptiert die Schreibweise. Matthias
@Peter, willst Du etwa behaupten, C sei portabel? Das war mal so angedacht und funktionierte vielleicht auch mal eine Zeitlang so. Inzwischen hat doch jeder sein eigenen Standard selbst definiert. M$ vorweg. Gerade die speziellen Compiler für diverse CPUs zeichnen sich doch durch "komfortable" Spezialinstruktionen, z.B. für das Ansteuern von Portpins, aus. Wem mag man es da verübeln, wenn er diese auch nutzt. Das Wort Standard bei Software kannst Du getrost aus Deinem Wortschatz streichen und durch Richtlinie ersetzen. Grüße Oliver
Hi das ist, mit Verlaub, Mist: Wenn man Zugriffe auf die Hardware in ein paar Funktionen kapselt, kann man wunderbar portable Programme schreiben. Jeder Compilerbauer erweitert die Sprache meist um ein paar Funktionen. Aber es liegt am Programmierer ob er portablen Code erzeugt oder nicht. Ich hab z.B. grade den Sourcecode für einen MP3-Player in weniger als einem halben Tag vom SDCC-C (also 8051) auf den M16C portiert. Dabei mußt ich eben die Funktionen die auf die HArdware zugreifen ändern den Rest konnte ich aber so übernehmen. Es liegt also nicht an der Sprache sondern am Programmierer was er verwendet. Wer natürlich unter Windows solch Sachen wie MFC benutzt ist selber Schuld. Es gibt genügend Bibliotheken für grafische Oberflächen die auf mehreren System verfügbar sind. Matthias
@Oliver, ich stimme da Matthias voll zu. I/O-Zugriffe mache ich meistens über 4 Funktionen: My_Special_IO_Init(); My_Special_IO_Status(); My_Special_IO_Read(); My_Special_IO_Write(); "My_Special_IO" ist z.B. CAN, I2C, ADC usw. Ich editiere meine Keil-Programme gerne mit Borland-C wegen der guten deutschsprachigen Online-Hilfe und nehme den Compiler auch zum Syntaxcheck. Mit den nachfolgenden Macros geht das auch ziemlich gut. Dann kann der Keil ja so schlimm wohl nicht sein. Einzelne Routinen, die keine I/O-Register direkt zugreifen lasse ich auch dort schon mal laufen, um die Funktion zu testen oder z.B. ob ich die Formatstrings bei printf() und schanf() richtig geschrieben habe. Peter #ifdef _TURBOC_ #define bit char #define xdata #define idata #define bdata #define pdata #define data #define code #define sfr char #define sbit char #define sfr16 int #define interrupt /##/ // comment #define at ;/##/ #endif
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.