Ds18s20

Aber das Zitat aus Seite 8 sagt, daß beim PowerUp automatisch der Wert aus dem korrespondierendem Eeprom-Register geladen wird. Wenn man da also was anderes als "12Bit" reingeschrieben hat, ist das nach jedem PowerUp dieser andere Wert.
Meintest Du also, daß der Wert im korrespondierenden Eeprom-Register "out of the box" "12Bit" ist, bis man was anderes reinschreibt, oder wie?
Dann wäre Die Antwort auf Ingos Frage: "Nein, Du kannst den Wert einmal ins Konfigurationsregister (Scratchpad) schreiben, und anschliessend das Copy Scratchpad veranlassen."
 
zu 1) Also ich meinte das mit der binären Auflösung ... korrekt ;-)
zu 2) da habe ich mir halt die Frage gestellt wie genau das beim POWER UP klappt, ob dann automatisch der in das Scratchpad geschriebene Wert für 9bit Auflösung nach jedem Neustart wieder dann auf 9bit steht.

EDIT
Stimmt wir sind beim DS18B20 :) Nachdem ich mir mal eine Lupe genommen hatte konnte ich das 3.Zeichen auch tatsächlich lesen. :read:
 
Ich kann auch nur wiedergeben, was im Datenblatt steht...
wie genau das beim POWER UP klappt, ob dann automatisch der in das Scratchpad geschriebene Wert für 9bit Auflösung nach jedem Neustart wieder dann auf 9bit steht
Nein, es wird der Wert aus dem korrespondierenden Eeprom-Register ins Scratchpad geladen.
Du mußt...
den Wert einmal ins Konfigurationsregister (Scratchpad) schreiben, und anschliessend das Copy Scratchpad veranlassen
Dadurch wird der Wert vom (flüchtigen) Scratchpad ins (nichtflüchtige) Eeprom kopiert, und folglich bei jedem PowerUp geladen.

Die binäre Auflösung ist beim DS18S20 immer(!) ein halbes Kelvin, wobei der Sensor nur einen Teil der möglichen 2^9 Werte erfaßt/ausgibt.

