Hallo zusammen, ich möchte gerne einen 2-Kanal Zähler bauen der 2 getrennte Kanäle zählen kann und diese Zählerstände über serielle Kommunikation in regelmäßigen Abständen übertragen kann. Ich habe dafür den ATTINY13 ins Auge gefasst, bin mir aber nicht sicher ob ich mein Vorhaben damit realisieren kann. Ich weiß, dass der attiny13 recht begrenzt in seiner Ausstattung ist. Ich denke die 1KB Flash dürften das größte Problem darstellen, zumal ich ja recht viele Funktionen implementieren muss. Ich habe den attiny13 aus verschiedenen Gründen angedacht: - Klein (8PDIP), - Außreichende Anzahl Ports (2 PortPins fürs Zählen, + 1 Port für Serielle Kommunikation) - Kalibrierter interner Oszillator, - Kaum externe Beschaltung notwendig Je mehr ich darüber nachdenke komme ich aber zu der Ansicht dass der attiny13 wegen seinem begrenzten Flashspeicher und nur einem 8-Bit Zähler nicht sinnvoll zu verwenden wäre. Den 8-Bit Timer würde ich aber nicht fürs Zählen der PortPins verwenden, sondern eher für das Senden der seriellen Daten. Das Zählen könnte ich über Software realisieren. Was habt ihr für eine Meinung? Ich wäre sehr Froh von eurer Erfahrung profitieren zu können. Viele Grüße und schon mal Dank im Voraus, Florian
Wie weit muß er denn zählen? Für große Zahlen ist der RAM zu klein. Bitte genauer spezifizieren. Stoppuhr, Frequenzzähler? Wie hattest du dir das zählen in SW vorgestellt.
Dann nimm einen Tiny85, der hat 8k und eine USI ;-)
Florian schrieb: > Ich weiß, dass der attiny13 recht begrenzt in seiner Ausstattung ist. > Ich denke die 1KB Flash dürften das größte Problem darstellen Die sind das kleinste Problem. Mit 1k kommst du locker aus. Aber die fehlende Hardware-UART würde mir mehr Kopfzerbrechen machen. > Was habt ihr für eine Meinung? Nimm dir einen vernünftigen Tiny, der über die Hardware verfgt, die du brauchst. Alles andere ist absichtliches sich selbst Prügel zwischen die Beine werfen. Der Flash und das SRAM sind nicht deine bestimmenden Faktoren. Die Hardware-UART ist es und je nachdem wie schnell deine Pulse sind, die du zähen willst bzw. wo die herkommen, kommt auch hier noch ein Limit dazu. Es lohnt nicht, hier um Pfennigbeträge zu feilschen. Was du dir an Cent beim µC sparst, steckts du als Euros in Form deiner Arbeitszeit wieder rein.
Hallo zusammen, oh, ich muss sagen ich bin überwältigt über das schnelle Feedback. Also, ich hole etwas weiter aus: Ich möchte die Pulse von einem Anemometer und einem Regenmesser zählen. Das Anemometer schickt pulse zwischen 0,4 Hz und 100 Hz. Der Regensensor immer dann wenn eines der Kippschälchen voll ist, also recht langsam. Beide Sensoren sind vereinfacht gesagt Reedschalter. Ich möchte die Zählerstände jeweils kumulieren und in einem Intervall von einer Minute übermitteln. Das bedeutet im Endeffekt, dass der Zähler für das Anemometer innerhalb einer Minute auf 6000 ansteigt, evtl etwas mehr oder auch deutlich weniger. Der Regenmesser dürfte unkritisch sein, da ich nicht denke dass wir in Deutschland je einen Monsun in einem solchen Ausmaß haben werden dass da ein Pufferüberlauf stattfinden würde. :-) Viele Grüße, Florian
Konzept? schrieb: > Wie weit muß er denn zählen? Für große Zahlen ist der RAM zu klein. Quatsch. Mit 64 Byte kannst Du bequem solange zählen, bis die Sonne explodiert und die Erde aufhört zu existieren. Peter
Florian schrieb: > Das bedeutet im Endeffekt, dass der Zähler > für das Anemometer innerhalb einer Minute auf 6000 ansteigt Das sind für den ATtiny13 keine Zahlen, sondern klitzekleine Zählchen (nur 2 Byte). Der Flash ist auch dicke ausreichend. Das einzige Problem ist, eine Datenübertragung zu wählen, die ohne Quarz auskommt, (SW-)UART fällt also weg. Ich würde daher zum ATtiny25 raten, da kann man einen Quarz als F_CPU anschließen. Peter
Hallo Peter, Du hast recht, 64 Byte sind zum Zählen mehr als genug, aber ich brauche ja auch RAM für die serielle Kommunikation und etwas Logik außen herum. Ich befürchte daher dass der Rest wesentlich größer sein wird als 64 Byte. Vorallem wenn ich Software UART machen muss. Peter Dannegger schrieb: > Quatsch. > Mit 64 Byte kannst Du bequem solange zählen, bis die Sonne explodiert > und die Erde aufhört zu existieren.
Florian schrieb: > Hallo Peter, > Du hast recht, 64 Byte sind zum Zählen mehr als genug, aber ich brauche > ja auch RAM für die serielle Kommunikation und etwas Logik außen herum. Ah geh. Was brauchst du denn da. 10 Byte, 20? Wenns mehr als 20 sind, sollten wir uns mal über Speicher-Urassen unterhalten. > Ich befürchte daher dass der Rest wesentlich größer sein wird als 64 > Byte. Quatsch > Vorallem wenn ich Software UART machen muss. Dann mach halt keine. Du musst dir ja nicht unbedingt einen Tiny nehmen, der keine Hardware UART hat.
Peter Dannegger schrieb: > Das einzige Problem ist, eine Datenübertragung zu wählen, die ohne Quarz > auskommt, (SW-)UART fällt also weg. > Ich würde daher zum ATtiny25 raten, da kann man einen Quarz als F_CPU > anschließen. Hallo Peter, das befürchte ich auch, allerdings fällt mir gerade noch eine weitere Hürde ein, die ich vollkommen vergessen habe: Ich möchte die Daten gerne über Funk übertragen. An sich ist das nicht das Problem, aber für den Sender/Empfänger muss ich eine Manchester Kodierung verwenden. Das kommt daher, dass der Empfänger als einfacher Pendel-Empfänger gebaut ist. Ich verwende keine Selbst erfundene Schaltung, sondern ein Set von Conrad auf 868 MHz Basis. Somit fällt eine integrierte USI dann doch wieder weg, oder?
Selbst wenn man das Ding auf internem OSC laufen lässt, sollten einige langsame Datenraten mit wenig fehler drinnen sein, oder? Ansonsten kann ich dir den Tiny2313 oder 4313 empfehlen, der hat HW-UART. Die USI ist etwas komplizierter. Ingo
Ingo schrieb: > Selbst wenn man das Ding auf internem OSC laufen lässt, sollten einige > langsame Datenraten mit wenig fehler drinnen sein, oder? 10% sind 10%. Egal bei welcher Datenrate.
Florian schrieb: > das befürchte ich auch, allerdings fällt mir gerade noch eine weitere > Hürde ein, die ich vollkommen vergessen habe: Ich möchte die Daten gerne > über Funk übertragen. Na das fällt dir ja bald ein. > An sich ist das nicht das Problem, aber für den > Sender/Empfänger muss ich eine Manchester Kodierung verwenden. Das kommt > daher, dass der Empfänger als einfacher Pendel-Empfänger gebaut ist. Ich > verwende keine Selbst erfundene Schaltung, sondern ein Set von Conrad > auf 868 MHz Basis. Welches Set?
Florian schrieb: > Ich möchte die Daten gerne > über Funk übertragen. An sich ist das nicht das Problem, aber für den > Sender/Empfänger muss ich eine Manchester Kodierung verwenden. Das kommt > daher, dass der Empfänger als einfacher Pendel-Empfänger gebaut ist. Ich > verwende keine Selbst erfundene Schaltung, sondern ein Set von Conrad > auf 868 MHz Basis. > Somit fällt eine integrierte USI dann doch wieder weg, oder? Also ich pack gleich meine Gummihandschuhe aus und ziehe Dir ALLE Würmer persönlich aus der Nase ! - Zählvorgänge <65000 = 16bit = 2byte (Tiny13, Tiny25/45/85) - Funkübertragung via Modul, das wie angesteuert wird ? Seriell, SPI, parallel ?? - Was sind noch für Würmer versteckt ? Wenn Du's Dir leicht machen willst nimm gleich einen 16bitter oder 32bitter, da kannst Du dann in einem Register zählen :-P
> 10% sind 10%. > Egal bei welcher Datenrate. Ah, Sorry. Ich hatte es grad mit dem Fehler verwechselt der sich aufgrund unpassender Teiler einstellt verwechselt...
Florian schrieb: > Vorallem wenn ich Software UART machen muss. Warum das denn? SW-UART braucht gegenüber HW-UART genau 0 Byte mehr.
1 | void sputchar( uint8_t c ) |
2 | {
|
3 | c = ~c; |
4 | STX_PORT &= ~(1<<STX_BIT); // start bit |
5 | for( uint8_t i = 10; i; i-- ){ // 10 bits |
6 | _delay_us( 1e6 / BAUD ); // bit duration |
7 | if( c & 1 ) |
8 | STX_PORT &= ~(1<<STX_BIT); // data bit 0 |
9 | else
|
10 | STX_PORT |= 1<<STX_BIT; // data bit 1 or stop bit |
11 | c >>= 1; |
12 | }
|
13 | }
|
Wenn Du die Zahlen als ASCII übertragen willst, brauchst Du nur einen Puffer von genau:
1 | char tx_buff[sizeof("65535")]; |
2 | uint16_t count; |
3 | utoa( count, tx_buff, 10 ); |
Peter
Hallo zusammen, also das Funk-Set ist dieses hier: http://www.conrad.de/ce/de/product/190939/Funk-Sende-Empfaenger-Set-868-MHz-Baustein-Sender-3-12-VACDC-Empfaenger-5-VACDC-Reichweite-max-200-m/2401030&ref=list Die Übertragung ist eigentlich simpel: 1 Pin an der MCU generiert das Rechtecksignal für den Sender (Manchester-Codiert, da der Empfänger ein Pendelempfänger ist) Wenn ich das richtig verstehe, ist die Datenmenge dann 4 Byte + 1 Byte Präambel um den Empfänger einschwingen zu lassen. 5 Byte sind nun nicht das Problem, selbst wenn es mehr sind (8, 10 oder wieviele auch immer) ist das aber meiner Meinung nach erst einmal nicht relevant. Noch was generelles: Es tut mir leid, wenn ihr der Meinung seid, mir alles aus der Nase ziehen zu müssen. Ich bemühe mich so ausführlich wie möglich zu sein, dabei aber nicht zu viel drum herum zu reden. Ich bin halt noch recht neu im Forum. (Ich weiß, ich schreibe im Moment als Gast, das behebe ich noch)
Florian schrieb: > Die Übertragung ist eigentlich simpel: 1 Pin an der MCU generiert das > Rechtecksignal für den Sender (Manchester-Codiert, da der Empfänger ein > Pendelempfänger ist) Und dabei gibt es so schöne Funkmodule, die man über eine UART anspricht. Aber ok. Na gut, Manchester zu erzeugen wird dich jetzt auch nicht umbringen. So aufwändig ist das dann auch wieder nicht. Sieht die SW-Uart von PeDa eben ein bischen anders aus. Nicht viel, aber ein bischen anders.
Gibt's da nicht auch Funkmodule die die normal funktionieren ohne Manchester? Ingo
Karl Heinz Buchegger schrieb: > Na gut, Manchester zu erzeugen wird dich jetzt auch nicht umbringen. So > aufwändig ist das dann auch wieder nicht. Sieht die SW-Uart von PeDa > eben ein bischen anders aus. Nicht viel, aber ein bischen anders. Also ich scheue mich nicht davor eine Kodierung zu implementieren. Ich habe auch keine Probleme mit der Programmierung. Ich habe nur leider nicht so viel Erfahrung mit der reinen C-Umgebung in den Tiny/Mega Architekturen. Deshalb frage ich ja auch hier nach euren Erfahrungswerten. Ich habe keine Ahnung wieviel Flash ein Programm mit 10, 100 oder 1000 Zeilen Code verbrauchen wird. Ich weiß auch nicht genau wieviel RAM das Programm dann in Anspruch nehmen wird. Klar, jede Variable verschluckt etwas Speicher. Wenn ich nun aber alle Antworten hier zusammenfasse, scheint es dennoch so zu sein, dass ein attiny13 / 15 dafür geeignet zu sein scheint. Auch wenn es vielleicht etwas beengt sein mag, und ich aus Bequemlichkeit auf vorgefertigte LIBs verzichten muss.
Florian Trück schrieb: > Karl Heinz Buchegger schrieb: >> Na gut, Manchester zu erzeugen wird dich jetzt auch nicht umbringen. So >> aufwändig ist das dann auch wieder nicht. Sieht die SW-Uart von PeDa >> eben ein bischen anders aus. Nicht viel, aber ein bischen anders. > > Also ich scheue mich nicht davor eine Kodierung zu implementieren. Ich > habe auch keine Probleme mit der Programmierung. Ich habe nur leider > nicht so viel Erfahrung mit der reinen C-Umgebung in den Tiny/Mega > Architekturen. Sieh dir Macnhester mal genauer an. Das ist nicht anderes als eine Flanke genau in der Mitte der Bitzeit zu erzeugen. Bei einer zu übertragenden 1 ist es eine steigende Flanke, bei einer zu übertragenden 0 ist es eine fallende Flanke (oder ugekehrt, je nach deinen Vorlieben) > > Deshalb frage ich ja auch hier nach euren Erfahrungswerten. Ich habe > keine Ahnung wieviel Flash ein Programm mit 10, 100 oder 1000 Zeilen > Code verbrauchen wird. Die Anzahl der Zeilen spielt weniger die Rolle. Das was in den Zeilen steht, ist es. Manchestercodierung kostet dir ca. 10 bis 15 Befehle auf Assemblerebene (großzügig geschätzt). Du hast bei 1k Flash ca 1000 Befehle zur Verfügung. Noch Fragen?
Guck doch einfach auf der Atmel Homepage mal nach, ob's noch andere Controller mit mehr Speicher und RAM im SO8-W Gehäuse gibt. Aber grundsätzlich reicht der wohl für n bissel zählen und ausgeben. Ingo
Florian Trück schrieb: > Wenn ich nun aber alle Antworten hier zusammenfasse, scheint es dennoch > so zu sein, dass ein attiny13 / 15 dafür geeignet zu sein scheint. Auch > wenn es vielleicht etwas beengt sein mag, und ich aus Bequemlichkeit auf > vorgefertigte LIBs verzichten muss. OK zum letzten mal, NIMM einen Tiny85 wenn's schon AVR 8pinner sein muß ! Du kannst auch in Assembler programmieren wenn's Dir lieber ist ...
Ingo schrieb: > Guck doch einfach auf der Atmel Homepage mal nach, ob's noch andere > Controller mit mehr Speicher und RAM im SO8-W Gehäuse gibt. Braucht er doch gar nicht. Speicher hat er mehr als genug.
Ingo schrieb: > Gibt's da nicht auch Funkmodule die die normal funktionieren ohne > Manchester? Mag sein, sogar welche die mit UART gesteuert werden, aber ich wollte jetzt eigentlich nicht meinen Geldbeutel leeren, um noch mehr Hardware zu kaufen. Ich mag eigentlich wenn möglich minimalistisch bleiben und so wenig wie möglich zukaufen. Das Funkmodul-Set ist mir halt in die Hände gefallen und da ich es jetzt habe, wäre es auch sinnvoll es einzusetzen statt noch eins zu kaufen.
Florian Trück schrieb: > Ich mag eigentlich wenn möglich minimalistisch bleiben und so wenig wie > möglich zukaufen. Das Funkmodul-Set ist mir halt in die Hände gefallen > und da ich es jetzt habe, wäre es auch sinnvoll es einzusetzen statt > noch eins zu kaufen. Na dann mach das in Gottes Namen. Die Schwierigkeit beim Manchester Codieren liegt ja nicht beim Sender, sondern darin den Empfänger zu synchronisieren. Im Sender ist Manchester Pipifax.
@ Karl Heinz Warum hast du deinen Manchester-SW-Code wieder rausgenommen, sah auf den ersten Blick doch ok aus. Ingo
Karl Heinz Buchegger schrieb: > Die Anzahl der Zeilen spielt weniger die Rolle. Das was in den Zeilen > steht, ist es. Manchestercodierung kostet dir ca. 10 bis 15 Befehle auf > Assemblerebene (großzügig geschätzt). Du hast bei 1k Flash ca 1000 > Befehle zur Verfügung. Noch Fragen? Aha, das ist jetzt mal ein Erfahrungswert der mir deutlich weiter hilft. :-) Jetzt habe ich mal eine Hausnummer um mich orientieren zu können. Also ist es mein Ziel so simpel und minimalistisch wie möglich zu sein, um unter dieser Grenze zu bleiben.
Florian Trück schrieb: > Auch > wenn es vielleicht etwas beengt sein mag, und ich aus Bequemlichkeit auf > vorgefertigte LIBs verzichten muss. Du scheinst irgendwie eine völlig falsche Vorstellung zu haben. Für das was du vorhast, ist der Tiny13 mehr als ausreichend. Wenn du den Speichermässig zu 40% auslastest, dann hast du schlecht programmiert. Die ursprüngliche Empfehlung basierte darauf, dass du dir den Teil "Datenübertragung' mit einer UART um Zehnerpotenzen einfacher machen kannst (vor allem auf der Empfangsseite) und das für einen Mehrpreis von 30 oder 40 cent.
Florian Trück schrieb: > Aha, das ist jetzt mal ein Erfahrungswert der mir deutlich weiter hilft. > :-) Jetzt habe ich mal eine Hausnummer um mich orientieren zu können. > Also ist es mein Ziel so simpel und minimalistisch wie möglich zu sein, > um unter dieser Grenze zu bleiben. Wie kommst du darauf? Nochmal: du hast 1K Flash zur Verfügung! Das bedeutet so um die 1000 Befehle. Wenn du in deiner Anwendung geschätzte 300 oder 400 Befehle verbrauchst, dann hast du bereits so umständlich wie nur möglich programmiert. Ob du jetzt 60 oder 70 Befehle in Summe brauchst, oder gar 100 - du kriegst von Atmel kein Geld für nicht benutzten Speicher zurück. Speicher ist nicht dein Problem! Nicht bei dieser Anwendung!
Ingo schrieb: > @ Karl Heinz > Warum hast du deinen Manchester-SW-Code wieder rausgenommen, sah auf den > ersten Blick doch ok aus. Weil ich das Startbit nicht bedacht hatte, das man zur Takt-Synchronisierung benötigt.
Karl Heinz Buchegger schrieb: > Du scheinst irgendwie eine völlig falsche Vorstellung zu haben. > Für das was du vorhast, ist der Tiny13 mehr als ausreichend. Wenn du den > Speichermässig zu 40% auslastest, dann hast du schlecht programmiert. > Die ursprüngliche Empfehlung basierte darauf, dass du dir den Teil > "Datenübertragung' mit einer UART um Zehnerpotenzen einfacher machen > kannst und das für einen Mehrpreis von 30 oder 40 cent. OK, leuchtet ein. Aber ich wollte halt mit dem auskommen was da ist. Ich werde das Ganze dann nochmal überdenken. Der Grund warum ich einen tiny13 nehmen wollte war recht simpel: Er ist minimalistisch, braucht nicht viel und vorallem: Ich habe ihn in der Bastelkiste. Ich habe auch noch andere Atmels in der Bastelkiste, aber meiner Meinung nach ist ein Mega16 oder gar 32 dafür vollkommener Overkill.
Das ist schon fast kein Overkill sondern Dummheit :). Gerade für solche Minianwendungen sind die Tinys da. Ich denke mal für das was du brauchst reicht sogar ein Tiny10 oder evtl. Sogar der 5er. Aber der kann leider nicht in C Programmiert werden, das is dann was für die Assemblerleute... Ingo
Ingo schrieb: > Das ist schon fast kein Overkill sondern Dummheit :). Gerade für solche > Minianwendungen sind die Tinys da. Ich denke mal für das was du brauchst > reicht sogar ein Tiny10 oder evtl. Sogar der 5er. Aber der kann leider > nicht in C Programmiert werden, das is dann was für die > Assemblerleute... > > > Ingo Nun, Assembler ist nicht mein Ding. Ich bleibe da lieber bei dem was ich noch verstehen kann. ;-)
Hallo zusammen, ich danke euch noch einmal für all euer Feedback. Die Infos waren hilfreich für mich und ermutigen mich, mit dem tiny13 das ganze umzusetzen. Eine erste Logik für das Zählen der Impulse habe ich schon entworfen und mein Code kompiliert soweit schon einmal Fehlerfrei. Jetzt würde ich gerne noch eine Serielle Übertragung implementieren um schon einmal erste Daten zu empfangen und auswerten zu können. @Peter: Das Codeschnippsel ist sehr hilfreich für mich. Aus welcher Deiner Libs ist es? Ich würde mir gern noch den Rest davon ansehen um weitere Eingebungen zu erhalten. Viele Grüße und Dank, Florian
Karl Heinz Buchegger schrieb: > Nochmal: du hast 1K Flash zur Verfügung! Das bedeutet so um die 1000 > Befehle. Ich kriege da aber nur 512 Befehle raus, und das auch nur, wenn ich auf lds/sts verzichte... ;-) Xundes Neues aus dem Flachland... ...
Hannes Lux schrieb: > Karl Heinz Buchegger schrieb: >> Nochmal: du hast 1K Flash zur Verfügung! Das bedeutet so um die 1000 >> Befehle. > > Ich kriege da aber nur 512 Befehle raus, und das auch nur, wenn ich auf > lds/sts verzichte... ;-) AUtsch. Ich hab die Word-Architektur verschwitzt. Danke für die Korrektur. Allerdings: Auch mit ~500 Befehlen hat er für dieses Projekt mehr Platz als er braucht. > > Xundes Neues aus dem Flachland... Detto (also jetzt nicht aus dem Flachland)
Also bis jetzt sieht es so aus: AVR Memory Usage ---------------- Device: attiny13 Program: 98 bytes (9.6% Full) (.text + .data + .bootloader) Data: 13 bytes (20.3% Full) (.data + .bss + .noinit) Build succeeded with 0 Warnings... Die Logik für das Zählen incl. zweier Variablen von 32 bit Größe habe ich schon. So wie das aussieht kann ich da noch jede Menge Zeug reinstecken. Wenn ich sparsam bleibe, kann ich sogar noch ein paar 1wire Sensoren abfragen und deren Werte gleich über UART mit dazu schicken. :-o
Hallo mal wieder, ich stoße gerade auf ein kleines Problem beim umsetzen meiner Pläne. Ich entwickle die Software im Atmel Studio 6 was soweit auch super funktioniert. Nun simuliere ich den attiny13 mit meinem code und der erste Zähler funktioniert soweit gut. Der zweite funktioniert leider garnicht. Ich habe keine Ahnung ob das an meinem Code liegt, oder ob einfach nur der Simulator nicht so astrein ist, wie ich es mir dachte. Ich teste indem ich im IO view einen PortPin High/Low schalte und mittels BreakPoints die Zustände überwache. Ich habe bisher noch keine entprellung implementiert, also bitte nicht deshalb meckern. Da das im Simulator noch nicht von Relevanz ist, sollte das also nicht das Problem sein. Der Code sieht bisher so aus:
1 | struct { |
2 | unsigned _wind_state:1; |
3 | unsigned _rain_state:1; |
4 | unsigned _wind_last:1; |
5 | unsigned _rain_last:1; |
6 | } s; |
7 | |
8 | int main(void) { |
9 | |
10 | DDRB &= (0 << DDB0); // PB0 als Eingang |
11 | DDRB &= (0 << DDB1); // PB1 als Eingang |
12 | DDRB |= (1 << DDB4); // PB4 als Ausgang |
13 | |
14 | while(1) { |
15 | s._wind_state = PINB & (1<<PINB0); |
16 | s._rain_state = PINB & (1<<PINB1); |
17 | |
18 | if (s._wind_state != s._wind_last) { |
19 | if(s._wind_state == 1) { |
20 | _counter_wind ++; |
21 | }
|
22 | s._wind_last = s._wind_state; |
23 | }
|
24 | |
25 | if (s._rain_state != s._rain_last) { |
26 | if(s._rain_state == 1) { |
27 | _counter_rain ++; |
28 | }
|
29 | s._rain_last = s._rain_state; |
30 | }
|
31 | }
|
32 | |
33 | return 0; |
34 | }
|
Hat jemand eine zündende Idee warum PB0 soweit funktioniert, aber PB1 nicht?
Bits sind nur bei 1 wahr, daher:
1 | s._rain_state = !!(PINB & (1<<PINB1)); |
Diese ganze Bitterei kostet Dich richtig viel Code. Wenn möglich sollte man auch für Bits besser ein uint8_t nehmen. Peter
Peter Dannegger schrieb: > Bits sind nur bei 1 wahr, daher: s._rain_state = !!(PINB & (1<<PINB1)); Ich habe gerade Mühe den Codeschnippsel zu verstehen. Ist das eine doppelte inversion? Ich frage mich, warum es dann bei der ersten Variable funktioniert. Peter Dannegger schrieb: > Diese ganze Bitterei kostet Dich richtig viel Code. > Wenn möglich sollte man auch für Bits besser ein uint8_t nehmen. Ich habe bisher keinen nennenswerten Unterschied in der Größe feststellen können, aber ich werde es gern beherzigen. Was mir allerdings gerade auffällt: Im AVR Studio 4 ist nach dem Kompilieren der Code 104 Bytes groß, im Studio 6 ist er 312 Bytes. Ist der neue Kompiler nicht so gut in der optimierung?
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.