Hallo, im Betreff ist eigentlich schon alles gesagt. Ich möchte einen PT1000 mit möglichst hoher Auflösung ratiometrisch messen, Geschwindigkeit spielt praktisch keine Rolle. Für Arduino gibt es eine umfangreiche Library, die auf der Arduino-SPI-Lib aufbaut - eine Tortur, sie beide nach gcc zu portieren. Hat jemand was für mich? Danke!
Michael schrieb: > Für Arduino gibt es eine umfangreiche Library, die auf der > Arduino-SPI-Lib aufbaut - eine Tortur, sie beide nach gcc zu portieren. > > Hat jemand was für mich? Ja, ein Tip: Lern' Programmieren. Es ist überhaupt nicht nötig, die Arduino-SPI-Lib zu portieren. Du brauchst nur in der Lib, um die es eigentlich geht, alle SPI-relevanten Sachen auf dein eigenes Zeug anpassen. Oder was immer du als Low-Level-SPI-API benutzt, wenn die geistige Grütze nicht genügt hat, was komplett eigenes zu produzieren. Ja, sowas nennt man Programmieren. Im Gegensatz zu Code zusammenklauben. Das können selbst Affen und KIs. Denen ist es halt nicht gegeben, zu verstehen, was da passiert. Du willst doch aber hoffentlich besser sein als ein Affe oder eine KI?
Michael schrieb: > Für Arduino gibt es eine umfangreiche Library, die auf der > Arduino-SPI-Lib aufbaut - eine Tortur, sie beide nach gcc zu portieren. Arduino nutzt den GCC. Was genau passt dir daran nicht? > Ich möchte einen PT1000 mit möglichst hoher Auflösung ratiometrisch > messen Was hast du von so einer Auflösung? Wie willst du dein Pt1000-Exemplar so genau kalibrieren? Mit der Wahl des ADS1220 hast du dich doch bereits festgelegt, wenn du noch den Temperaturbereich nennst, in dem du messen können möchtest. Die Realisierung einer "möglichst hohen Auflösung" hat nichts mit der Programmiersprache und schon gar nicht mit der Existenz irgendwelcher Bibliotheken zu tun.
:
Bearbeitet durch User
Ich möchte nichts entwickeln, sondern lediglich mehrere bereits vorhandenen ADS1220-Platinen anwenden. Abgesehen davon - falls mir das nötig erscheinen sollte, hätte ich gute Kontakte in ein Kalibrierlabor.
„ADS1220 an ATmega328 ohne Arduino“ Wenn man nur ein kleines Wörtchen austauscht, ist das Problem keins mehr. Oliver
Michael schrieb: > Für Arduino gibt es eine umfangreiche Library, die auf der > Arduino-SPI-Lib aufbaut - eine Tortur, sie beide nach gcc zu portieren. Die, die ich gefunden habe, bei der sind 3 Methoden anzupassen. In der Lib ist das wirklich prächtig für dich vorbereitet. Wenn das schon eine Tortur ist....?
:
Bearbeitet durch User
wie üblich in diesem Forum, einfach helfen ist nicht..alles Einsteins und Oberlehrer hier... Hast du mal im Forum von avr freaks gefragt? https://www.avrfreaks.net/s/ oder Roboternetz de= Eigentlich wirst du in jedem anderen Forum die gewünschte Hilfe ohne Beleidigungen erhalten hast du es mal mit ChatGPT versucht? Vielleicht klappt das dafür ganz gut, kann natürlich passieren, dass du es dann doch korrigieren musst, dass kann als Anfänger natürlich schwieriger werden, aber diesen Codeschnipsel kannst du dann ja bei avr freaks einstellen, da wird dir dann sicher geholfen
:
Bearbeitet durch User
Mairian schrieb: > hast du es mal mit ChatGPT versucht? > … aber diesen Codeschnipsel kannst du dann ja bei avr > freaks einstellen, da wird dir dann sicher geholfen Ja ja, miserablen Code von fragwürdigen Systemen zusammen prutschen lassen und dann andere bitten für dich den Dreck zu korrigieren. Willkommen in der schönen neuen Welt!
ich sehe bislang nicht, das seine Anfrage hier besser gewesen wäre als ChatGpt...denkt mal drüber nach
:
Bearbeitet durch User
Moin, Was mich betrifft, würde ich lieber auf die Einzelheiten diskret aufgebauter Messelektronik und auf eine Fertiglösung wie z.B. der MAXIM31865 hinweisen. Hier das Datenblatt: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31865.pdf Dafür sprechen unter anderen: - Fertig aufgebaute erschwingliche Module erhältlich - Für viele Anwendungen ausreichende Genauigkeit und Auflösung. - Fertige Bibliotheken für Testzwecke (Referenz Design) (auch als Ansatz für eigene Implementationen Ich weiß von was ich spreche, weil ich jahrelang eigene Schaltungen mit diversen 24-bit Wandlern im Industrieumfeld entwickelt habe. Wenn man selber etwas bauen will, empfiehlt sich ein ADC mit externen Differenzial Referenzeingang. Dann kann der Vergleichswiderstand in Serie mit dem PT-Fühler geschaltet werden und eine einfache Stromquelle genügt. (Konstantstromquelle ist nicht notwendig). Gewisse Massnahmen sind natürlich notwendig, um den Spannungsabfall an den stromführenden Erregungsleitungen erfassen zu können. Mit den richtigen (Multi-Channel) ADCs bleibt die Grundschaltung aber relativ einfach. Auch muß man sich Gedanken zum ESD- und generellen Überlastungsschutz machen. Für viele Anwendungen lohnen sich aber die einschlägigen Speziallösungen der üblichen Platzhirsch-Firmen, weil Vieles gut durchdacht mit-integriert ist. Auch haben industrielle Konverter Fehlererkennung und Flexibilität bezüglich der Anschlusstopologie (3/4W) Duck und weg, Gerhard
:
Bearbeitet durch User
Mairian schrieb: > wie üblich in diesem Forum, einfach helfen ist nicht..alles Einsteins > und Oberlehrer hier... Willkommen, hier bist auch DU genau richtig. Gerhard O. schrieb: > Ich weiß von was ich spreche, weil ich jahrelang eigene Schaltungen mit > diversen 24-bit Wandlern im Industrieumfeld entwickelt habe. Michael schrieb: > Ich möchte nichts entwickeln, sondern lediglich mehrere bereits > vorhandenen ADS1220-Platinen anwenden. ... mit möglichst hoher Auflösung - was immer damit gemeint sein mag. Mit Deinen Anforderungen gehörst Du zur Zielgruppe von Arduino. Dafür gibt es bestimmt eine fertige LIB.
Beitrag #7940302 wurde vom Autor gelöscht.
Gerhard O. schrieb: > Dafür sprechen unter anderen: > ... > Für viele Anwendungen ausreichende Genauigkeit und Auflösung. Damit wird man die Anforderungen des TO wohl kaum abdecken können. Er fragt explizit nach Michael schrieb: > ... mit möglichst hoher Auflösung Bleeding Edge of Technology hat mit Standardlösungen nichts zu tun. Eventuell muss der TO hier Abstriche machen, wenn er schon bei der SPI-Kommunikation mit einem ADS1220 nicht auf eigenen Füßen stehen kann.
Es gibt unzählige Libraries für den ADS1220, einfach mal nach "ADS1220 github" suchen. Da kann sich der TO die passende raussuchen, er schreibt ja nicht welchen Mikrocontroller er verwendet. Eine ist z.B. diese hier: https://github.com/MahdaSystem/ADS1220 Die setzt keinen bestimmten Mikrocontroller voraus und das Readme erkärt in ein paar Zeilen wie man die Library verwendet.
Dieter S. schrieb: > ... er schreibt ja nicht welchen Mikrocontroller er verwendet. Doch schon - bereits in der Titelzeile
Michael schrieb: > Ich möchte nichts entwickeln, sondern lediglich mehrere bereits > vorhandenen ADS1220-Platinen anwenden. Rainer W. schrieb: > Michael schrieb: >> ... mit möglichst hoher Auflösung > Bleeding Edge of Technology hat mit Standardlösungen nichts zu tun. > Eventuell muss der TO hier Abstriche machen, Die Auflösung ist mit der Vorgabe "ADS1220" ja bereits festgelegt, nix "Bleeding Edge". Für die erbetene Hilfe war das kein Design-Kriterium sondern nur Hintergrundinfo. Dass im nicht-professionellen Umfeld "mit möglichst hoher Auflösung" meistens als "ich möchte mal aus Spass herausfinden, wie weit ich mit meinen Mitteln so kommen kann" gelesen werden muss, verdeutlicht die Fragestellung vielleicht. Finde ich auch völlig ok. Michael schrieb: > Geschwindigkeit spielt praktisch keine Rolle. Wenn man keine fremden Bibliotheken anpassen mag, ist es wohl am einfachsten, das Ganze Q&D per Bit-Banging selbst hinzuklöppeln. https://www.ti.com/lit/ds/symlink/ads1220.pdf ab Seite 34 "8.5 Programming" liefert genug Info, um klarzustellen, dass das kein nennenswerter Aufwand ist. HTH (re)
Re schrieb: > Die Auflösung ist mit der Vorgabe "ADS1220" ja bereits festgelegt, nix > "Bleeding Edge". Unfug Die angegebene Auflösung für einen zu messenden Parameter bezieht sich gewöhnlich auf eben diesen Parameter und nicht auf das Ausgabeformat des verwendeten Wandlers. Angenommen die Spannungsvariation am Pt1000 überstreicht nur 10% des Wandlerbereichs, dann ist die effektive Auflösung für die Spannung bereits um rund 3,3 Bit kleiner. Dazu kommt die Steigung der Kennlinie dU/dT und natürlich das Rauschen, dass die effektive Auflösung weiter reduziert und von der Filterung (ggf. in der Software) abhängig macht. Michael schrieb: > Ich möchte nichts entwickeln, sondern lediglich mehrere bereits > vorhandenen ADS1220-Platinen anwenden. Wie wäre es mit einem Schaltplan deiner Platine und die Beantwortung der Frage nach dem Temperaturbereich?
:
Bearbeitet durch User
Moin, Der ADS1220 ist eigentlich ein sehr guter Ansatz, weil alles Notwendige darin enthalten ist, um einen einfachen Aufbau und RTD Messung in allen Topologien zu ermöglichen. Auch die FW ist dazu recht einfach. Die Polynomische Korrektur der Kennlinie nach Callendar-Van Dusen oder ähnlich lässt sich auch auf einem 8-bitter durchführen, wenn man das Polynom durch Faktorisierung auf einfache Multiplikationen reduziert. Generell genügen bei Temperaturerfassung ein paar Messungen/s. Das schafft auch ein AVR. Eine interpolierende LUT ist natürlich sonst auch ratsam. Ich habe mir selber ein paar ADS1220 Bords bestellt, um selber damit Versuche anstellen zu können. Der ADS1220 ist ein nützliches Teil. Für gute RTD Genauigkeit muß der Referenz Widerstand so genau wie möglich bekannt sein und temperaturstabil. Hier eignen sich gewisse Film Typen mit wenigen oder Null TK und 0.01% Genauigkeit. Die kosten natürlich um die $25, aber einer genügt. Wenn man alles richtig macht, ist je nach Güte des RTDs eine konvertierte Messgenauigkeit um +/- 0.05% durchaus mit mässigen Mitteln erreichbar. An sich ist das ein tolles Projekt. Gerhard
:
Bearbeitet durch User
Rainer W. schrieb: > Re schrieb: >> Die Auflösung ist mit der Vorgabe "ADS1220" ja bereits festgelegt, nix >> "Bleeding Edge". > > Unfug > > Die angegebene Auflösung für einen zu messenden Parameter bezieht sich > gewöhnlich auf eben diesen Parameter und nicht auf das Ausgabeformat des > verwendeten Wandlers. > > Angenommen die Spannungsvariation am Pt1000 überstreicht nur 10% des > Wandlerbereichs, dann ist die effektive Auflösung für die Spannung > bereits um rund 3,3 Bit kleiner. Dazu kommt die Steigung der Kennlinie > dU/dT und natürlich das Rauschen, dass die effektive Auflösung weiter > reduziert und von der Filterung (ggf. in der Software) abhängig macht. > > Michael schrieb: >> Ich möchte nichts entwickeln, sondern lediglich mehrere bereits >> vorhandenen ADS1220-Platinen anwenden. > > Wie wäre es mit einem Schaltplan deiner Platine und die Beantwortung der > Frage nach dem Temperaturbereich? Im Datenblatt, Abbildungen 77-79 werden 2.4W RTD Schaltvorschläge vorgebracht. Es ist überzeugend, wie einfach mit solchen Bausteinen eine hochwertige Umsetzung des Vorhabens realisierbar ist. Die kleinen im Handel angebotenen Bords lassen sich ohne Mühe für RTD, wie in den Schaltbeispielen angegeben, verdrahten. Eine Widerstandsmessgenauigkeit von besser als +/- 10mOhm sollte in der Praxis ohne Weiteres erreichbar sein, bzw hatte ich früher mit anderen Bausteinen erreicht.
Gerhard O. schrieb: > Die > Polynomische Korrektur der Kennlinie nach Callendar-Van Dusen oder > ähnlich lässt sich auch auf einem 8-bitter durchführen, wenn man das > Polynom durch Faktorisierung auf einfache Multiplikationen reduziert. Auch auf 8-Bittern kann man richtige Float-Berechnungen machen, sofern es nicht auf extrem hohe Geschwindigkeit oder maximal reduzierten Speicherbedarf ankommt. Temperaturen sind nichts, was man mit hohen Frequenzen messen müsste. Und das will der Threadstarter ja auch nicht: Michael schrieb: > Geschwindigkeit spielt praktisch keine Rolle. Sofern man nicht gerade meint, den Kram mit einem Tiny abwickeln zu müssen, ist i.d.R. das Flash des µC so groß, daß die paar Kilobyte, die für Float nötig sind, auch einfach nicht stören. FÜr 8-Bit-AVR gibt es allerdings standardmäßig nur 32-Bit-Float, mit 64 Bit hat sich hier mal jemand beschäftigt: Beitrag "64 Bit float Emulator in C, IEEE754 compatibel" Ja, es ist hier auf µC.net eine Quasi-Religion, krampfhaft float und auch Funktionen wie printf zu vermeiden, aber das ist oft deutlich hinderlicher als daß es wirklich sinnvoll wäre. Premature Optimisation und so.
Harald K. schrieb: > FÜr 8-Bit-AVR gibt es allerdings standardmäßig nur 32-Bit-Float Vielleicht haben wir Glück und dem TO reicht eine 6-stellige Auflösung aus? Aber ich muß zugeben, 15 Stellen wären natürlich besser.
Harald K. schrieb: > FÜr 8-Bit-AVR gibt es allerdings standardmäßig nur 32-Bit-Float Nur wenn man eine veraltete, nicht mehr unterstützte Compilerversion einsetzte. Älteste aktuell (2025) noch unterstützte GCC-Version ist v13. 64-Bit double gibt es seit GCC v10 (Release 2020). https://gcc.gnu.org/gcc-10/changes.html#avr
Johann L. schrieb: > eine veraltete Tun es denn mittlerweile auch printf und seine Brüder mit 64 Bit double?
Arduino F. schrieb: > Johann L. schrieb: >> eine veraltete > > Tun es denn mittlerweile auch printf und seine Brüder mit 64 Bit double? Was implementiert ist, ist die Größe von [long] double korekt zu behandeln. Eine [long] double Erweiterung würde printf / scanf IMO zu sehr aufblasen. Bisher hat auch noch niemand eine entsprechende Erweiterung vorgeschlagen. Für eine Ausgabe kann man einfach nach float casten (was dann bedeuet, dass man long double zur Berechnung verwenden muss).
:
Bearbeitet durch User
Johann L. schrieb: > Für eine Ausgabe kann man einfach nach float casten Also hat sich da in den letzten Jahren wenig geändert. Man kann mit 64 Bit double rechnen, aber man bekommt sie nicht ohne Klimmzüge(libc Ünterstützung) rein oder raus. Schade eigentlich.... Speicherung nur im Binärformat
Gerhard O. schrieb: > wenn man das Polynom durch > Faktorisierung auf einfache Multiplikationen reduziert. Gemeint ist wohl Auswertung gemäß Horner, und nicht etwa eine tatsächliche Polynomfaktorieierung (ist noch nicht mal klar, ob das Polynom in Linearfaktoren zerfällt). https://de.wikipedia.org/wiki/Horner-Schema Das Verfahren wird man auch auf z.B. 32-Bit Systemen einsetzen wollen, da besser konditioniert als eine naive Auswertung.
:
Bearbeitet durch User
Johann L. schrieb: > Gerhard O. schrieb: >> wenn man das Polynom durch >> Faktorisierung auf einfache Multiplikationen reduziert. > > Gemeint ist wohl Auswertung gemäß Horner, und nicht etwa eine > tatsächliche Polynomfaktorieierung (ist noch nicht mal klar, ob das > Polynom in Linearfaktoren zerfällt). > > https://de.wikipedia.org/wiki/Horner-Schema > > Das Verfahren wird man auch auf z.B. 32-Bit Systemen einsetzen wollen, > da besser konditioniert als eine naive Auswertung. Ja. Genau diese Methode benutzte ich damals. Ich vergass, dass es als Horner Methode benannt wird. Danke für den Hinweis.
:
Bearbeitet durch User
Arduino F. schrieb: > Man kann mit 64 Bit double rechnen, aber man bekommt sie nicht ohne > Klimmzüge(libc Ünterstützung) rein oder raus. > Schade eigentlich.... Das wäre doch keine Raketentechnik, wenn man es selber schreibt! Für meine Zähler mache ich das seit Jahrzehnten und auch ein AVR ist dabei recht flott. Aber was soll hier die Versteifung auf 'double'-Berechnungen bringen? Der TO ist nicht einmal in der Lage, Messwerte aus dem ADC auszulesen und seine 'Anforderungen' sind die übliche Spinnerei hier. Das ist schade!
Johann L. schrieb: > Nur wenn man eine veraltete, nicht mehr unterstützte Compilerversion > einsetzte. Das ist hier im Forum für einige quasi Brauchtum, wenn nicht gar Volkssport.
Mi N. schrieb: > Aber was soll hier die Versteifung auf 'double'-Berechnungen bringen? Noemand versteift sich auf double. Es wurde lediglich angemerkt, dass avr-gcc IEEE double an Bord hat, falls man es denn nutzen möchte.
Johann L. schrieb: > Mi N. schrieb: >> Aber was soll hier die Versteifung auf 'double'-Berechnungen bringen? > > Noemand versteift sich auf double. Es wurde lediglich angemerkt, dass > avr-gcc IEEE double an Bord hat, falls man es denn nutzen möchte. Ich denke, Gleitkommzahlen sollte man generell nur dann benutzen, wenn ihr Einsatz sinnvoll ist. Das ist bei den kleinen µC und den darauf typischerweise laufenden Anwendungen so gut wie nie der Fall. Ausnahmen existieren sicherlich, bestätigen aber wie immer nur die Regel. Und auch mit mehr Resourcen sollte man sich den Einsatz von Gleitkommazahlen im Allgemeinen und double oder noch mehr im Besonderen sehr gut überlegen und das eigentlich nur dann ernsthaft in Erwägungung ziehen, wenn es entsprechende Hardwareinheiten zur Unterstützung gibt. Das Softwaregebastel in den Runtimes irgendwelcher Programmiersprachen ist mehr so als Machbarkeitsstudie ohne ernsthaften Praxisbezug zu verstehen. Es nützt ja nix, wenn man eine hochgenaues Ergebnis liefern kann, wenn es erst nächstes Jahr im Frühjahr verfügbar wird. Und es nützt insbesondere dann nix, wenn es in Wirklichkeit garnicht so genau sein muss!
Ob S. schrieb: > Und auch mit mehr Resourcen sollte man sich den Einsatz von > Gleitkommazahlen im Allgemeinen und double oder noch mehr im Besonderen > sehr gut überlegen und das eigentlich nur dann ernsthaft in Erwägungung > ziehen, wenn es entsprechende Hardwareinheiten zur Unterstützung gibt. Wie Du selber weißt, ist das völliger Quatsch. Man nimmt, was man braucht. Fehlt nur noch Deine Forderung, alles in Assembler zu programmieren. Leider bist Du im letzten Jahrtausend stehen geblieben.
Ob S. schrieb: > Es nützt ja nix, wenn man eine hochgenaues Ergebnis liefern > kann, wenn es erst nächstes Jahr im Frühjahr verfügbar wird. Schon ein 8-Bit-Prozessor aus den späten 70er Jahren konnte mit double ausreichend schnell rechnen. Mir scheint, Du hast Dich beim beständigen irgendwo-falsch-abbiegen in irgendeinem Gewölle verheddert.
Ob S. schrieb: > Das Softwaregebastel in den Runtimes irgendwelcher Programmiersprachen > ist mehr so als Machbarkeitsstudie ohne ernsthaften Praxisbezug zu > verstehen. Dann darfst du auf kleineren CPUs auch nicht mit 32-Bit Integer rechnen. Und eine Division geht garnicht, nicht einmal mit 8 Bit. Keine Hardware, nur Softwaregebastel...
Ob S. schrieb: > Johann L. schrieb: >> Niemand versteift sich auf double. Es wurde lediglich angemerkt, dass >> avr-gcc IEEE double an Bord hat, falls man es denn nutzen möchte. > > Ich denke, Gleitkommzahlen sollte man generell nur dann benutzen, wenn > ihr Einsatz sinnvoll ist. Genau. Es ist Sache des Anwenders, das zu entscheiden. Und Sache der Tools ist es, Funktionalität zu bieten. > Das Softwaregebastel in den Runtimes irgendwelcher Programmiersprachen > ist mehr so als Machbarkeitsstudie ohne ernsthaften Praxisbezug zu > verstehen. Allein für AVR + IEEE double findet man mindestens 5 verschiedene Implementierungen unterschiedlicher Autoren in Netz. Und das sind nur diejenigen, die man öfentlich findet. Eine konkret genannte Anwendung war z.B. Auswertung von GPS-Daten, wo erklärt wurde, IEEE single sei zu ungenau. Ein AVR @ 16MHz schafft 1000 Funktionsauswertungen oder mehr pro Sekunde, wie sinl, asinl, etc. Eine GPS Auswertung dauert also nicht bis zum nächsten Frühjahr.
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.