Die binäre Auflösung ist beim DS18B20 immer(!) ein sechzehntel Kelvin, wobei der Sensor nur einen Teil der möglichen 2^12 Werte erfaßt/ausgibt.
Je nach vorgegebener "Wandlungsgeschwindigkeit" (?) enthalten dabei die untersten Bits zu verwerfende/falsche Daten, effektiv hast Du also 11, 10 oder 9 Bit (was zu den achtel, viertel, halben Kelvin führt).
If the DS18B20 is configured for 12-bit resolution, all bits in the temperature register will contain valid data. For 11-bit resolution, bit 0 is undefined. For 10-bit resolution, bits 1 and 0 are undefined, and for 9-bit resolution bits 2, 1, and 0 are undefined.
Beim auslesen der beiden Temperatur-Register erhälst Du immer alle 16 Bit (also vorzeichenbehaftete 16 Bit Ganzzahl im Zweierkomplement. Signed Int16 oder sowas.
Die führenden Sign-Bits spielen keine Rolle, sind Zweierkomplement-konform. Die untersten 3 Bits enthalten je nach Konfiguration invalide Daten, @fredred teilt deswegen durch 8 (2^3), was diese drei Bits quasi abschneidet, und den Rest unter beibehalt der Sign-Bits nach Rechts schiebt (unter Assembler würde man einfach dreimal aritmetrisch Rechtsschieben (ASR)).
Effektiv wird daraus also ein 9Bit-Ergebnis, egal was der DS18B20 eigentlich eingestellt hat.
Beim S-Sensor wird das genauere Ergebnis unter Einbeziehung von "Count_per-C" und "Count_remain" (Scratchpad) ermittelt.
Beim B-Sensor sind diese aber im Datenblatt nicht angegeben, die beiden Register sind dort "reserved". (Konsequenterweise fehlt auch die Formel)
Hier müßte man also die eingestellte "Auflösung" aus dem Konfigurationsregister auslesen, dann die entsprechenden untersten Bits auf 0 setzen (wegmaskieren). Als Ergebnis hat man dann 'ne vorzeichenbehaftete Ganzzahl, bei der ein LSB einem sechzehntel Kelvin entspricht. Könnte man dann wie gehabt ressourcensparend in dezi-/centi-/milli°C umrechnen (und bei der Ausgabe das Komma dazuschummeln), oder wenn unbedingt nötig in eine Gleitkommazahl wandeln und durch 16 teilen.

(Hmm. bei meinem Datenblatt (B-Sensor) steht in Figure10 zum Configuration-Register, daß Bit6..Bit5 R1..R2 sind. In der folgenden Tabelle werden dann aber nur R0 und R1 verwendet. Ist für Bit5 R0 anzunehmen, oder ist Bit6 R0 und Bit5 R1?)
 
Zuletzt bearbeitet:
Das klingt logisch.

Also setze ich beim ersten Mal die 9bit ins EEPROM ... beim zweiten mal lädt er diesen Paramter beim powerup.
Jetzt stoße ich eine Wandlung an und erhalte dann 0000_0000_ 0000_0000 ?? und die drei letzten Bits sind dann undefiniert - heißt da steht irgendwas drin oder definiert 0 ?
 
Ja, natürlich geht das nur über das Scratchpad. Im Eeprom steht eben erstmal 12Bit. Läßt Du da 9Bit reinkopieren, steht 9Bit drin.
Der Sensor lädt bei jedem PowerUp diese Konfiguration.


Ich würde von "irgendwas" ausgehen, ob der die eigentliche Digitalisierung ähnlich dem ADC in den AVR durch sukzessive Approximation durchführt (dann würden unterschiedliche Auflösungen unterschiedliche Wandlungszeiten erfordern (paßt)), hab ich nicht recherchiert - dann könnten die nicht mehr digitaliesierten Bits alle(!) einen festen Wert haben (ob 1 oder 0 hab ich jetzt nicht mehr im Kopf - irgendwo hatten wir hier die Arbeitsweise des AVR-ADC mal auseinandergenommen).
Kannste ja einfach mal ausprobieren, ob die immer 1 oder immer 0 sind, oder rauschen.

Du liest das Scratch ja eh immer komplett aus, hast also auch das tatsächliche Konfigurationsregister. Die beiden Temperaturregister sind als INT16 bereits die Temperatur in sechzehntel-°C. Je nach tatsächlicher Auflösung des Sensors stimmen aber die letzten Bits ggf nicht, deswegen schaust Du im Konfigurationsregister (hast Du ja mitausgelesen) nach, welche das sind, und setzt die 0 (bei 9bit zB alle drei). Damit stimmt die Temperatur bereits (als sechzehntel°C), wenn Du das jetzt irgendwie als dezi-/centi-/milli°C oder als Gleitkommazahl ausgeben willst, mußt Du das wie gehabt umrechnen lassen.

Hier mal noch was zum Hintergrund von DS1820, DS18S20, DS18B20

@fredred , kannst Du vielleicht mal was zu Deinem Rechenweg beim B-Sensor sagen, wegen der reservierten Register, die Du da verwendest? Auslesen kann man die, klar, aber sind da wirklich die entsprechenden Daten drin, oder fällt das dann nur nicht auf? Laut meinem letzten Link arbeitet der S-Sensor immer intern mit 12 Bit, wobei das Ergebnis (konform zum 1820) auf 9Bit gerundet wird.
Der B-Sensor kann auch die 12Bit, gibt die selbst aus und rundet nicht - es macht also eigentlich gar keinen Sinn, da irgendwas gerundetes rekonstruieren zu wollen...
Der B-Sensor kann aber auch in der Auflösung reduziert werden (um die Messung zu beschleunigen), wobei die LSB(s) dann zu verwerfen sind.
 
dann könnten die nicht mehr digitaliesierten Bits alle(!) einen festen Wert haben (ob 1 oder 0 hab ich jetzt nicht mehr im Kopf - irgendwo hatten wir hier die Arbeitsweise des AVR-ADC mal auseinandergenommen).
Hier wars:
Der ADC arbeitet folgendermaßen:
Er versucht die anliegende analoge Spannung sukzessiv durch vielfache eines 1023stels der Referenzspannung mithilfe eines DAC zu approximieren.
0b11_1111_1111 entspräche der Referenz, 0b00_0000_0000 ist 0
Von links nach rechts werden jetzt einfach die Bits "ausprobiert", im ersten Schritt wird also 0b10_0000_0000 auf den DAC gelegt, wodurch der die halbe Referenzspannung ausgibt (Uref*(512/1023)). Diese wird mit tatsächlichen Eingangsspannung verglichen.
Ist die tatsächliche Spannung größer, bleibt die 1, sonst 'ne 0. Danach gehts mit der nächsten Stelle weiter. Nehmen wir an, die 1 ist stehengeblieben - jetzt wird 0b11_0000_0000 auf den DAC gelegt - der gibt foglich dreiviertel der Referenz raus... wieder wird verglichen usw., sind alle 10 Bits durch, hat man das digitalisierte Ergebnis dazustehen.
Beim AVR wären es theoretisch Nullen, ABER der AVR-ADC kopiert sein Ergebnis immer erst in die beiden Result-Register, wenn alle 10 Bits digitalisiert sind. Auf die 10Bit, die den DAC ansteuern hat man keinen Zugriff.
Wie gesagt, wie konkret der DS18x20 digitalisiert, weiß ich nicht. (nur eben, daß da ein ADC 'ne Differenz zwischen einer thermostabilen und einer thermolabilen Spannungsreferenz mißt.
 
Der Link ist echt gut.

OK, dann muss ich den MSB und den LSB als ein integer zusammensetzen und entsprechend an BIT 15 erkennen ob eine negative Zahl als MINUS GRADE herrschen oder nicht. BIT0 bis BIT2 ignoriere ich oder setze es direkt auf 0
Oder ich schiebe einfach die Zahl nach rechts um drei Stellen raus ....
Dann müßte ich ja die Binärzahl in eine Dezimalzahl wandeln und entsprechend nur noch das KommA und Vorzeichen ordentlich Für die Anzeige zusammensetzen... rechnen kann ich ja mit den Dezimalzahlen ohne Komma ...


Wenn ich das zusammen habe poste ich mal mein Beispiel...
 
NEIN, die beiden Bytes sind zusammen bereits ein 16bit-signed. Da mußt Du mit Bit15 gar nichts mehr machen... Nur eben ggf die letzten 1-3 Bits Nullsetzen. In Bascom sollte das einem Integer entsprechen, Du mußt also nur die beiden Bytes in einen deklarierten/definierten Integer stopfen. Obs dafür bereits was gibt, und wie effizient das ist, weiß ich nicht. Am einfachsten (auch zu verstehen) sollte Overlay sein. Du legst eine Integer an, an der Position des LowBytes mit Overlay eine low-Variable, an die Position des HighBytes eine High-Variable (das alles erzeugt keinen Code)
Das empfangene LSByte des Sensors knallst Du in die Low-Variable, das MSByte in die High-Variable. In Abhängigkeit der Auflösungskonfiguration löscht Du die untersten Bits in der Low-Variable (bitweises logischs UND, bei 9Bit also mit &B1111_1000).
Greifst Du nun auf die Integervariable zu hast Du die bereinigten sechzehntel°C
 


CodeBox BascomAVR

DIM Sensordaten(9) As Byte   ‘(Byteanzahl)

DIM Sensornummer(8,8) As Byte  ‘(Byteanzahl, Sensornummer 1 bis n)

DIM TEMP AS String  'String zur Umwandlung der Temperatur


1wreset  ‘Reset druchführen

1wwrite &hCC  ‘SKIP ROM – ALLE Sensoren ansprechen

1wwrite &h44  ‘Temperaturmessung starten

Waitms 500  'warten max.Messzeit


1wverify Sensornummer(0,1)  'Sensor auswählen

1wwrite &hBE  'Temperatur aus Scratchpad lesen

Sensordaten(1) = 1wread(9)  'Daten Byteweise in Variable lesen


Sensordaten.0 = 0   'Löschen Bit 0 wg. 9bit Auflösung

Sensordaten.1 = 0  'Löschen Bit 1 wg. 9bit Auflösung

Sensordaten.2 = 0  'Löschen Bit 2 wg. 9bit Auflösung


TEMP = STR (Sensordaten)  'Umwandeln der Integer in String

LCDAT 1, 1 , Format(TEMP,“0.0“); “°C“  '



so würde ich mir das dann denken ....
 
Den 1wire-Kram bin ich jetzt nicht durchgegangen, wenn das soweit stimmen sollte, hast Du nach Zeile 21 im Array Sensordaten (9 Bytes) ein Abbild des Scratchpads.
Sensordaten(1)=Temperatur-Lowbyte
Sensordaten(2)=Temperatur-Highbyte
Sensordaten(5)=Configuration Register

greifst Du auf Sensordaten(x) zu, wird das als Byte behandelt (da Du das ja als Byte-Array definiert hattest)
Insbesondere kannst Du prüfen, welche der beiden Resolution-Bits (Sensordaten(5).6, Sensordaten(5.5)) gesetzt sind, und dann per Fallunterscheidung festlegen welche der Bits im Temperatur-Lowbyte zu löschen sind. Das ist dann natürlich nicht wie bei Dir in den Zeilen 24..28 sondern Du mußt die Bits in Sensordaten(1).0, Sensordaten(1).1 und Sensordaten(1).2 verwenden.

Wie gesagt ist Sensordaten ein Array of Byte, aber die Bits in den ersten beiden Bytes sind Dein gesuchter Integer, Du mußt Bascom also nur noch dazu bekommen, auf die beiden in Form eines Integers zuzugreifen. Und das machst Du, indem Du eine Integervariable (nennen wir sie Temperatur) definierst, die genau dort im Speicher angelegt wird (also eigentlich keine neue Variable im Sinne von reserviertem Speicher ist, sondern nur ein neuer "Griff" auf die beeits definierte Stelle).
Das machst Du mit Overlay


CodeBox BascomAVR
Dim Temperatur as Integer at Sensordaten(1) Overlay

(@Bascom-Profis: Bitte korrigieren)
Ein Integer besteht bei Bascom aus zwei Bytes, dargestellt im Zweierkomplement (also vorzeichenbehaftet).
Zuerst steht das LowByte im Speicher, dann das HighByte. Das LowByte von Temperatur greift also auf Sensordaten(1) zu, das Highbyte auf Sensordaten(2). klar?
Da Temperatur als integer definiert ist, werden alle Umwandlungen etc auf Basis eines Integers durchgeführt.
Allerdings steht ein Bit dort immer noch für ein sechzehntel°C (also bei gemessenen 2°C stehen da 32 drin, eben 32/16.)
Wenn Du erstmal soweit mitgekommen bist, kann man sich Gedanken machen, wie man die dezimal (ggf mit Nachkommastellen) darstellen kann, ohne wirklich mit Kommazahlen Rechnen zu müssen...
 
Also definiere ich das Overlay damit ich auf die beiden Bytes LSB und MSB mittels INTEGER Variablen zugreifen kann?
Logisch definiere ich dann den Pointer auf den Speicherbereich der beiden Bytes ?

Dann müßte ich doch eigentlich die Umwandlung auf das Overlay definieren ?


CodeBox BascomAVR
TEMP = STR (Temperatur)  'Umwandeln der Integer in String
 
Ja genau, Du rechnest mit der Integer-Variable "Temperatur" weiter. Tatsächlich nutzt die dieselben Speicherzellen wie Sensordaten(1und2), nur das Bascom das eben als eine zusammenhängende vorzeichenbehaftete (Zweierkomplement) 16Bit-Ganzzahl betrachtet, und bei irgendwelchen Manipulationen eben entsprechende Integeroperationen verwendet. Insbesondere bei der angedeuteten "mach'n String draus"-Operation werden die führenden Einsen zum "-" usw.

Da der Inhalt von "Temperatur" aber auf der Basis von sechzehntel-°C ist, würde der String Dir immer den sechzehnfachen Wert anzeigen.
Hochsprachentypisch kannste natürlich jetzt aus dem Integer 'n Single machen lassen (Gleitkomma), den durch sechzehn teilen, und gefused in den String schreiben. Mit den wenigen Bascom-Zeilen, veranlaßt Du aber im Hintergrund einen erheblichen Code- und Zeitaufwand, weil das ganze eben mit Fließkomma umgesetzt wird.

Viel weniger Aufwand ist, wenn Du Die sechzehntel°C zb in hundertstel°C umrechnest. Das Komma malst Du Dir aufs Display (ok, Du kannst es Dir auch bloß denken, oder im String dazuschummeln - Wenn man eine eigene Ausgaberoutine schreiben müßte/würde, würde man es da direkt miteinbauen, oder besser in der "mach'n String draus"-Funktion.)
Wie kommst Du von sechzehntel°C auf hunderstel°C?
 
Zuletzt bearbeitet:
...
Wie kommst Du von sechzehntel°C auf hunderstel°C?

Das weis ich noch nicht... Ich denke noch :) drüber nach.
Ich hätte jetzt den HochsprachentypischenKanonenkugelalgorhytmus genommen :) Hast Du oder jemand einen Vorschlag für die Alternative?
Die Division durch 16 sollte doch zur Basisverschiebung auf Zehntel so oder so durchgeführt werden.


