Ich habe bisher Mikrocontroller in Pascal programmiert. Aber mit der von mir verwendeten Entwicklungsumgebung war ich in der freien Variante auf Mega8 oder Mega88 AVRs beschränkt. Nun habe ich mir das AtmelStudio v7 installiert und versuche erste Schritte in C um auch größere AVRs zu programmieren. Leider musste ich feststellen das bestimmte Funktionen wie automatisches Entprellen von bestimmten Eingängen, Variablen als bit deklarieren, einfaches Einbinden von Hardwarefunktionen usw. fehlen. Muss ich diese kuschelweich und Wohlfühlfunktionen nun alle selbst irgend wie schreiben oder gibt es fertige Bibliotheken für eben diese Hardwarefunktionen (Schrittmotoren, LCD-Displays mit HD44780, interne Timer, PWM usw.) Das Meiste davon kann ich mir ja selbst stricken indem ich die internen Register entsprechend setze, aber wie sieht es mit Tastenentprellen aus oder vor Allem Bitvariablen? Zu denen habe ich bisher noch nichts gefunden. Frank
Ich kenne Pascal nicht, aber eventuell ist bool das was Du in C für Deine Bitvariablen suchst. Oder Bitfelder mit Breite 1. Philipp
Hallo, der AVR, unterstützt keine Bitvariablen, dies würde eine Bitarithmetik bedingen, so dass man auf Byte ausweicht. typedef uint8_t bit_t; Tasten entprellt man mit dem Timer-Verfahren (nach Peter Dannegger). https://www.mikrocontroller.net/articles/Entprellung Beitrag "Universelle Tastenabfrage" Evtl. ist für Dich LunaAVR als Übergang von Pascal eine Möglichkeit. Die Tastenentprellung nach Peter Dannegger ist genauso als Interface verfügbar.
Hast du schon das Tutorial hier gelesen? Das sollte viele deiner fragen erschlagen, gerade das Thema über Entprellung.
Frank B. schrieb: > Leider musste ich feststellen das bestimmte Funktionen wie automatisches > Entprellen von bestimmten Eingängen, Variablen als bit deklarieren, > einfaches Einbinden von Hardwarefunktionen usw. fehlen. Das macht das Arduino-Umfeld, daher ist es so beliebt. Allerdings schrebt man beim Arduino besser nur funktionierende Programme, Debugger und Refactoring und ähnliches gibt es nicht.
Frank B. schrieb: > Zu denen habe ich bisher noch nichts gefunden. Weitersuchen. Es gibt Bibliotheken für praktisch alles in C. P.S. Genau wie beim Arduino, trotzdem werden Arduino-user selbst von halbgebildeten (das sind die meisten) C-usern angespuckt.
:
Bearbeitet durch User
Marc V. schrieb: > Frank B. schrieb: > P.S. > Genau wie beim Arduino, trotzdem werden Arduino-user selbst von > halbgebildeten (das sind die meisten) C-usern angespuckt. Nana...
Rene H. schrieb: > Marc V. schrieb: >> Frank B. schrieb: > >> P.S. >> Genau wie beim Arduino, trotzdem werden Arduino-user selbst von >> halbgebildeten (das sind die meisten) C-usern angespuckt. > > Nana... Immerhin spricht der Arduinoanier C++. Als mir vor kurzem im Büro fad war, hab ich was in C++11 ausprobieren wollen und der schnellste Weg dahin zu kommen, war ArduinoIDE installieren. Kommt ein AVR-GCC 4.9.1 mit, der kann C++11 und fast alles von C++14. Aber das ist ja für echte C-Programmierer Teufelszeug. @Frank B.: Arduino ist nicht wirklich schlecht. Und als Unzugsvehikel ganz ok. Vor allen gibt's da funktionierend HW für kleines Geld. Mega328 auf der 32-Pin DIL Platine mit USB-nach-Serial ab 2,50€. Und zum Lernen/Umsteigen: die Libs, auch von anderen kommen als Source. Da läst sich was von lernen. Im Positiven wie im Negativen ;-)
Les mal im Thread "OOP, was soll das?" oder so ähnlich. Da will man lieber selber im Speicher rum-pock-en, statt std::string verwenden. Denn da weiß man ja gar nicht was das macht (heul). Statt froh zu sein, das knifflige nur einmal machen (lassen) zu müssen. Gut, Moby will auch kein C, solange es auch ASM gibt ;-)
Carl D. schrieb: > Les mal im Thread "OOP, was soll das?" oder so ähnlich. > Da will man lieber selber im Speicher rum-pock-en, statt std::string > verwenden. Denn da weiß man ja gar nicht was das macht (heul). > Statt froh zu sein, das knifflige nur einmal machen (lassen) zu müssen. > Gut, Moby will auch kein C, solange es auch ASM gibt ;-) Den lese ich nicht, was da steht kann ich mir denken. Wenn man wissen will, was std::string macht braucht man nur ins Template zu schauen. Notfalls rein steppen im Debugger wenn man es nicht versteht. Anyway, ist nicht das Thread Thema.
Frank B. schrieb: > Ich habe bisher Mikrocontroller in Pascal programmiert. Frank B. schrieb: > Leider musste ich feststellen das bestimmte Funktionen wie automatisches > Entprellen von bestimmten Eingängen, Variablen als bit deklarieren, > einfaches Einbinden von Hardwarefunktionen usw. fehlen. Wenn Dich niemand zu C zwingt, rate ich dazu, BASCOM zu nutzen. Die von Dir genannten Details sind dort enthalten und es gibt eine Probeversion mit 4KB Kapazität zum kostenlosen herunterladen: http://www.mcselec.com/index.php?option=com_docman&task=doc_download&gid=139&Itemid=54 MfG Paul
:
Bearbeitet durch User
Paul B. schrieb: > Wenn Dich niemand zu C zwingt, rate ich dazu, BASCOM zu nutzen. Die > von Dir genannten Details sind dort enthalten und es gibt eine > Probeversion mit 4KB Kapazität zum kostenlosen > herunterladen: > http://www.mcselec.com/index.php?option=com_docman&task=doc_download&gid=139&Itemid=54 > > MfG Paul Das hat auch den Vorteil, daß man nicht mehr so komplizierte Susdrücke schreiben muß. Der Programmierer darf sich nämlich um Zwischenergebnisse bei Ausdrücken mit mehr als 2 Operaden selbst kümmern. Das ist wie Assembler, nur eben mit anderen Befehlen. @Frank B. Sei schlau und zwing dich selbst zu C. Da hast du die Lehrzeit wenigstens nicht vertan.
:
Bearbeitet durch User
Michael B. schrieb: > Allerdings schrebt man beim Arduino besser nur funktionierende > Programme, Debugger und Refactoring und ähnliches gibt es nicht. Es hält dich doch keiner davon ab, Arduino Code in Atmel Studio zu entwickeln. Beitrag "Arduino Library unter Atmel Studio 6.2"
Karl M. schrieb: > Hallo, > > der AVR, unterstützt keine Bitvariablen, dies würde eine Bitarithmetik > bedingen, so dass man auf Byte ausweicht. > > typedef uint8_t bit_t; Und welchen Vorteil soll sowas gegenüber bool haben? Philipp
Rene H. schrieb: > Carl D. schrieb: >> Aber das ist ja für echte C-Programmierer Teufelszeug. > > Sagt wer? C ist eine Sprache, die einfach genug ist, dass man sie mit vertretbarem Aufwand halbwegs oder gar weitgehend verstehen kann. Es mag Leute geben, die C++ verstehen. Aber das sind wohl nur ein paar wenige, die wohl ihr Leben weitgehend C++ widmen. Auch gewöhnliche Programmierer mögen gewisse C++-Teilmengen sinnvoll einsetzen können. Und ich habe auch schon C++-Code geschrieben (freiwillig, statt C zu verwenden). Aber ich fühle mich wohler, wenn ich C schreibe. Einfach weil ich C weit besser verstehe als C++. Philipp
Paul B. schrieb: > Wenn Dich niemand zu C zwingt, rate ich dazu, BASCOM zu nutzen. Die von > Dir genannten Details sind dort enthalten und es gibt eine Probeversion > mit 4KB Kapazität zum kostenlosen > herunterladen: Ich schreibe hier vom Smartphone aus, daher als Gast. (Habe leider meine Passwörter nicht im Kopf ) Nein es zwingt mich niemand, C zu benutzen. Aber wenn ich bei Pascal bleibe (AVRco) kann ich die Mega8/88 auch weiterhin voll ausnutzen. Aber 480 bis 980€ für die Vollversion sind mir für reine Hobbyanwendungen eben doch etwas viel. Daher möchte ich schon getne auf C umsteigen, weil es da auch mehr Unterstützung gibt und weil ich damit auch Plattformunabhängig bin und später auch mal gerne auf ARM weiter machen möchte. Ich werde mich halt in C und seine Feinheiten einarbeiten, auch wenn es dann heisst, wieder nahezu von Vorn anzufangen. Frank
> Aber mit der von mir verwendeten Entwicklungsumgebung war ich in der freien Variante auf Mega8 oder Mega88 AVRs beschränkt. Und die paar Taler fuer die Bezahlversion sind schon ueberrissen ? Na, dann.
:
Bearbeitet durch User
Wie wäre es damit:
1 | #include <stdbool.h> |
2 | bool var = true; |
Oder geht das nicht bei Atmel?
Oh D. schrieb: >> Aber mit der von mir verwendeten Entwicklungsumgebung war ich in der freien > Variante auf Mega8 oder Mega88 AVRs beschränkt. > > > Und die paar Taler fuer die Bezahlversion sind schon ueberrissen ? > Na, dann. Ist halt wie mit allem, entweder man kann es selber oder man muss andere dafür bezahlen. Nur manche Zeitgenossen verstehen das nicht so recht...
EsLebeC99 schrieb: > Wie wäre es damit: > #include <stdbool.h> > bool var = true; > > Oder geht das nicht bei Atmel? Geht schon, ist aber keine Bitarithmetik. sizeof(bool) ist mindestens eins, also mindestens so gross wie ein unsigned char.
Frank B. schrieb: > vor Allem Bitvariablen? Da musst du sowieso aufpassen. Die Möglichkeit, ein einzelnes Bit anzusprechen, gibt es nur auf ganz wenigen Controllern. Wenn auf anderen Controllern 8 "bool"s in 1 char gezwängt werden, dann kann es durchaus sein, dass der Code langsamer ist, weil das Zeug immer auseinandergepriemelt werden muss. Und es bleibt nur zu hoffen, dass der Compiler mit dem Packen der 8 bool in 1 char kein Semaphorenproblem erzeugt... Auf jeden Fall verwende ich als kleinste unteilbare Einheit immer einen char.
Frank schrieb: > Ich werde mich halt in C und seine Feinheiten einarbeiten, auch wenn es > dann heisst, wieder nahezu von Vorn anzufangen. Naja, so ganz von vorn wohl nicht, denn mit Pascal im Kreuz wirst du auch in C eher flottkommen als die meisten Komplett-beginner. Du mußt dir bei C eigentlich nur ein paar grundsätzliche Dinge merken, um nicht auf die Nase zu fallen: 1: eigentlich alles hat in C einen oder mehrere Seiteneffekte. Übersieht man die, dann Bauchlandung. 2. C kennt von hause aus an simplen Datentypen NUR 4 Stück: char, int, float und Zeiger. Dabei gibt es keinerlei Bedeutungsschranke zwischen char und int. Zu den Datentypen gibt es Attribute und es gibt Default-Typen. Beispiel: int A, long int A, short int A, long long int A. Dabei kann man dasint weglassen, so daß viele sich nur die Attribute eingeprägt haben, also long A, short A. Genauso geht es mit den Attributen signed und unsigned. Alles anderen Bezeichnungen werden vor dem eigentlichen Kompilieren auf diesen Grundbestand heruntergebrochen. Einen boolean Datentyp gibt es nicht. 3. In C wurde auf Teufel komm raus an lesbaren Wörtern gespart. Stattdessen gibt es einen Sack voll Komginationen an sonstigen druckbaren Zeichen, die als Quasi-Schlüsselwörter herhalten müssen. Ist Kontextbezogen, z.B, A oder A kann was verdammt unterschiedliches bedeuten, je nach Kontext. 4. C wurde nicht logisch, sondern diktatorisch erfunden. Das heißt, daß du ne Menge Dinge eben LERNEN mußt, anstelle VERSTEHEN. Immer nach dem Motto "Das ist hier so!" Mein Rat: Schreibe auch in C eher bieder und vermeide sowas wie Husarenstückchen und Heldentum in deinen Quellen. Dann ist auch C ganz gut benutzbar. W.S.
Ich will mich auch nicht als arduino-Freund bezeichnen, allerdings muss man trotzdem ehrlich genug sein und den Entwicklern Respeckt für ihre Arbeit zollen. Neben den AVRs gibt es zumindest einen STM32 Port und auch einen für ESP8266. Wenn man da nicht die Arduino-IDE benutzt sondern seine normale Entwicklungsumgebung kann man auch gut debuggen. Insbesondere die USB-Device Unterstützung für die billigen STM32F103 Boards ist nicht schlecht. Jedenfalls kann man damit sehr schnell was zusammenstricken, größere kommerziele Projekte würde ich damit aber auch nicht machen.
Paul B. schrieb: > rate ich dazu, BASCOM zu nutzen So kann man eine Programmierumgebung auch kaputt machen!
W.S. schrieb: > 2. C kennt von hause aus an simplen Datentypen NUR 4 Stück: char, int, > float und Zeiger. Dabei gibt es keinerlei Bedeutungsschranke zwischen > char und int. Zu den Datentypen gibt es Attribute und es gibt > Default-Typen. Beispiel: int A, long int A, short int A, long long int Das ist so auch nicht richtig. _Bool, char, short, int, long, long long und die unsigned Varianten sowie float, double und long double sind alles eigenständige Typen. Nix mit Attributen. W.S. schrieb: > Einen boolean Datentyp gibt es nicht. Doch den gibts: _Bool In stdbool.h steht dann
1 | #define _Bool bool
|
:
Bearbeitet durch User
W.S. schrieb: > In C wurde auf Teufel komm raus an lesbaren Wörtern gespart. Das ist einer der großen Vorteile von C und abgeleiteten Sprachen. Ich muss im Moment mit VHDL arbeiten und da ist es so nervig, dass man 'Variablen' und Schlüsselwörter erst zwischen den Blockungswörtern raussuchen muss. Ich denke, es hat schon einen Grund, warum es zum Beispiel in der Mathematik "x+2=3<=>x=1" heißt und nicht "x plus zwei gleich drei, daraus folgt, x ist gleich eins."
Be S. schrieb: > Geht schon, ist aber keine Bitarithmetik. sizeof(bool) ist mindestens > eins, also mindestens so gross wie ein unsigned char. Das weiß ich nicht, vermutlich wird das so sein. Mir wäre kein Controller bekannt, der seinen Speicher bitweise (!)adressieren kann, somit muss man eh immer gleich ein Byte oder mehr lesen. Das wird vom Compiler abhängen, denke ich. Die C Speifikation gibt AFAIK nicht vor, wie der Compiler das zu lösen hat. Der wird die Bits durchaus auch stapeln düfen. Wenn man ganz sicher gehen will muss man halt ein Bitfelt deklarieren:
1 | typedef struct |
2 | {
|
3 | unsigned int Bit0 : 1; //bool |
4 | unsigned int Bit1 : 1; //bool |
5 | unsigned int Bit2_7 : 6; //unsigend, 6 Bit breit |
6 | //... bis Bit7
|
7 | }_bitfeld; |
8 | |
9 | _bitfeld var; |
10 | var.Bit0 = 1; |
11 | var.Bit2_7 = 15; |
Soviel zu "C unterstützt nur xy Typen". Man kann sich beliebige Typen beliebig zusammenfrickeln, wenn man will.
EsLebeC99 schrieb: > Die C Speifikation gibt AFAIK > nicht vor, wie der Compiler das zu lösen hat. Der wird die Bits durchaus > auch stapeln düfen. Eine direkte Beschränkung habe ich auf die Schnelle nicht gefunden, aber: - sizeof(bool) kann nicht kleiner als 1 sein. - sizeof(char), sizeof(signed char) und sizeof(unsigned char) ist 1. - Der address-of-Operator muss funktionieren (bool * muss existieren). - sizeof(bool[8]) muss 8 Mal grösser als sizeof(bool) sein.
:
Bearbeitet durch User
EsLebeC99 schrieb: > enn man ganz sicher gehen will muss man halt ein Bitfelt > deklarieren:typedef struct > { > unsigned int Bit0 : 1; //bool > unsigned int Bit1 : 1; //bool > unsigned int Bit2_7 : 6; //unsigend, 6 Bit breit > //... bis Bit7 > }_bitfeld; > > _bitfeld var; > var.Bit0 = 1; > var.Bit2_7 = 15; > > Soviel zu "C unterstützt nur xy Typen". Man kann sich beliebige Typen > beliebig zusammenfrickeln, wenn man will. Wenn man die bool-Semantik will, muss man die Bitfelder aber als bool, nicht als unsigned int anlegen. Philipp
EsLebeC99 schrieb: > Das weiß ich nicht, vermutlich wird das so sein. Mir wäre kein > Controller bekannt, der seinen Speicher bitweise (!)adressieren kann, > somit muss man eh immer gleich ein Byte oder mehr lesen. Es gibt halt welche mit Instruktionen zum Zugriff auf einzelne Bits, was dann effizienter als Verwendung der Instruktionen für logisches und / oder ist. Philipp
Be S. schrieb: > EsLebeC99 schrieb: >> Die C Speifikation gibt AFAIK >> nicht vor, wie der Compiler das zu lösen hat. Der wird die Bits durchaus >> auch stapeln düfen. > > Eine direkte Beschränkung habe ich auf die Schnelle nicht gefunden, > aber: > - sizeof(bool) kann nicht kleiner als 1 sein. > - sizeof(char), sizeof(signed char) und sizeof(unsigned char) ist 1. > - Der address-of-Operator muss funktionieren (bool * muss existieren). > - sizeof(bool[8]) muss 8 Mal grösser als sizeof(bool) sein. Solange sich das Verhalten des Programms nicht ändert, kann der Compiler weitgehend machen, was er will. Also beispielsweise auch einen bool, dessen Adresse nicht verwendet wird irgendwo in einem einzelnen Bit speichern. Wie verbreitet solche Optimierungen sind, weiß ich allerdings nicht. Philipp
Philipp Klaus K. schrieb: > Wenn man die bool-Semantik will, muss man die Bitfelder aber als bool, > nicht als unsigned int anlegen. Spielt eigentlich keine Rolle.
1 | typedef struct{ |
2 | bool A:1; |
3 | }bitfield_bool; |
4 | |
5 | typedef struct{ |
6 | unsigned int A:1; |
7 | }bitfield_uint; |
8 | |
9 | bitfield_bool X; |
10 | X.A = true; |
11 | |
12 | bitfield_uint Y; |
13 | Y.A = true; |
Kommt aufs Gleiche, ausser dass sizeof(bitfield_bool) evt. kleiner als sizeof(bitfield_uint) ist. Philipp Klaus K. schrieb: > Also beispielsweise auch einen bool, dessen Adresse nicht verwendet wird > irgendwo in einem einzelnen Bit speichern. Das stelle ich mir schwierig vor, ginge wohl nur bei lokalen Variablen, die nicht in Strukturen/Unions gepackt sind.
W.S. schrieb: > 1: eigentlich alles hat in C einen oder mehrere Seiteneffekte. > Übersieht man die, dann Bauchlandung. Definiere "Seiteneffekte". Dieser Begriff hat im Kontext von Programmiersprachen eigentlich eine bestimmte Bedeutung und so gesehen hat vieles in C keine Seiteneffekte. > 4. C wurde nicht logisch, sondern diktatorisch erfunden. Das heißt, daß > du ne Menge Dinge eben LERNEN mußt, anstelle VERSTEHEN. Man kann einiges davon auch verstehen, aber manchen Leuten fällt es leichter, es zu lernen als es zu verstehen. Zumal die Geschichte dieser nicht mehr jungen Sprache mitunter einen Teil beiträgt.
:
Bearbeitet durch User
W.S. schrieb: > 4. C wurde nicht logisch, sondern diktatorisch erfunden. Das heißt, daß > du ne Menge Dinge eben LERNEN mußt, anstelle VERSTEHEN. Immer nach dem > Motto "Das ist hier so!" Schon mal K&R gelesen? C ist bislang immer noch der logischste gemeinsame Nenner der Assembler am nächsten liegenden Programmiersprachen. Gehts um irgend eine Art Betriebssystem (dazu zähle ich auch mal bare metal), kommt man um C nicht rum. Hat schon Gründe, warum C immer noch zu den best definierten Industriestandards gehört. Das kann man von C++ und den Wirth-Sprachen nicht behaupten. Was leider immer noch entsetzlich unlogisch ist, sind manche entarteten Coding-Guidelines von seiten GNU, oder der Klassiker "unsigned char* data" (Stichwort Prototypen). Da hat man in C leider zuviele Freiheiten, etwas mehr Diktatorik ist da teils sogar hilfreich. Ist halt immer eine Frage auf welcher Ebene man sich bewegt. Im industriellen Umfeld, wo Programme eine gewisse Robustheit aufweisen müssen, ist nun mal das ganze Fachwissen von ganz unten bis oben zur GUI gefragt. Zur Bool-Diskussion ist schlicht anzumerken, dass man sich unter C eben auch mit der Architektur seiner CPU auseinandersetzen muss. Ein Pascal-Bool kann auch intern ein Byte sein, muss aber nicht (sehen wir mal von 8051-Bit-Zugriffen ab). C definiert das sauberer (wenn auch die Endianness in der oben genannten Bitfeld-Notation ins Spiel kommt). Abgesehen davon: In effizientem und robusten Code haben Bools eigentlich nur als Rückgabewerte was zu suchen. Ansonsten lebt ein Bit typischerweise in einem Register, und der Programmierer sollte wissen dürfen und müssen, wo es lebt. Alles andere gehört für mich zu "bad practise".
Fitzebutze schrieb: > Abgesehen davon: In effizientem und robusten Code haben Bools eigentlich > nur als Rückgabewerte was zu suchen. Ansonsten lebt ein Bit > typischerweise in einem Register, und der Programmierer sollte wissen > dürfen und müssen, wo es lebt. Alles andere gehört für mich zu "bad > practise". Naja, ich sehe einen bool eher als eine Variable, die zwei Zustände annehmen kann. Wie das implementiert wird, ist mir meistens egal. Ich wähle auch einen uint_fast8_t, wenn nur Werte von 0...255 (oder weniger) auftreten können, genau so mache ich es mit bool. So sieht ein Leser sofort, dass nur zwei Zustände auftreten können.
Fitzebutze schrieb: > Abgesehen davon: In effizientem und robusten Code haben Bools eigentlich > nur als Rückgabewerte was zu suchen. Ansonsten lebt ein Bit > typischerweise in einem Register, und der Programmierer sollte wissen > dürfen und müssen, wo es lebt. Alles andere gehört für mich zu "bad > practise". Genau. Und die ganze Bitschieberei kostet nur Platz und Zeit. Und in den meisten Programmiersprachen ist bit setzen erheblich langsamer als AND und OR - ausser in ASM, natürlich. Kann mich nicht mehr genau erinnern welche Sprache das war, aber VAR.bit = 1 war ungefähr dreimal langsamer und brauchte dreimal so viel Speicher wie VAR |= (1<<bit). C wird das wahrscheinlich sowieso optimieren und AND bzw. OR daraus machen aber trotzdem ist die Erwartung, dass Pascal ein bit wirklich als bit speichert, etwas zu optimistisch. Und wenn doch, kostet es nur Zeit und Speicher, bringt also absolut keine Vorteile. EDIT: C kann mit #define vieles übersichtlicher machen, z.B:
1 | #define SetBit(ADDRESS,BIT) ((ADDRESS) |= (1<<(BIT))) //
|
sind genau 5 Takte.
:
Bearbeitet durch User
Carl D. schrieb: > Les mal im Thread "OOP, was soll das?" oder so ähnlich. > Da will man lieber selber im Speicher rum-pock-en, statt std::string > verwenden. Denn da weiß man ja gar nicht was das macht (heul). > Statt froh zu sein, das knifflige nur einmal machen (lassen) zu müssen. > Gut, Moby will auch kein C, solange es auch ASM gibt ;-) Hast du mal reingesehen was std::string macht? Damit meine ich statt typischen Aussagen wie "ist geil weil ist geil" oder "das macht man heute so" sich mal Fakten ansehen? std::string ist schon deshalb im Embedded-Bereich ein Wagnis, weil es, wenn die Small String Optimisation in sdt::string nicht mehr greift, dynamisch Speicherallozierung verwendet. Bei der dynamisch Speicherallozierung von std:string sind Wachstumsfaktoren von 1,5 bis 2 typisch. Im Extremfall verwendet ein std::string nach ein paar einfachen String-Operationen also fast doppelt so viel Speicherplatz wie eigentlich nötig. Wenn dein Code auch noch temporäre std::string Objekte erzeugt geht noch mehr Speicher flöten. Wenn du einen std::string verkleinerst gibt es keine Garantie dass der allozierte Speicher verkleinert wird. Small String Optimisation bedeutet Tricksereien in der internen Implementierung einiger std::string Methoden und/oder Tricksereien mit dem festen Puffer für Small String Optimisation. Zum Beispiel den Puffer als eine union zu verwenden der den String bei Small String Optimisation enthält oder den Pointer auf den allozierten Speicherbereich wenn Small String Optimisation nicht greift. Das ist nicht nur sehr unschön, die Implementierung ist weniger robust und benötigt neben mehr Daten- auch mehr Code-Speicherplatz. Zusammengefasst: Wer weiß was er macht denkt über C++ mit Standard-Lib incl. STL zweimal nach bevor er es im Embedded-Bereich verwendet.
EsLebeC99 schrieb: > Mir wäre kein Controller bekannt, der seinen Speicher bitweise > (!)adressieren kann Der gute alte 8051 kann einen Teil seines Speichers bitweise adressieren; das ist besonders für Register nützlich. Aus den oben erwähnten Gründen kann dieser Bereich aber nicht für "bool"-Variablen benutzt werden; da gibt es dann einen compilerspezifischen Typ wie z.B. "bit".
Jay schrieb: > Zusammengefasst: Wer weiß was er macht denkt über C++ mit Standard-Lib > incl. STL zweimal nach bevor er es im Embedded-Bereich verwendet. Das ist eine mutige Aussage. Es gibt derartig viele verschiedene Controller und Anwendungsbereiche, dass solche pauschalen Aussagen per Definition immer falsch sind. Hat man kleine bis mittlere Stückzahlen eines teuren Gerätes, ist der Preis des Controllers völlig irrelevant. Bei 1000 Stück enspräche der Mehrpreis eines Controllers von z.B. 1€/Stk den Kosten von <10 Arbeitsstunden. Da wird niemand wegen ein paar kB RAM herumoptimieren, das ist wirtschaftlicher Blödsinn. Andererseits kann es sein, dass man gigantische Stückzahlen >100M eines billigen Gerätes produziert. Dann kann es Sinn machen, 1 Mannjahr in die Optimierungen der Firmware eines winzigen 8-Bit-Controllers zu stecken. Hier wird man vielleicht mit Assembler anfangen, um das letzt Bit herauszuquetschen.
Be S. schrieb: > EsLebeC99 schrieb: >> Wie wäre es damit: >> #include <stdbool.h> >> bool var = true; >> >> Oder geht das nicht bei Atmel? > > Geht schon, ist aber keine Bitarithmetik. sizeof(bool) ist mindestens > eins, also mindestens so gross wie ein unsigned char. Du wirst vermutlich auch eine Weile brauchen, wenn du einen Compiler suchst, bei dem sizeof(bool) nur 0,125 ist. ;-) W.S. schrieb: > 3. In C wurde auf Teufel komm raus an lesbaren Wörtern gespart. > Stattdessen gibt es einen Sack voll Komginationen an sonstigen > druckbaren Zeichen, die als Quasi-Schlüsselwörter herhalten müssen. Für die logischen Operatoren gibt es in Standard-C auch Namen. Die benutzt nur keiner, weil sie hässlich sind. :) > Ist Kontextbezogen, z.B, A oder A kann was verdammt unterschiedliches > bedeuten, je nach Kontext. Hast du da mal ein Beispiel dafür? Mir wäre was derartiges nicht bekannt. > 4. C wurde nicht logisch, sondern diktatorisch erfunden. Das heißt, daß > du ne Menge Dinge eben LERNEN mußt, anstelle VERSTEHEN. Immer nach dem > Motto "Das ist hier so!" Man sollte unterscheiden zwischen etwas, das nicht logisch ist und etwas, dessen Logik man nur nicht erfasst hat oder nicht gut findet.
EsLebeC99 schrieb: > Jay schrieb: >> Zusammengefasst: Wer weiß was er macht denkt über C++ mit Standard-Lib >> incl. STL zweimal nach bevor er es im Embedded-Bereich verwendet. > > Das ist eine mutige Aussage. > Für ein OS würde ich die unterschreiben. Kann aus eigener Erfahrung nur sagen, Finger weg von STL im Kernel space. Gleiches gilt aber auch für die standard libc. > Es gibt derartig viele verschiedene Controller und Anwendungsbereiche, > dass solche pauschalen Aussagen per Definition immer falsch sind. > Auf einem Linux-fähigen SoC ist C++/STL im Userspace sicher gut plaziert. Aber auch da gibt es Fallstricke, nämlich die Memory-Fragmentierung, die bei klassischer C++-Programmierung mit inflationär benutzten 'new' und impliziten realloc() (std::string) irgendwann zuschlägt. Und dann hat man nach einigen Monaten Laufzeit plötzlich einen OOM panic (der u.U. nicht akzeptabel ist). Moderne Kernels sortieren zwar um, sind aber gegen gewisse Szenarien nicht gefeit. Dann muss man doch wieder in den Tiefen graben und genau wissen, was auf Systemebene abgeht. Solches Debugging kostet dann teils ähnlich wie die gesamte Entwicklung und der C++-Grundbau hat kaum Arbeit gespart, aber einen zum "vermeintlich sauberen Coden" verleitet. Fazit: Jeder sollte sich so oder so in seiner Hochsprache nicht allzu sicher fühlen. Man kann in C eine Menge Scheisse bauen, aber es in C++ zusätzlich noch nicht realisieren, dass man Scheisse baut :-)
Be S. schrieb: > Philipp Klaus K. schrieb: >> Wenn man die bool-Semantik will, muss man die Bitfelder aber als bool, >> nicht als unsigned int anlegen. > > Spielt eigentlich keine Rolle.typedef struct{ > bool A:1; > }bitfield_bool; > > typedef struct{ > unsigned int A:1; > }bitfield_uint; > > bitfield_bool X; > X.A = true; > > bitfield_uint Y; > Y.A = true; > Kommt aufs Gleiche, ausser dass sizeof(bitfield_bool) evt. kleiner als > sizeof(bitfield_uint) ist. Aber X.A = 2 wird etwas anderes ergeben als Y.A = 2. > > Philipp Klaus K. schrieb: >> Also beispielsweise auch einen bool, dessen Adresse nicht verwendet wird >> irgendwo in einem einzelnen Bit speichern. > > Das stelle ich mir schwierig vor, ginge wohl nur bei lokalen Variablen, > die nicht in Strukturen/Unions gepackt sind. Oder solche, die static sind. Philipp
Oh D. schrieb: > Und die paar Taler fuer die Bezahlversion sind schon ueberrissen ? > Na, dann. Es handelt sich hier um 480 bis 980 Euro, je nach Version, das halte ich schon für mehr als ein paar Taler und es übersteigt mein Hobbybudget schon um mindestens eine halbe Größenordnung. Klar würde ich mir die Vollversion gerne gönnen, wenn ich könnte. Allerdings bliebe dann noch, das ich mich beim Umstieg (nein, nicht ganz, ich möchte weiterhin auch AVRs benutzen) auf ARM Cortex dennoch in C einarbeiten muss. Cyblord -. schrieb: > Ist halt wie mit allem, entweder man kann es selber oder man muss andere > dafür bezahlen. Nur manche Zeitgenossen verstehen das nicht so recht... oder man muss es eben lernen ;-) Der Datentyp "bit" ist auch in Pascal nicht wirklich bitbezogen sondern benutzt ein Byte als Variable, mitsamt allen nötigen Umbrüchen innerhalb des Compilers, aber er vereinfacht halt den Umgang mit einzelnen Bits schon um einiges, auch wenn er natürlich wesentlich mehr Speicher benötigt als tatächlich nötig wäre. Ich werde mich mal soweit es geht in C einarbeiten und sehen, wie ich klar komme. Frank.
:
Bearbeitet durch User
Frank B. schrieb: > Der Datentyp "bit" ist auch in Pascal nicht wirklich bitbezogen sondern > benutzt ein Byte als Variable, Beziehst du dich hier auf eine bestimmte Implementierung, oder auf die Sprache? Denn die Sprache lässt das m.W. offen.
Carl D. schrieb: > Arduino ist nicht wirklich schlecht. Und als Unzugsvehikel ganz ok. Vor > allen gibt's da funktionierend HW für kleines Geld. Mega328 auf der > 32-Pin DIL Platine mit USB-nach-Serial ab 2,50€. Die Hardware ist jetzt nicht unbedingt mein Problem, die habe ich schon seit ich mit Mikrocontrollern angefangen habe, selbst zusammen gestrickt. Und einen Bootloader bekomme ich auch noch auf die Controller geschrieben ;-) A. K. schrieb: > Beziehst du dich hier auf eine bestimmte Implementierung, oder auf die > Sprache? Denn die Sprache lässt das m.W. offen. Ich beziehe mich hier auf die Implementierung von AVRco, die ich bisher benutzt habe. Sorry, das hätte ich klarer schreiben müssen. Frank
>> Und die paar Taler fuer die Bezahlversion sind schon ueberrissen ? >> Na, dann. > >Es handelt sich hier um 480 bis 980 Euro, je nach Version, das halte ich schon für mehr als ein paar Taler und es übersteigt mein Hobbybudget schon um mindestens eine halbe Größenordnung. Zum Glueck gibt es mehrere Anbieter. Nicht alle sind so teuer wie der elab. http://www.mikroe.com/mikropascal/ http://wiki.freepascal.org/AVR
Philipp Klaus K. schrieb: > Aber X.A = 2 wird etwas anderes ergeben als Y.A = 2. Korrekt. Wären es keine Bitfelder, wären die Ergebnisse auch nicht identisch. Bei bitfield_bool ist der automatische Cast nach bool inbegriffen. Philipp Klaus K. schrieb: > Oder solche, die static sind. Der Compiler kann dann aber nur optimieren, wenn er sicherstellen kann, dass nirgends per Zeiger auf die Variable zugegriffen wird.
дампфтроль schrieb: > Zum Glueck gibt es mehrere Anbieter. Nicht alle sind so teuer wie der > elab. Richtig, aber der gibt mir das im Eingangspost schon erwähnte Wuschelweich Rundumglücklichgefühl ;-)
Be S. schrieb: > Der Compiler kann dann aber nur optimieren, wenn er sicherstellen kann, > dass nirgends per Zeiger auf die Variable zugegriffen wird. Meines Wissens gab es nur ein Compiler der bits wirklich als bits aufbewahrt hat - dafür waren dann aber 2 Register reserviert, ich glaube r2 und r3. Es war ziemlich schnell, aber es könnten maximal 16 bitvariablen deklariert werden. Alles andere ist langsamer und braucht Speicherplatz - midestens ein Byte. Wenn es aber mehrere bitvariablen sind, sieht es natürlich viel besser aus.
Frank B. schrieb: > Muss ich diese kuschelweich und Wohlfühlfunktionen nun alle selbst > irgend wie schreiben oder gibt es fertige Bibliotheken für eben diese > Hardwarefunktionen (Schrittmotoren, LCD-Displays mit HD44780, interne > Timer, PWM usw.) Als Gelegenheitsprogrammierer brauche ich bei "C" immer viel Zeit mich zurechtzufinden. Es gibt hier viel Beispielcode, der aber angepasst werden muss und für mich öfters kryptisch aussieht. Daher bin ich dann auf Luna umgeschwenkt. Einwandfrei, solange man nicht das Maximum aus dem controller holen möchte. http://avr.myluna.de/doku.php Vielleicht auch was für dich, Beispiele: http://avr.myluna.de/doku.php?id=de:lcd4-class&s[]=hd44780 http://avr.myluna.de/doku.php?id=de:pwm-modes http://avr.myluna.de/doku.php?id=de:timer0
дампфтроль schrieb: > http://wiki.freepascal.org/AVR Freepascal (FPC) wollte ich auch schon vorschlagen, der unterstuetzt scheinbar auch den STM32. Mit Bibliotheken fuer die Hardwareansteuerung sieht es aber schlecht aus.
Jay schrieb: > Carl D. schrieb: >> Les mal im Thread "OOP, was soll das?" oder so ähnlich. >> Da will man lieber selber im Speicher rum-pock-en, statt std::string >> verwenden. ... > Zusammengefasst: Wer weiß was er macht denkt über C++ mit Standard-Lib > incl. STL zweimal nach bevor er es im Embedded-Bereich verwendet. im fraglichen Thread geht es nicht um μController, sonder ursprünglich um JavaScript, was ja mit Sicherheit einen funktionierenden Heap braucht. Ich hab natürlich noch nicht die std::string Source untersucht, denn einer der Vorteile einer Lib, die Abertausende verwenden, ist ihre große Wahrscheinlich, daß sie funktioniert. Und wenn es "Design-Bugs" gibt, dann ist man nicht der erste, der draufkommt. Ja, ist gemein andere vorzuschicken, aber so bin ich manchmal.
Carl D. schrieb: > im fraglichen Thread geht es nicht um μController, sonder ursprünglich > um JavaScript, was ja mit Sicherheit einen funktionierenden Heap > braucht. > > Ich hab natürlich noch nicht die std::string Source untersucht, denn > einer der Vorteile einer Lib, die Abertausende verwenden, ist ihre große > Wahrscheinlich, daß sie funktioniert. Und wenn es "Design-Bugs" gibt, > dann ist man nicht der erste, der draufkommt. Ja, ist gemein andere > vorzuschicken, aber so bin ich manchmal. Es war mir schon klar, dass irgendeine Ausrede kommt.
Der Keil C51 benutzt für Bitvariablen den 128Bit Bereich im SRAM und die Bitbefehle (SETB, CLR, JB, JNB).
Oh D. schrieb: >> Aber mit der von mir verwendeten Entwicklungsumgebung war ich in der freien >> Variante auf Mega8 oder Mega88 AVRs beschränkt. > > Und die paar Taler fuer die Bezahlversion sind schon ueberrissen ? > Na, dann. Naja, also 980€ - für nur einen Teil - für das Hobby, ist schon ne Menge. Nicht jeder haut dafür mal eben nen tausender raus wenn der Markt von freier Software nur so überschwemmt ist, eben mit dem Hintergrund sich da einarbeiten zu müssen. Da finde ich das schon überrissen.
>> дампфтроль schrieb: >> http://wiki.freepascal.org/AVR >Freepascal (FPC) wollte ich auch schon vorschlagen, der unterstuetzt scheinbar auch den STM32. Mit Bibliotheken fuer die Hardwareansteuerung sieht es aber schlecht aus. Die Hardware Ansteuerung in generische Bibliotheken auszulagen halt ich fuer nicht so eine gute Idee. Ich verwend auch den E-Lab, aber ohne all die Bibliotheken. Bei den Bibliotheken weiss man nicht was sie tun. Gewisse Calls sind dann blockierend waehrend man lieber nicht blockierend arbeiten wuerde.
Ich würde auch empfehlen, dass Du Dir mal LunaAVR ansiehst. Aber ansonsten will ich mit diesem (sehr vorhersehbaren) Herumgerotze in diesem Thread nichts zu tun haben. Gruß Klaus
Be S. schrieb: > Das ist so auch nicht richtig. _Bool, char, short, int, long, long long > und die unsigned Varianten sowie float, double und long double sind > alles eigenständige Typen. Nix mit Attributen. So langsam fängt es an, mich zu ärgern. Von wegen "nix mit Attributen". Begreife mal, daß eigentlich alles, was du da aufgezählt hast, eine Kombination aus Attribut + Default ist. Von wegen eigenständiger Typ. _Bool wird meist runtergebrochen auf unsigned char, manchmal auch auf ne 32 Bit Zahl (Win32 Programmierung) char ist Grundtyp und damit dem Compiler bekannt short ist Abkürzung für short int (int ist hier Default) int ist Grundtyp und damit dem Compiler bekannt long ist Abkürzung für long int long long ist ebenfalls Abkürzung, hier für long long int genau so geht es mit den anderen Attributen wie unsigned, signed und volatile. Und in ähnlicher Weise auch mit den Gleitkommazahlen. Es ist immer wieder das gleiche Schema: Attribute+Datentyp+Bezeichner. Warum begreifst du das zugrundeliegende Schema nicht? Warum meinst du, das seien eigenständige Datentypen? Wir hatten so ein Thema vor geraumer Zeit, wo jemand meinte, daß eine Umbenennung in einem Headerfile per typedef einen neuen Datentyp schaffen würde. Das ist dummer Käse, denn es handelt sich immer nur um eine Umbenennung, die im Zuge des Kompilierens schlußendlich auf die tatsächlich zugrundeliegenden Datentypen heruntergebrochen wird. W.S.
> long long ist ebenfalls Abkürzung, hier für long long int
Wenn long long eine Abk. f. long long int ist, dann ist long long int
eine Abk. für long long int long long int int. Das kann aber doch
irgendwie nicht sein, da der Compiler sich im Nirvan befindet.
Joe schrieb: > Wenn long long eine Abk. f. long long int ist, dann ist long long int > eine Abk. für long long int long long int int. Das kann aber doch > irgendwie nicht sein, da der Compiler sich im Nirvan befindet. Mit Logik auf dem Kriegsfuss ?
Marc V. schrieb: > Mit Logik auf dem Kriegsfuss ? Auf Basis der Aussage long ist Abkürzung für long int hat er streng logisch recht, auch wenn etwas Einsatz von Hirn sofort klar macht, was gemeint ist. Wenn man statt dessen definiert, dass automatisch "int" angenommen wird, wenn sonst kein anderer Basistyp angegeben ist, dann funktioniert es auch mit der Logik.
:
Bearbeitet durch User
W.S. schrieb: > Warum meinst du, das seien eigenständige Datentypen? Lies den Standard (Seite 39 ff.): > An object declared as type _Bool [...] > An object declared as type char [...] > There are five standard signed integer types, designated as signed char, > short int, int, long int, and long long int. > For each of the signed integer types, there is a corresponding (but > different) unsigned integer type (designated with the keyword > unsigned) [...] > There are three real floating types, designated as float, double, and > long double. Was genau lässt die Vermutung offen, dass die Typen nicht eingenständig sind? W.S. schrieb: > Wir hatten so ein Thema vor geraumer > Zeit, wo jemand meinte, daß eine Umbenennung in einem Headerfile per > typedef einen neuen Datentyp schaffen würde. Das ist dummer Käse, denn > es handelt sich immer nur um eine Umbenennung, die im Zuge des > Kompilierens schlußendlich auf die tatsächlich zugrundeliegenden > Datentypen heruntergebrochen wird. Das ist korrekt. Nur mit Strukturen und Unions kann man neue Typen erschaffen.
W.S. schrieb: > genau so geht es mit den anderen Attributen wie unsigned, signed und > volatile. volatile passt nicht in die Reihe. Das ist ein "qualifier", so wie const oder restrict. Die ändern an der Größe oder internen Repräsentation des Typen nichts, sondern nur an der Art, wie darauf zugeriffen wird. Marc V. schrieb: > Mit Logik auf dem Kriegsfuss ? Ob "Joe" wohl explodiert, wenn man ihn auf die in OpenSource-Kreisen häufig anzutreffenden rekursiven Akronyme hinweiset? W.S. schrieb: > Das ist dummer Käse, denn es handelt sich immer nur um eine Umbenennung, > die im Zuge des Kompilierens schlußendlich auf die tatsächlich > zugrundeliegenden Datentypen heruntergebrochen wird. Keine Umbenennung, sondern eine Einführung eines alternativen Namens. Der ursprügnliche Name bleibt ja weiterhin da. Man muss allerdings auch sagen, dass die Bezeichnung "typedef" in der Hinsicht sehr irreführend ist.
:
Bearbeitet durch User
W.S. schrieb: > Warum begreifst du das zugrundeliegende Schema nicht? Fairerweise muss man zugestehen, dass die Standards C99 und C11 nicht so formal vorgehen wie du. Deine zum Verständnis sinnvolle Unterscheidung zwischen Basistyp wie char/int und Attributen wie short/long findet sich dort nicht. Der ganze Kram wird dort uniform unter "type specifier" abgehandelt und letztlich als Liste vorgesehener "multiset" aus ebendiesen "type specifiers" präsentiert.
A. K. schrieb: > Fairerweise muss man zugestehen, dass die Standards C99 und C11 nicht so > formal vorgehen wie du. Deine zum Verständnis sinnvolle Unterscheidung > zwischen Basistyp wie char/int und Attributen wie short/long findet sich > dort nicht. Naja, so ganz durchgängig ist die ja auch nicht. Es gibt weder einen long char, noch einen unsigned float. Wobei ich es irgendwie stimmiger gefunden hätte, wenn die drei Gleitkomma-Typen nicht float, double und long double, sondern short float, float und long float geheißen hätten.
:
Bearbeitet durch User
Rolf M. schrieb: > Naja, so ganz durchgängig ist die ja auch nicht. Es gibt weder einen > long char, noch einen short float. Weshalb die Standards wohl auch davon abgesehen haben, diese Differenzierung explizit reinzuschreiben, und sich darauf beschränkten, die vorgesehenen Kombinationen explizit aufzuzählen. In C89 wiederum kommt der Begriff des Basistyps ausdrücklich vor, allerdings nicht so, wie W.S. es mit seiner Systematik und seinem "Grundtyp" gerne hätte: "The type char, the signed and unsigned integer types, and the floating types are collectively called the basic types". In der allerersten Sprachdefinition von Ritchie, vor K&R, hiess das noch "fundamental type" und beschränkte sich auf char,int,float,double. Der Rest wie short, long und unsigned und damit die ganze Kombinatorik davon kam erst danach. W.S. hat schon damit recht, dass es Bereiche in C gibt, in denen man lernen muss, was geht, statt sich auf strenge innere Logik zu versteifen. Ritchie war kein Meister logisch stimmiger Konstruktionen, sondern eher ein Pragmatiker mit Neigung zum ad hoc Durchwursteln. Weshalb man sich zwar eine Logik zurecht legen kann, diese aber nicht wirklich konsequent umgesetzt ist.
:
Bearbeitet durch User
Rolf M. schrieb: > Wobei ich es irgendwie stimmiger > gefunden hätte, wenn die drei Gleitkomma-Typen nicht float, double und > long double, sondern short float, float und long float geheißen hätten. Auf dem letzten Treffen der WG14 wurde in Vorschlag für einen neuen Gleitkommadatentyp, der auch mit nur 16 bit implementierbar ist diskutiert, und es wurde entschieden, die Arbeit daran fortzuführen. Es ist gut möglich, dass er in C22 aufgenommen wird, und er wird vermutlich short float heißen. Philipp
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.