um einen digitalen Temperatursensor DS18B20 mit einer MCUs der TinyAVR Serie 1/2 in meinem Fall der ATtiny 1614 (habe aber auch Serie 2 ATtiny 3216 erfolglos getestet) auszulesen verwende ich die Library OneWire (PaulStoffregen) in der Version 2.3.8 wie sie in vielen Beispielen verwendet wird. Dies funktioniert perfekt mit einem Arduino UNO R3, somit bin ich sicher das mein Hardwareaufbau (Speisung mit 4.7k Pullup Widerstand, sprich nicht parasitär) sowie die Programmierung, welche ich schon auf das absolute Minimum reduziert habe, in Ordnung sein muss.
Die ATtinys programmiere ich mit Arduino IDE 2.3.6 unter Verwendung von megaTinyCore (SpenceKonde) in der Version 2.6.10. Die Settings (Fuses) sind
dabei alle in Default Einstellung belassen, hatte aber auch hier in meiner
Verzweiflung einiges "versucht", u.a. den gleichen Takt von 16Mhz wie beim UNO. Soweit mir bekannt ist OneWire nicht an einen bestimmten Pin gebunden, habe aber auch andere probiert.
Es ist auch egal ob zum Auslesen zusätzlich die DallasTemperature Library
verwendet wird oder aber direkt per Register Adressierung zugegriffen wird.
Nach Suche im Internet gibt es anscheinend Kompatibilitätsprobleme mit der
OneWire Library. Daher habe ich auch andere Optionen getestet, u.a. die
OneWireNg Library (PiotrStolarz Version 0.14.0). Wie bereits erwähnt, es
funktioniert immer auf dem Klassiker UNO (ATmega328p).
intGetTemp()// Read Temperatur Value (integer version x10 !)
29
{
30
ds.reset();// Reset OneWire bus. (needed before communicating)
31
ds.skip();// Select OneWire device by skip (all, works only with 1 sensor)
32
ds.write(0x44,0);// write command to start conversion, with no parasite power(0)
33
delay(800);// wait before next command (12bit res takes 750ms con. time)
34
ds.reset();// Reset again
35
ds.skip();// Select OneWire device again
36
ds.write(0xBE);// write command to read Scratchpad
37
38
bytedata[9];// byte array to hold read data
39
ds.read_bytes(data,9);// Read 9 bytes of data from sensor
40
41
if(!(OneWire::crc8(data,8)==data[8]))return999;// Data CRC is invalid return 99.9 °C
42
int16_traw=(data[1]<<8)|data[0];// Convert the data to integer temperature value
43
return(raw*10)/16;// return as integer value xx.x (%10 for decimal place)
44
}
Es müsste doch mittlerweile jemand eine funktionierde OneWire Library für die neuen ATtinys entwickelt haben, die Serie (1/2) ist ja schon einige Jahre verfügbar und anscheinend beliebt. Bevor ich nun analoge Temperatursensoren (LM35 DZ) einsetzte würde ich gern in Erfahrung bringen ob es vielleicht nicht doch möglich ist OneWire auf der TinyAVR Serie 1/2 zu realisieren.
Es müsste doch mittlerweile jemand eine funktionierde OneWire Library
für die neuen ATtinys entwickelt haben, die Serie (1/2) ist ja schon
einige Jahre verfügbar und anscheinend beliebt. Bevor ich nun analoge
Temperatursensoren (LM35 DZ) einsetzte würde ich gern in Erfahrung
bringen ob es vielleicht nicht doch möglich ist OneWire auf der TinyAVR
Serie 1/2 zu realisieren.
Solange Du einen freien UART hast, ist das schwierige, nämlich das Erzeugen des Bittimings, damir erledigt. Der Rest ist nur noch Runterprogrammieren des Datenblatts.
nimm eine ältere OneWire Version oder lies hier was zu tun ist.
https://github.com/PaulStoffregen/OneWire/pull/94
Das Thema ist schon länger bekannt, es gibt mehrere Anfragen zum Thema und es betrifft nicht nur die ATtiny Serie. Leider verweigert Paul stur ein Update.
Über das Thema mit dem USART in One-Wire Mode, bzw. eine eigene Funktion dafür zu Entwerfen bin ich auch schon gestopltert aber meine Kenntnisse sind noch nicht so tief das ich das jetzt schon hinbekomme.
Auch war vermutlich zu voreilig, bzw. habe nicht mit soetwas gerechnet, denn die Platine für mein Projekt ist schon fertig aus China gefliefert und somit keine seriellen Pins mehr frei (da hängt bereits das LCD per I2C dran).
Aber ich teste auf jeden Fall mal eine ältere Version der OneWire Lib und versuche ansonsten eine sogenannte BitBang Eigenversion sofern ich dem Beispiel Code durchblicke.
nimm eine ältere OneWire Version oder lies hier was zu tun ist.
https://github.com/PaulStoffregen/OneWire/pull/94
Das Thema ist schon länger bekannt, es gibt mehrere Anfragen zum Thema
und es betrifft nicht nur die ATtiny Serie. Leider verweigert Paul stur
ein Update.
@Juergen H.
Wenn ich die Kommentare bei github richtig interpretiere, hat Spence Konde deshalb ein Fork von Pauls OneWire Library angelegt, und dort die Unterstützung für die neueren Tinys implementiert. Ob das wie gewünscht funktioniert weiß ich nicht, aber du kannst die Lib ja mal testen:
wow ich bin neu hier aber das ich selbst als Newbie chon so viel Unterstützung erhalte finde ich echt super, Dankschön an alle!
Dank den Anreizen habe ich gerade begonnen die alten Versionen zu installieren und hatte nun einen durchschlagenden Erfolg. Zwar nicht mit einer älteren Version (ich kann in der Arduino IDE wählen zwischen 2.30 bis 2.38), diese gingen alle nicht.
ABER: Mir ist aufgefallen das die OneWireNg Library (in der Version OneWireNg-0.14.0) welche ich bereits getestet hatte bei mir so nie funktionieren konnte da der Header den exakt gleichen Namen hat. Erst nachdem die OneWire von Spence komplett deinstalliert war hat der Compiler auch die OneWireNg herangezogen und siehe da, es funktioniert.
Zur Ergänzung will ich noch hinzufügen das die Modifizierung der Spence OneWire Library (wie in "Add support for new ATTiny MCUs #98") beschrieben tatsächlich funktioniert.
Hatte mir die Mühe gemacht auch diesen Vorschlag umzusetzen da in einem Kommentar irgendwo erwähnt wurde das diese besser ist als die OneWireNg (zumindest sehe ich einen großen Unterschied beim Speicherbedarf was ja nicht unerheblich ist bei den Tinys).
die Serie (1/2) ist ja schon
einige Jahre verfügbar und anscheinend beliebt.
Das Problem ist nur, warum sollte man ohne Not ständig immer dem neuesten nachjagen, wenn die bewährten AVRs doch voll und ganz ihre Aufgaben erfüllen.
So epochal sind die Erweiterungen ja nicht. Allerdings wurde vieles komplett umgestellt (Timer usw.), so daß man einen ganzen Rattenschwanz an Umbauten seiner Libs benötigt. Und Zeit ist ja bekanntlich auch Geld.
Auch hat sich Microchip keinen Gefallen damit getan, ständig neue Familien mit minimalsten Änderungen (tiny 0, 1, 2 usw.) rauszubringen. Das hat die Nutzer zutiefst verunsichert, worauf sie nun setzen sollen. Daher bleiben sie erstmal beim Bewährten.
Und hast Du mal überlegt, wie teuer im industriellen Umfeld die Einrichtung eines neue Bauteils in der Lagerverwaltung ist. Sowas macht keine Firma mal eben nur so zum Spaß.
Was ist, wenn an anderer Stelle die Interrupts disabled werden müssen? Das zerreißt je nach Dauer vom disable das Timing und irgendwann funktioniert es nicht mehr. Wie geht ihr damit um? HW-1Wire verwenden?
Da wird die Lösung mit UART vermutlich besser sein wenn man denn einen übrig hat. Hab mir das nicht angesehen.
Was ist, wenn an anderer Stelle die Interrupts disabled werden müssen?
Steht im Text. Der 1W-Timerinterupt darf nur bis ~60µs gesperrt sein, das sind bei 16MHz immerhin ~1000 CPU-Takte für andere Interrupts. 50..200 Zyklen für Interrupts ist in der Regel kein Hexenwerk. Und atomare Zugriffe brauchen selten >10 Zyklen.
Oder man macht super extrem lange Sperren in den Meßpausen. Zu schnelle Wandlungen führen ja eh zu Fehlern durch die Eigenerwärmung des Sensors.
Die Meßpause muß man ja nicht den 1W-Interrupt mitmachen lassen.
Der 1W-Timerinterupt darf nur bis ~60µs gesperrt sein, das sind bei
16MHz immerhin ~1000 CPU-Takte für andere Interrupts. 50..200 Zyklen für
Interrupts ist in der Regel kein Hexenwerk.
OK, das wird für viele Fälle dann funktionieren.
Danke für die Aufklärung
Die Meßpause muß man ja nicht den 1W-Interrupt mitmachen lassen.
Nein, wahrlich nicht ;)
Wäre aber auch kein Beinbruch. Man könnte einfach onwi.delay abtesten, ob die Wartezeit noch läuft. Selbst bei superlangen Interruptsperren wartet man dann eben x * 100ms länger.
So epochal sind die Erweiterungen ja nicht. Allerdings wurde vieles
komplett umgestellt (Timer usw.), so daß man einen ganzen Rattenschwanz
an Umbauten seiner Libs benötigt. Und Zeit ist ja bekanntlich auch Geld.
Hallo Peter,
unter dem Aspekt gebe ich dir natürlich recht und eigentlich bin ich auch eher "Old-School" aber mich haben die neuen Tinys letzendlich doch begeistet da sie für meine Anforderungen einige Vorteile mitbringen, dafür hatte ich sogar meine Werkstatt um SMD Löttechnik erweitert.
Epochal sind die Erweiterungen nicht aber ich finde die UPDI Schnittstelle welche nur einen CH340n mit minimalster Beschaltung erfordert was den Entwurf eigener Platinen recht einfach gestaltet und das auch kein exterer Ozzi benötigt wird schon lohnenswert umzusteigen. Ein ATtiny 3216/26 bietet gegenüber dem klassischen ATmega328P (mit dem ich immer noch arbeite) den gleichen Speicher bei höherem Takt und ist zudem noch deutlich günstig.
In wie weit diese Teile im industriellen Umfeld genutzt werden hab ich keinen Schimmer, hab so das Gefühl das die sind eher für Amatueranwendungen und uns Hobbyisten sind.
hab so das Gefühl das die sind eher für
Amatueranwendungen und uns Hobbyisten sind.
Wenn das mal kein Irrtum ist. Glaubst du ernsthaft, daß Micochip den nicht ganz unwesentlichen Entwicklungsaufwand für DIESE Zielgruppe betreibt? Keine Sekunde! Die sind nebensächlicher als nebensächlich!
Hier gibt's auch noch eine Onewire/DS18xx Bibliothek.
ich kann nicht nachvollziehen und ich verstehe es auch nicht, warum Peter seinen Kriegspfad gegen die neuen Controller so aggressiv fortführt. Im ARM Umfeld kommen "jede Woche" neue Controller raus mit minimalsten Unterschieden. Läuft auch.
ich kann nicht nachvollziehen und ich verstehe es auch nicht, warum
Peter seinen Kriegspfad gegen die neuen Controller so aggressiv
fortführt.
Weil er faul geworden ist. Er will am liebsten immer nur seine liebgewordenen alten "libs" (gemeint sind natürlich: bewährte Codefragmente) immer weiter verwenden können.
Ich habe da durchaus ein gewisses Verständnis für, aber er übertreibt das wohl doch etwas.
Die neuen AVR8 haben durchaus etliche technische Vorteile gegenüber dem Classic-Kram aber, und insofern hat er Recht: auch einige Nachteile. Das betrifft weniger die Tinys, da überwiegen die Vorteile meist massiv. Aber bei den Megas gibt es schon einige Features, denen man nachweint.
Aber: Die neuen sind heute schon deutlich günstiger und diese Preisschere wird sich in Zukunft noch weiter öffnen. Das ist die klassische Microchip-Politik. Die kündigen nur recht selten was stumpf ab, vorher treiben sie lieber noch über Jahre die Preise in die Höhe.
ich verstehe es auch nicht, warum
Peter seinen Kriegspfad gegen die neuen Controller so aggressiv
fortführt.
Ich verstehe auch nicht, warum mit gleich ein Kriegspfad unterstellt wird. Man wird doch wohl seine Meinung sagen dürfen, ohne sofort angegriffen zu werden. Diese Aggressivität im Forum ist wirklich unerträglich geworden.
Es ist nunmal so, daß in Firmen neue Bauteile begründet werden müssen, weil damit Kosten verbunden sind (Buchung, Lagerhaltung usw.).
In den Anfängen mit µCs konnte ich relativ frei Bauteile selber aussuchen. Die Firma ist aber seitdem erheblich gewachsen, d.h. die Edelbastlerzeiten sind schon lange vorbei.
Es gibt zusätzlich den Effekt, wenn man für eine Baugruppe neue Bauteile verwendet, d.h. ein neues Layout erstellt, daß dann der Fertiger diese auch neu kalkuliert und damit der Preis erheblich ansteigt.
Bei einer Bestandsbaugruppe fallen dagegen Preisanpassungen deutlich moderater aus.
Es gibt zusätzlich den Effekt, wenn man für eine Baugruppe neue Bauteile
verwendet, d.h. ein neues Layout erstellt, daß dann der Fertiger diese
auch neu kalkuliert und damit der Preis erheblich ansteigt.
Nö. Es fallen einmalige Einrichtkosten an. Der Preis der Baugruppe bleibt gleich, wenn die Bauteile nicht teurer werden.
Um die geht es doch gar nicht. Alle Einmalkosten sind Pillepalle.
Wenn ein Bäcker Streuselschnecken verkauft, will er möglichst lange den Preis beibehalten, weil die Kunden ihn ja schon kennen. Wenn er nun Zimtschnecken neu ins Programm nimmt, kann er den Preis frei kalkulieren.
Der Preis der Baugruppe
bleibt gleich, wenn die Bauteile nicht teurer werden.
Träum weiter. Der Fertiger hat ständig steigende Kosten (Strom, Miete, Löhne), die er weiterreichen muß.
Bisher ist keine Baugruppe bei einer Neukalkulation günstiger geworden, obwohl ich die Fertigung vereinfacht habe (weniger THT, mehr SMD, weniger Montageaufwand, günstigere Bauteile usw.).
ich verstehe es auch nicht, warum
Peter seinen Kriegspfad gegen die neuen Controller so aggressiv
fortführt.
Ich verstehe auch nicht, warum mit gleich ein Kriegspfad unterstellt
wird. Man wird doch wohl seine Meinung sagen dürfen, ohne sofort
angegriffen zu werden. Diese Aggressivität im Forum ist wirklich
unerträglich geworden.
Hallo Peter,
ich fange mit dir keinen Streit an. Ich möchte weder unerträglich sein, noch möchte ich dich ärgern, auch nicht verärgern oder sonstwas in der Richtung. Ich habe nur eine Auffälligkeit niedergeschrieben, die mir schon länger ins Auge sticht. Diese Auffälligkeit könnte mit deinem Alter zu tun haben. :-) :-) :-)