Das hier habe ich im Netz gefunden (natürlich angepaßt auf das Beispiel hier)


CodeBox BascomAVR
If Sensordaten(2) > 0 Then  'Minus Temperatur
  Temperatur = 256 - Temperatur
  Temperatur = Temperatur * 10
  Temperatur = Temperatur / 16
  Temperatur = 0 - Temperatur  'Vorzeichen -
  Else
  Temperatur = Temperatur * 10
  Temperatur = Temperatur / 16
  End If
  TEMP = Str(Temperatur) 'Umwandeln der Integer in String

LCDAT 1,1,(TEMP , "0.0") ; "°C"

http://www.roboternetz.de/community/threads/60657-Beispielprogramm-für-DS1820-Temperatursensor-und-RN-AVR-Universal


und das hier habe ich gefunden:
http://files.elv.de/bilder/journal/2015_01/12/2015_01_12_bascom_teil_14.pdf

wobei ich das Ganze auf Seite 8 mit MAKEINT, Fusing und SHIFTOUT nicht wirklich durchblilcke.

Man schibt hier quasi die restlichen Nachkommastellen einfach aus der Variablen ...
 
Zuletzt bearbeitet:
Makeint fügt irgendwie (rechnet zusammen) zwei Bytes zu einem (neuen/anderen) Integer zusammen. Die Quell-Bytes müssen dabei nicht unbedingt nacheinander im Speicher liegen. Da sie das bei uns aber bereits tun, braucht da gar nichts gerechnet zu werden - wir haben Bascom mit der definition ..at..overlay nur gesagt, wie die dort bereits liegenden Daten weiter zu behandeln sind.

