Die 1-Wire Sensoren auslesen dauert ja schon recht lange und kann die
Mainloop merkbar verzögern. Daher habe ich mal meinen alten C51-Code auf
AVR-GCC portiert und noch etwas aufgehübscht.
Es wird eine Statemaschine im Timerinterrupt verwendet. Die
Statemaschine macht einen kompletten 1-Wire Transfer und stoppt dann den
Timer wieder. Man kann also in der Mainloop eine Aktion starten und
zyklisch abfragen, ob sie fertig ist. Die Mainloop wird also nicht
ausgebremst und kann in der Zwischenzeit andere Tasks ausführen.
Damit nicht andere Interrupts das 1-Wire Timing zerstören, werden die
kurzen Aktionen im Timerinterrupt abgewartet. Dadurch benötigt der
Interrupthandler etwa 6µs.
Damit die max 120µs des Low-Pulses eingehalten werden, dürfen andere
Interrupts nur um max 60µs verzögern. Ansonsten müssen diese Handler die
Interrupts wieder freigeben.
Bequemer Weise macht die Statemaschine auch gleich die Wartezeit für die
Wandlung mit. Sie läßt sich in 0,1s Schritten bis max 25s wählen.
Wenn man die Sensoren nicht mit parasite Power versorgen will, kann man
die entsprechenden Zeilen auskommentieren (Zeile 100, 101).
Anbei der komplette Code.
Hier die Statemaschine:
Carl D. schrieb:> Trickreich wie die Entprellung.
Der Trick ist einfach nur der, daß ich nicht schnell mal eben so
drauflos einhacke, sondern erstmal einen Plan mache.
Ich empfehle dafür die gute alte Papier, Bleistift, Radiergummi Methode.
Auch mag ich es nicht, wenn man gleiche Codesequenzen an mehreren
Stellen wiederholen muß. Zu oft macht man dann Fehler, wenn Änderungen
nötig sind und man Stellen vergißt, zu ändern. An sowas haben vermutlich
die C-Entwickler gedacht und deshalb das Durchrutschen durch case
explizit vorgesehen.
Vom Prinzip her ist das switch/case einfach nur eine spezielle Version
des goto.
Von Pointern eine lokale Arbeitskopie anzulegen, hilft dem Compiler beim
Optimieren sehr.
Die States beim 1-Wire sind schön aufeinander folgend. Es sind nur 3
Rücksprünge nötig, für die Meßzeit und für das nächstes Byte schreiben
oder lesen.
Hallo Peter,
"trickreich" war nicht als Vorwurf, sondern als Kompliment gemeint.
Es hat auch etwas gedauert, bis ich das mit dem Delay verstanden hab ;-)
Wie gesagt: Danke für den von dir veröffentlichen Code!
HansImGlück schrieb:> hi, ich habe es noch etwas weiter "getrieben":>> - fsm mit timer isr und sleep mode
Da hast du vermutlich in der main nur sleep aufgerufen. Oder worin
unterscheidet sie sich sonst von Peters FSM?
> - statt fsm mit timer isr eine fsm mit watchdog delays
Magst du das auch hier veröffentlichen? Das fände ich toll und
hilfreich!
Peter D. schrieb:> Damit nicht andere Interrupts das 1-Wire Timing zerstören, werden die> kurzen Aktionen im Timerinterrupt abgewartet
Gewartet wird bei meiner Realisierung im Sleep Mode und der Timer macht
das Wake-up!
Mathias W. schrieb:> Da hast du vermutlich in der main nur sleep aufgerufen. Oder worin> unterscheidet sie sich sonst von Peters FSM?
Bei der zweiten Variante wurde die Timer Funktion durch den Watchdog
realisiert, also wieder warten im Sleep Mode, aber Wake-up durch den
Watchdog!
Der Unterschied besteht darin, das der Watchdog Timer nochmals viel
weniger Power Consumption im Sleep bedeutet, da die Taktquelle maximal
low-power ist.
... alles zum Preis, dass der WD weniger genaue Zeitintervalle hat, was
hier ohne Bedeutung ist.
Auch realisiere ich oft beliebeige Delays im Sleep Mode mit dem
Watchdog, durch Kombination von mehrenen WD-Zeitintervalen, da dieser ja
nur wenige/feste Zeitintervalle bietet.
Mathias W. schrieb:> Magst du das auch hier veröffentlichen? Das fände ich toll und> hilfreich!
Muss ich mir überlegen ... eigentlich nicht, weil leider das technische
Niveau sowie das Diskussionsniveau hier oft so grausam niedrig ist, dass
die Arbeit dazu nicht lohnenswert erscheint.
Dieses Forum ist bespiellos bzgl. HW/SW/Engineering low Level QA!
Leider of echt wenig addded value, mit Ausnahmen wie Steccy,
Taschenrechner 1284p ...
Schaut euch doch mal an z.B. den Code der WordClock oder vom
Transistortester - ja echt viel Fleiß, aber genau nur das! Ansonsten
eine grausame Quality bzgl. Strukture/Design/Sprachanwendung/...
HansImGlück schrieb:> Mathias W. schrieb:>> Magst du das auch hier veröffentlichen? Das fände ich toll und>> hilfreich!>> Muss ich mir überlegen ... eigentlich nicht, weil leider das technische> Niveau sowie das Diskussionsniveau hier oft so grausam niedrig ist, dass> die Arbeit dazu nicht lohnenswert erscheint.>> Dieses Forum ist bespiellos bzgl. HW/SW/Engineering low Level QA!> Leider of echt wenig addded value, mit Ausnahmen wie Steccy,> Taschenrechner 1284p ...>> Schaut euch doch mal an z.B. den Code der WordClock oder vom> Transistortester - ja echt viel Fleiß, aber genau nur das! Ansonsten> eine grausame Quality bzgl. Strukture/Design/Sprachanwendung/...
Ja das Niveau ist manchmal nicht so dolle hier. Dennoch verstehe ich
Deine Einlassung nicht.
Wenn Du findest das die Qualität des Quellcodes hier zu schlecht ist,
dann wäre es doch an der Zeit mal zu zeigen wie man es besser macht.
Allerdings läßt sich das nur beurteilen wenn Du Deinen Code hier zeigst.
Behaupten das der eigene Code viel besser ist kann jeder. Bis jetzt ist
Deine Aussage nur heiße Luft.
Im übrigen ist es kein guter Stil den Leuten hier den Mund wässrig zu
machen und dann den Code zurückzuhalten. Das läßt eigentlich nur einen
Schluß zu : Dein Code ist nicht so gut wie Du behauptest. Beweise es
ansonsten wäre es besser die Griffel still zu halten.
Bei Deiner Einstellung wäre es besser, wenn Du hier auf jegliche Posts
verzichten würdest, denn im Gegensatz zu Peda hilfst Du hier niemanden.
Zeno schrieb:> Im übrigen ist es kein guter Stil den Leuten hier den Mund wässrig zu> machen und dann den Code zurückzuhalten. Das läßt eigentlich nur einen> Schluß zu : Dein Code ist nicht so gut wie Du behauptest. Beweise es> ansonsten wäre es besser die Griffel still zu halten.
Ich sagte doch schon low Level!
Deine Anwendung von logischen Denkgesetzen ist eher sehr bescheiden und
augenscheinlich unlogisch, weil weder induktiv noch deduktiv begründet
und auch nicht falsifizierend. Dafür aber passend zum vorherrschenden
Klippschulniveau.
Unter Hilfe verstehe ich eher Selbsthilfe und nicht Copy&Paste.
Mit meinen Hinweisen sollte jeder Normalbegabte es selber realiseren
können und die anderen brauchen das auch nicht wirklch, weil sie es dann
offensichtlich auch nicht verstanden haben.
Klippschule unterstütze ich nicht, dazu gibt es hier genug andere
Helden, wie du so einer bist.
Peter D. schrieb:> Anbei der komplette Code.
Sehr schöner Code für die "universelle" Form (universell hier im Sinne
von: für einen möglichst breiten Bereich von Systemtakten geeignet). Das
geht kaum besser umzusetzen.
Aber sowohl für besonders hohe auch auch für besonders geringe
Systemtakte gibt es natürlich deutliches Optimierungspotential. Das ist
halt der Fluch der Universalität...
Was soll's, bei jedem Code muss man Kompromisse machen, je nach
Zielstellung.
Moritz schrieb:> Ohne Worte - Du bist der lebende Beweis für das linke Ende der> Gauß-Kurve beim Thema Intelligenz.
Hi Kleingeist, du offenbarst hier einen Wiederspruch, weil das linke
Ende der Gauß-Kurve ist immer bei Null und mit "Null-Intelligenz" ist
kein biologisches System lebensfähig. Daher ist dort auch kein lebender
Beweis zu erbringen!
Wilhelm M. schrieb:> hört, hört
Kannst du offensichtlich nicht begreifen, da kein Mathe Abiturlevel dir
zu eigen ist. Und wenn doch, dann haste wohl nur am Fenster gesessen!
Infinitialrechnung schon mal berührt?
Bleib lieber bei deinen 4 Grundrechenarten, das reicht für eine
bescheidene Existenz.
HansImGlück schrieb:> Ich sagte doch schon low Level!> Deine Anwendung von logischen Denkgesetzen ist eher sehr bescheiden und> augenscheinlich unlogisch, weil weder induktiv noch deduktiv begründet> und auch nicht falsifizierend. Dafür aber passend zum vorherrschenden> Klippschulniveau.
Ja mir ist schon klar, das Du hier den meisten und insbesondere mir
völlig überlegen bist.
HansImGlück schrieb:> Unter Hilfe verstehe ich eher Selbsthilfe und nicht Copy&Paste.> Mit meinen Hinweisen sollte jeder Normalbegabte es selber realiseren> können und die anderen brauchen das auch nicht wirklch, weil sie es dann> offensichtlich auch nicht verstanden haben.
Nicht mal daran gedacht das es auch Leute gibt die das vielleicht nicht
jeden Tag machen und deshalb nicht so viel Erfahrung haben? Das da viele
dabei sein werden denen Deine Ausführungen nicht weiter helfen, einfach
weil die Erfahrung und das Wissen fehlt? Den Quelltext vor Augen kann
man sich da oftmals viel einfacher rein denken.
Und ja es wir immer Leute geben die dann C&P machen, aber es wird genau
so viele Leute geben, die versuchen werden Deine Gedanken nach zu
vollziehen, diese als Anregung aufnehmen und dann ihren eigenen Weg
gehen.
Ich habe mir für meine Wetterstation auch eine 1-W Implementierung
geschrieben. Die ist zwar bei weitem nicht so durchdacht wie die Lösung
von Peda oder Deine, aber ich habe sie selbst gemacht und verstanden.
Und das ist für mich das Entscheidente, denn das Ganze muß ja auch
gewartet werden.
Ich werde jetzt auch nicht hergehen und Pedas Lösung implementieren auch
nicht per C&P, aber ich habe sie mir mit Interesse angesehen und etwas
dabei gelernt.
Ich niemanden was Schlechtes, aber bei Dir kann ich nur sagen Hochmut
kommt vor dem Fall. Ich weis schon, warum ich solchen Zeitgenossen wie
Du einer zu sein scheinst lieber aus dem Weg gehe.
Zeno schrieb:> Ich niemanden was Schlechtes, aber bei Dir kann ich nur sagen Hochmut> kommt vor dem Fall. Ich weis schon, warum ich solchen Zeitgenossen wie> Du einer zu sein scheinst lieber aus dem Weg gehe.
Korrektur:
Ich wünsche niemanden was Schlechtes, aber bei Dir kann ich nur sagen
Hochmut
kommt vor dem Fall. Ich weis schon, warum ich solchen Zeitgenossen wie
Du einer zu sein scheinst lieber aus dem Weg gehe.
Zeigefinger schrieb:> Kannst du offensichtlich nicht begreifen, da kein Mathe Abiturlevel dir> zu eigen ist. Und wenn doch, dann haste wohl nur am Fenster gesessen!
Kleine Nachfrage dann noch: bitte kläre mich auf!
Wo ist das linke Ende der Gaußkurve?
HansImGlück schrieb:> - fsm mit timer isr und sleep mode> - statt fsm mit timer isr eine fsm mit watchdog delays
Falls Stromsparen notwendig ist, dann macht das die Mainloop, denn nur
die weiß, ob noch andere Tasks auszuführen sind. Eine Device-Lib hat
sich da gefälligst raus zu halten. Sie sollte so wenig Seiteneffekte wie
möglich haben. Und unerwünscht in Sleep zu gehen, ist schon eine massive
Beeinträchtigung.
Ganz abgesehen davon ist Sleep in Interrupts beim AVR ein Kapitel für
sich.
Peter D. schrieb:> Und unerwünscht in Sleep zu gehen, ist schon eine massive> Beeinträchtigung.
... hier spricht ja ein richtiger Experte?! - eher wohl nur ein selbst
ernannter!
Peter D. schrieb:> Statemaschine auch gleich die Wartezeit
Nur die Wartezeiten im Device Treiber werden bei mir jetzt im sleep
erledigt und somit gibt es auch keine Seiteneffekte, die nicht schon
vorher da waren.
Sleep mode in einer ISR ist kein Spezialfall ausser für jene die auf
einen 8051 fahren gelernt haben und aus der Vergangenheit in die Zukunft
reisen!
Da der Experte schon mal in der Leitung ist ..., es wäre nützlich mal
das Statediagramm seiner FSM zu sehen. Damit mal überprüft werden kann,
ob auch das liefert wird was versprochen wird - ein vollständiges
OneWire Protokoll!
HansImGlück schrieb:>> Da der Experte schon mal in der Leitung ist ..., es wäre nützlich mal> das Statediagramm seiner FSM zu sehen. Damit mal überprüft werden kann,> ob auch das liefert wird was versprochen wird - ein vollständiges> OneWire Protokoll!
Warum sollte er das tun?
@Admin: Bitte aufräumen. Danke!
@Freaks, bitte, macht euch doch nicht
wieder gegenseitig runter... ;-O
Der Peter ist doch ein guter Schriftsteller!
Ich hab da mal ne kleine OT-Frage:
Was haltet ihr von IAR Visualstate?
Lohnt es, sich damit zu beschäftigen,
oder kann es weg?
mfg
Lolita schrieb:> @Freaks, bitte, macht euch doch nicht> wieder gegenseitig runter... ;-O>> Der Peter ist doch ein guter Schriftsteller!
Ach Lolita gegen den Peter geht es doch gar nicht. Alle hier im Forum
wissen das der Peter sich alles gut überlegt und guten Code schreibt.
Er ist sich auch nicht zu fein sein Wissen mit der Community hier zu
teilen.
Aber es gibt Leute hier in diesem Thread die meinen sie wären der
Herrgott höchstselbst und benehmen sich auch entsprechend.
Aber wahrscheinlich ist sein Code doch nicht so gut wie Peter hier
Beitrag "Re: DS18B20 mit Interrupt, AVR-GCC" schreibt.
Ich kann es nicht beurteilen da ich weder den tollen Code kenne noch der
absolute AVR Programmierguru bin. Ich mache das nur für den
Hausgebrauch, sicher nicht optimal aber für mich völlig ausreichend, da
für meine Zwecke am Ende die zu erledigende Funktionalität das Ziel ist.
Das Ganze muß auch nicht sonderlich performant sein, solange die
gewünschte Funktion erfüllt wird.
@zeno,
Wenn Du aber kostenlos ein schelles und gutes Protokoll
bekommst, warum willst du dann ein langsames einsetzen?
So bleibt doch mehr Zeit für eigene Ergüsse übrig?
Der Speicher ist doch bestimmt nur ein Teil deine Projektes
oder die Hauptsache?
mfg
Naja, ich beantworte die Fragen mir mal selber:
Schön wäre es, wenn wir Liebenden (Amateure) uns hier
Librarys schaffen könnten, die von den Hasen begutachtet,
einen MC_Net Standard auch außerhalb des Boardes schaffen könnten.
Ich hätte sogar nen Vorschlag für die Licence:
Jeder der das Zeug dann einsetzt, hat einen constexpr string
im Kompilat zu plazieren, etwa:
www.mc.net absolut easy!
oder auch
www.mc.net nicht mit mir! ;-P
mfg
Lolita schrieb:> Wenn Du aber kostenlos ein schelles und gutes Protokoll> bekommst, warum willst du dann ein langsames einsetzen?>> So bleibt doch mehr Zeit für eigene Ergüsse übrig?> Der Speicher ist doch bestimmt nur ein Teil deine Projektes> oder die Hauptsache?
Ich habe mich seinerzeit als ich das gemacht habe halt auch umgeschaut
wie man den 1-Wire Bus mit einem µC anspricht. Ich bin dann auch fündig
geworden und habe die Lösung an mein Projekt angepasst - ich verwende
einen MSP430. Diese Lösung arbeitet halt ohne Interrupts und macht die
Timings mit einer Delayfunktion. Ja das ist sich nicht elegant und auch
nicht sonderlich schnell, aber für meine Wetterstation ist das völlig
zweitrangig, weil da die Abfrageintervalle in aller Regel größer als 30s
sind - Wetter ändert sich halt nicht so schnell. Besonders
energieeffizient muß es auch nicht sein, da die Wetterstation mit
Netzteil versorgt wird.
Mir kam es da wirklich nur auf eine funktionierende Lösung an die ich
auch verstehe. Interupts sind mir immer noch ein wenig suspekt - ich
gewöhne mich halt sehr langsam daran. Für mich ist das ganze eben nur
Hobby und mit µC hantiere ich auch erst seit vielleicht 8 Jahren. Bin
vorher eben ganz gut mehr als 40Jahre ohne µC ausgekommen.
Zum 2.Teil Deines Posts. Na klar würde dann mehr Zeit für eigene Ergüsse
bleiben, aber man lernt eben mehr, wenn man ein Problem selber löst,
auch wenn die Lösung nicht optimal ist. Beim nächsten Mal macht man es
eben besser. Es mach auch mehr Spaß, wenn man selbst eine Lösung findet
und für's Ego ist es auch gut.
Lolita schrieb:> Jeder der das Zeug dann einsetzt, hat einen constexpr string> im Kompilat zu plazieren, etwa:
Das mach ich generell so. In meinem Quelltexten ist immer ein Verweis
auf die Quelle, wenn ich fremden Code benutzt habe. In dem Programm
welches ich für meine Firma geschrieben habe, sind z.B die Quellen aller
Fremdkomponenten/-code in einer Aboutbox aufgeführt.
Peter D. schrieb:> AVR-GCC portiert und noch etwas aufgehübscht.
... das geht noch viel optimaler bzgl. Speed/Size, wenn man die AVR
Architekture besser kennt und für die FSM states(or partly) diese auf
die GPR Register linkt!
meine Geheimwaffe!
GPR?, liegen im IO Memory Addressbereich und sind Bit addressierbar
toogle/clear/set/read, sprich kein read-modify-write nötig und HW
initialisiert! Es gibt so GPR0 bis 3/4 und mal genannt GPIORx oder GPRx.
Wer von euch Helden kennt diese UND kann sie auch sinnvoll benutzen für
z.B. Flags/States/Schleifenvariable?
Wie verwenden? z.B. so, status= bit flag
typedef struct {
uint8_t status1 :1, status2 :1, ... ;
} status_t;
#define STATUS1 ((status_t*) &GPIOR0)->status1
#define STATUS2 ((status_t*) &GPIOR0)->status2
HansImGlück schrieb:> Peter D. schrieb:>> AVR-GCC portiert und noch etwas aufgehübscht.>> ... das geht noch viel optimaler bzgl. Speed/Size, wenn man die AVR> Architekture besser kennt und für die FSM states(or partly) diese auf> die GPR Register linkt!>> meine Geheimwaffe!> GPR?, liegen im IO Memory Addressbereich und sind Bit addressierbar> toogle/clear/set/read, sprich kein read-modify-write nötig und HW> initialisiert! Es gibt so GPR0 bis 3/4 und mal genannt GPIORx oder GPRx.>> Wer von euch Helden kennt diese UND kann sie auch> sinnvoll benutzen für z.B. Flags/States/Schleifenvariablen
Schön daß du das entdeckt hast. Damit bist du nun AVR-Experte. Mit gutem
Algorithmus hat das so viel zu tun wie der Tip von einigen, nur ASM ist
gut.
BTW, Schleifenvariablen in GPRx ist ziemlicher Müll, den man aber nur
versteht, wenn man schon mal eine Schleife im Assemblerlisting gesehen
hat und das AVR8 Programmiermodell versteht.
HansImGlück schrieb:> meine Geheimwaffe!
Daß ich nicht lache.
Zu meinem Programmierstil gehört eben, daß ich Programme möglichst
unabhängig vom konkreten Target halten will.
Wenn der Compiler bool durch HW-Bits ersetzen würde, dann hätte ich
nichts dagegen. Aber selber werde ich nen Teufel tun und den Code
zusätzlich unleserlich gestalten. Aus dem gleichen Grund benutze ich
auch nicht die Togglefunktion mancher AVR-Targets über die
Inputregister.
Die Einsparungen durch solchen Hassle sind nicht der Rede wert.
Peter D. schrieb:> Zu meinem Programmierstil gehört eben, daß ich Programme möglichst> unabhängig vom konkreten Target halten will.
Was natürlich zur Folge hat, dass sie für ein konkretes Target oft
suboptimal sind. Solange kein Problem, wie die Resourcen trotzdem für
die Aufgabe genügen.
Aber was, wenn nicht?
> Wenn der Compiler bool durch HW-Bits ersetzen würde, dann hätte ich> nichts dagegen. Aber selber werde ich nen Teufel tun und den Code> zusätzlich unleserlich gestalten. Aus dem gleichen Grund benutze ich> auch nicht die Togglefunktion mancher AVR-Targets über die> Inputregister.
Dann benutzt du also nach der gleichen Logik auch kein Eventsystem, kein
ADC, kein Timer2, keine I2C-/SPI-Hardware (...Aufzählung beliebig
erweiterbar)?
All diese netten Sachen gibt's nämlich halt nicht auf jedem AVR8.
Deswegen sollte man sie deiner Meinung nach überhaupt nie verwenden?
Also mir scheint: das kann nur falsch sein...
> Die Einsparungen durch solchen Hassle sind nicht der Rede wert.
Das kommt ja wohl sehr darauf an...
Peter D. schrieb:> Die Einsparungen durch solchen Hassle sind nicht der Rede wert.
Du Dümmerchen, die Einsparung ist signifikant, probiert es mal aus.
Peter D. schrieb:> Aus dem gleichen Grund benutze ich> auch nicht die Togglefunktion mancher AVR-Targets
Ich schon, die Togglefunktion hat quasi jeder AVR und auch die GPR's!
Du schreibst doch hier, dass du für AVR den Code portiert hast, daher
sehr inkonsequent dein Statement, - wohl doch eher ein Kleingeist?!
BTW, viele neue AVR unterstützen OneWire via HW UART mode, aber das ist
auch nichts für deinen Programmierstile, so wenig wie reduction of power
consumption, wohl einfach zu alt und unflexibel der Herr.
Peter D. schrieb:> Aber selber werde ich nen Teufel tun und den Code> zusätzlich unleserlich gestalten.
Echt dumm dein Gelaber, die GPR's lassen sich via union genau so
ansprechen, wie jedes andere SFR angesprochen wird und wie
Atmel/Microchip es in ihren header files definieren.
Sind diese auch für dich zu unleserlich, dann liegt es vielleicht doch
nur an den eigenen begrenzten Fähigkeiten.
Ich würde erst mal prüfen/verifizieren und dann mir eine Meinung bilden,
so macht es jeder durchschnittliche Ingenieur.
c-hater schrieb:> All diese netten Sachen gibt's nämlich halt nicht auf jedem AVR8.
AVR8 was ist das, muss ich das noch kennen?
... ch bekomme von Microchip jeden Monat backfrisch 36 AVR/ARM/PIC's
freihaus geliefert und sammle die Teile bald wie Briefmarken!
... und lese auch intensive die Doku's, und mag sehr das Eventsystem,
und die Cortex M23 und PIC32 Serie,
... und "liebe" Micropython, das wäre dann auch für den c-hater
vielleicht was, oder?!
... lässt sich auch mit c/c++ verheiraten!
HansImGlück schrieb:> Wer von euch Helden kennt diese UND kann sie auch sinnvoll benutzen für> z.B. Flags/States/Schleifenvariable?HansImGlück schrieb:> Du Dümmerchen, die Einsparung ist signifikant, probiert es mal aus.HansImGlück schrieb:> Sind diese auch für dich zu unleserlich, dann liegt es vielleicht doch> nur an den eigenen begrenzten Fähigkeiten.HansImGlück schrieb:> AVR8 was ist das, muss ich das noch kennen?> ... ch bekomme von Microchip jeden Monat backfrisch 36 AVR/ARM/PIC's> freihaus geliefert und sammle die Teile bald wie Briefmarken!> ... und lese auch intensive die Doku's, und mag sehr das Eventsystem,> und die Cortex M23 und PIC32 Serie,> ... und "liebe" Micropython, das wäre dann auch für den c-hater> vielleicht was, oder?!> ... lässt sich auch mit c/c++ verheiraten!
Man trägst Du die Nase hoch! Du solltest sie mal wieder runter nehmen,
damit das Regenwasser raus laufen kann und Du wieder Luft durch die Nase
bekommst, denn das ist viel gesünder und beugt Schnappatmung vor.
Leute, der Typ, der umständlich einen Goldklumpem im Brunnen versenkt
hat, hat nur etwas Lagerkoller, weil er aktuell keine Börger essen gehen
darf. Da stichelt man halt mal in jede Richtung und hofft auf
Unterhaltung. Einfach stehen lassen.
Zeno schrieb:> Ist sehr wahrscheinlich die beste Lösung.
Interessant, euch interessiert nicht der Inhalt sondern nur die
Verpackung, da hatte HansImGlück schon recht, wenn er das miese Niveau
hier anprangert!
Der Typ wirft mal wenigstens ein paar Argumente in den Ring, daran könnt
ihr euch doch mal versuchen und abarbeiten!
Ach neh doch nicht, richtig arbeiten will oder kann ja hier keiner mehr,
lieber nur rumhängen und copy&past?!
HansImGlück schrieb:> Du Dümmerchen, die Einsparung ist signifikant, probiert es mal aus.
Nö, signifikant ist da nichts. Der User würde es nicht merken und
nichtmal messen können, da die zeitrelevanten Tasks davon nicht
betroffen wären.
Warum also sollte ich Programmierzeit in Mikrooptimierung verschwenden,
wenn es nicht das geringste bringt?
Meine AVR-Anwendungen haben reichlich Reserven und laufen auch nicht bei
der maximalen F_CPU.
Hallo zusammen,
da ich mehrere DS18B20 gleichzeitig auslesen wollte, habe ich Peters
Code etwas umgebaut und erweitert. Die Zugriffe auf die IOs sind
extrahiert, was auch die Portierung auf andere MCUs erleichtern dürfte
(in meinem Fall auf einen Tiny1616), auch lassen sich die Pins des
verwendeten Ports über ONEWIRE_PINMASK einschränken.
Die Methoden zum Auslesen der DS18B20 ist in eine extra Datei gewandert
und mit einer kleinen Statemachine ist das Auslesen der Sensoren etwas
bequemer.
ds18b20_start() startet eine conversion, ds18b20_tick() kann nach
belieben aufgerufen werden - diese gibt, wie ds18b20_isdone() zurück, ob
eine conversion abgeschlossen ist. Mit ds18b20_get_temp_fixe() kann die
Temperatur des angegebenen Kanals als fixed-point zurückgegeben werden.
Ich verwende den Code in einem Modbus-Server, funktioniert auf dem
Basteltisch bisher ausgezeichnet.
@peda: welche Lizenz hat dein Code eigentlich?
Chris schrieb:> Die Zugriffe auf die IOs
Hmmm...
OneWire war eigentlich als Bussystem gedacht, mit dem primären
Entwicklungsziel, möglichst wenige Leitungen zu benötigen.
Dein Lösung konterkarriert das doch irgendwie ein wenig, oder?
Ob S. schrieb:> Dein Lösung konterkarriert das doch irgendwie ein wenig, oder?
Das stimmt natürlich, es gibt aber auch Gründe es auf diese Weise zu
machen:
Die angeschlossenen Sensoren sind einfacher zuordenbar, sprich: man muss
sich nicht um die Search & Match kümmern und sie können wirklich
zeitgleich ausgelesen werden (für wen das wichtig ist).
Chris schrieb:> Die angeschlossenen Sensoren sind einfacher zuordenbar, sprich: man muss> sich nicht um die Search & Match kümmern
Nunja. Klar.
> und sie können wirklich> zeitgleich ausgelesen werden (für wen das wichtig ist).
Ich kann mir nur eine Sache vorstellen, bei der es wichtig wäre, dass
Temperatur sensoren gleichzeitig ausgelesen werden. Das ist, wenn auch
der abfragende Controller auf Batterie läuft, und deshalb nur möglichst
kurze Zeit aktiv sein soll.
Aber klar: Dieses Szenario kann durchaus mal vorkommen. Das sehe ich
ein.
Ich habe die Erfahrung gemacht, man sollte die Sensoren nur alle 10s
auslesen. Ansonsten kann die Eigenerwärmung einen deutlichen Meßfehler
bewirken, besonders an wenig bewegten Gasen.
Thread beobachten
Seitenaufteilung abschalten