Shiftout pumpt ein (oder auch mehrere) Byte seriell durch ein Bein des Controllers. Quasi über die serielle Schnittstelle (SPI), je nach Vorgabe auch in Software umgesetzt.

Fusing wandelt eine Gleitkommavariable (Single) in einen String um, der der dezimalen Darstellung des Wertes entspricht. Dabei wird die Darstellung bezüglich der Nachkommastellen nach einer vorzugebenden Maske getrimmt.

Wenn Du von °C auf centi°C kommen willst, mußt Du die °C mit 100 Multiplizieren. Da Du aber sechzehntel-°C als Wert hast, mußt Du auch noch durch 16 teilen.
Da Integer Ganzzahlen sind (und bei der ganzzahligen Division theoretische Nachkommastellen verschwinden), muß erst multipliziert werden, und zuletzt dividiert.
Vorher kannst Du natürlich kürzen.
Also mal 25 und durch vier.
Außerdem darf das Zwischnergebnis der Multiplikation nicht überlaufen. Der Sensor liefert maximal 2000dez bei 125°C, minimal -880dez bei -55°C.
Das Produkt würde (oben) leider nicht in eine 16Bit-Integer passen. Entweder man verschenkt die Auflösung, indem man erstmal durch zwei teilt (und ggf rundet), dann mit 25 multipliziert, und anschliessend nochmal durch zwei teilt.
Oder man legt die Temperatur-Variable auf eine größere Integer aus. (In Assembler gäbe es noch mehr Möglichkeiten) In Bascom wäre das eine Long (vorzeichenbehaftete 32Bit Integer).


CodeBox BascomAVR
dim Temperatur_L as Long
Temperatur_L=Temperatur*25
Temperatur_L=Temperatur_L/4 'effizienter wäre hier viermal arithmetrisch rechtsschieben, geht sicher auch in Bascom
'in String packen
'ggf an drittletzter Stelle ein Komma dazwischenschummeln (gibts sicher 'n Bascom-Befehl)
'ausgeben
Das wäre eine zusätzliche, neue (echte) Long-Variable zur vorhandenen Integer-Variable (die in Wirklichkeit nur Overlay im Sensordaten-Array liegt)
Im Gegensatz zur Overlay-Integer verbraucht diese neue Long also Speicher.
Verstanden?
Dann leg ich noch eins drauf:
Im Sensordaten-Array hast Du ja
Sensordaten(1)=Low-Temperaturbyte <-- hier greift außerdem die Integer Temperaturvariable (Overlay)
Sensordaten(2)=High-Temperaturbyte
Sensordaten(3)=ausgelesener TH-Alarmwert
Sensordaten(4)=ausgelesener TL-Alarmwert
Sensordaten(5)=Controlregister <--hier kannst Du die tatsächliche Auflösung des Sensors ermitteln, und per Fallunterscheidung die zu ignorierenden Bits in Sensordaten(1) löschen
Sensordaten(6..8)=reservierte Bytes
Sensordaten(9)=Prüfsumme
Wenn Du die Prüfsumme kontrollieren willst, mußt Du das machen bevor Du im Array irgendwelche Daten überschreibst (also zB die invaliden Bits).
Wenn Dich die ausgelesenen Alarmgrenzen interessieren, verwertest Du die jetzt.
danach verleibst Du die beiden Speicherplätz in die Temperaturvariable ein - Du definierst Temperatur also nicht als Integer, sondern als *Trommelwirbel* ... Long. Natürlich auch "at Sensordaten(1) overlay".
Wenn die Temperatur positiv war (also das MSB von Sensordaten(2) null ist), müssen diese beiden Bytes (in allen Bits) auch null sein. Wenn die Temperatur negativ war, müssen alle Bits eins sein.
Oder anders formuliert: der Sensor liefert das Ergebnis mit 16 Stellen(Bits). Wir deklarieren vorn weitere 16 Stellen hinzu, und füllen die führenden Nullen oder Einsen auf.
klingt komplizierter als es ist:

CodeBox BascomAVR
'Sensordaten in Array lesen
'Checksumme
'ggf Alarmwerte verwerten
'invalide Bytes mithilfe des ausgelesenen Konfigurationsbytes aus Sensordaten(1) löschen
'Sensordaten(3..4) in Temperaturvariable assimilieren
If Sensordaten(2)>127 then
  Sensordaten(3)=255
  Sensordaten(4)=255
else
  Sensordaten(3)=0
  Sensordaten(4)=0
end if
'Temperatur kann jetzt auf die korrekten vier Bytes zugreifen, und ist groß genug
 
Zuletzt bearbeitet:
OK. In Summe klingt das alles nach viel zu viel Overhead für einfache Operationen....
Meine Tendenz ist dann eher dass wir bei dem OVERLAY der 16bit (LSB und MSB) bleiben
 
??
Das einzige was sich ändert ist die Defininition von Temperatur (eben Long statt Integer), und die If.. then..else..endif da oben (6 Zeilen).

Wenn Dich die Checksumme nicht interessiert, ignorierst Du das eben,
Wenn Dich die Alarmgrenzen nicht interessieren, kannst Du den entsprechenden Speicher ohne Rücksicht überschreiben.
Wenn Du immer(!) von einer festen Auflösung ausgehst, mußt Du die Bits im Config-Register nicht auswerten, sondern kannst die Bits fest im Code vorgegeben löschen. Genau genommen mußt Du die nichtmal löschen, sondern teilst einfach durch 2, 4 oder 8. Integerdivision, dabei verschwinden die letzten Bits einfach. Dann paßt das Produkt mit 25 ggf sogar in den Integer.

Du kannst das ja einfach mal mit Integer und 9Bit-Darstellung umsetzen - der Schritt von da auf 10, 11 oder 12Bit kannst Du danach umsetzen, der ist nicht so groß. Im Prinzip steht alles schon da oben. Stecks einfach mal zusammen (in Hard- und Software)
 
So, nach nun 2 Wochen erneutem Stillstand ... nochmals eine Nachfrage im Kontext:

Kann man die Sensornummern, die man ausliest in einen Speicherbereich des Megas einlesen, der nach dem Neustart (Powerless) noch vorhanden ist ?
 
Super ... Danke! Ich werde das direkt mal austesten ....
 
Alternativ kannst Du auch einfach Bascom eine Variable im Eeprom alloziieren lassen:

CodeBox BascomAVR
Dim LustigerName As Eram Byte/String * x/whatever

Auf die ERAM (Eeprom) -Variable kannst Du dann aber nicht direkt zugreifen, sondern brauchst eine konventionelle SRAM-Hilfsvariable:

CodeBox BascomAVR
Dim Hilfsvariable As Byte/String * x/whatever
Hilfsvariable=irgendwelche Daten
LustigerName=Hilfsvariable

Zum Laden halt andersrum...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)