Stránka 6 z 6
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 05 úno 2020, 10:46
od Maxim
Ještě se zeptám, existují nějaké metody jak zjistit co se v té paměti děje? u mě se chyby projeví tak, že na tom displeji při 70% zaplnění paměti (píše IDE) zobrazují hodnoty, které by měly být vypsány jinde.. po minutě se to třeba sekne úplně.
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 05 úno 2020, 18:37
od ondraN
Padá ti to kvůli chybám, ne kvůli paměti (to možná taky).
Kód: Vybrat vše
long zobrazeniCasuAZnakuCasu(char *pomocnePole , size_t velikostPole , long pocetCyklu) {
long hodnotaCasuUpravena = pocetCyklu;
hodnotaCasuUpravena = pocetCyklu * 2;
if (hodnotaCasuUpravena < 99) {
hodnotaCasuUpravena = snprintf(pomocnePole, velikostPole - 1, "%i" , (long)hodnotaCasuUpravena); //převede int "hodnotaCasu" na řetězec "velikostPole" a uloží do velikostPole délku proměnné velikostPole, kterou vrací funkce snprinf
pomocnePole[hodnotaCasuUpravena] = 's'; //na konec řetězce připíše s
}
if ((hodnotaCasuUpravena > 99) and (hodnotaCasuUpravena < 5939)) {
hodnotaCasuUpravena = hodnotaCasuUpravena / 60;
hodnotaCasuUpravena = snprintf(pomocnePole, velikostPole - 1, "%i" , (long)hodnotaCasuUpravena); //převede int "hodnotaCasu" na řetězec "velikostPole" a uloží do velikostPole délku proměnné velikostPole, kterou vrací funkce snprinf
pomocnePole[hodnotaCasuUpravena] = 'm'; //na konec řetězce připíše m
}
if (hodnotaCasuUpravena > 5939) {
hodnotaCasuUpravena = hodnotaCasuUpravena / 3600;
hodnotaCasuUpravena = snprintf(pomocnePole, velikostPole - 1, "%i" , (long)hodnotaCasuUpravena); //převede int "hodnotaCasu" na řetězec "velikostPole" a uloží do velikostPole délku proměnné velikostPole, kterou vrací funkce snprinf
pomocnePole[hodnotaCasuUpravena] = 'h'; //na konec řetězce připíše h
}
Podívej se, jaký index používáš tady
Kód: Vybrat vše
pomocnePole[hodnotaCasuUpravena] = 'm'; //na konec řetězce připíše m
Kam se ti to zapíše, když je hodnotaCasuUpravena větší než 9, což je poslední člen pole???
Prostě si po nějakém čase začneš přepisovat paměť kde je uloženo něco úplně jiného a to končí zásekem.
Dál jsem ten kód nezkoumal, protože bez pořádných komentářů netuším, co se tam má vlasně dět.
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 05 úno 2020, 18:59
od kiRRow
Hodně ramky ušetříš - Serial.println(F("Tento text bude jen v FLASH pameti a nebude plnit SRAM"));
Abys přesně věděl co se děje v paměti, musel bys ten program po zkompilování prozkoumat na simulátoru toho procesoru ... a někdy to znamená i jít krok po kroku ...
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 20 úno 2020, 10:03
od Maxim
--> ondraN
Díky za upozornění, tuto chybu jsem opravil.
Zatím jsem nezkoušel vrátit počet ukládaných hodnot, jestli by to mělo vliv na sekání.
Ale rád bych pochopil, jak je možné, že se uložené hodnoty zobrazovali správně, když se řetězec nemohl do vyhrazeného pole vejít.
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 20 úno 2020, 11:43
od ondraN
Musíš si uvědomit, co snprintf vrací za hodnotu. Jednak vrací počet znaků výsledné konverze bez ohledu na na nastavenou max. hodnotu, jednak při chybě vrací zápornou hodnotu. Takže to fungovalo do první chyby nebo první konverze delší než pole.
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 20 úno 2020, 12:37
od gilhad
Maxim píše: ↑20 úno 2020, 10:03
Ale rád bych pochopil, jak je možné, že se uložené hodnoty zobrazovali správně, když se řetězec nemohl do vyhrazeného pole vejít.
I kdyz se retezec do alokovaneho pole "nevejde", tak se da zapsat v plne delce (pokud si nekontrolujeme delku pole) a taky v plne delce zpracovat. Teda prepisou se tim asi nejpis nejake jine promenne za koncem retezce, nebo nealokovana pamet, a muze to mit spoustu necekanych vedlejsich efektu, ale taky treba zrovna nahodou nemusi, nebo nejsou na prvni pohled videt - holt pamet jako pamet ...
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 22 črc 2026, 01:44
od JPLABS
Maxim píše: ↑18 led 2020, 12:37
Dobrý den,
poradil by mi někdo jak zobrazovat záznamy teplot na display?
Pro komunikaci s displayem používám knihovny TFT.h a SPI.h.
Pro měření teploty používám čidla DHT22 a DS18s20.
Hodnoty z těchto čidel převádím na INT kvůli úspoře paměti. Z teploty 24.5 tedy mám číslo 245 a dále pak bojuji s konverzí tohoto čísla na CHAR, protože neumím na display poslat jinou proměnnou než CHAR. Možná někdo poradí jak na to? Konverze čísla mi také dělá problémy, protože někdy má číslo 245 tři znaky a někdy čtyři, takže nevím jak jednoduše tam zpátky vložit tečku.
Děkuji za rady.
Hledal jsem tady něco k DS18S20, našel jsem zprávu nahoře. Takže postup:
celková teplota z DS18S20 je dána součtem lowbyte (1.byte ze scratchpad) a korekcí z hodnot COUNT REMAIN a COUNT PER C z byte 6 a byte 7 ze scratchpad. Korekce obnáší odečíst 0.25 od lowbyte. Aby se to dalo v binárním režimu provést, musí se vynásobit lowbyte 100 a odečíst se 25:
Lowbyte = Lowbyte *100 - 25
Tím máme v Lowbyte 100-násobek základní skutečné teploty bez korekce.
Dále se vypočte korekce. Ta se přirozeně musí též vynásobit 100. Pak se oba údaje sečtou. Tím se dostane celková teplota ovšem vynásobená 100: hodnota 2450, která ve skutečnosti představuje skutečnou teplotu 24.50˚C
Nyní jde o to jak tam vpašovat tu desetinnou tečku.
Když celkovou teplotu podělíme 100, dostaneme integer skutečné teploty: 24
Když takto získaný integer vynásobíme 100 a odečteme od celkové teploty (2450), dostaneme fragment skutečné teploty: 50. Co to je "
integer" a "
fragment" viz základy matematiky, Třeba Přehled užité matematiky od prof. Rektoryse. Je to tam někde hned na prvních stránkách .... Pak už postačí zobrazit za sebou integer, tečku, fragment a přidat pro okrasu znaky ˚C. U mne to takto bylo dnes vyzkoušeno s PIC18F4550
Přišel jsem sem ale s jiným zjištěním. Koupil jsem dnes v GME čidlo DS18S20+
Toto mi funguje, dle Maxim datasheetu s těmito rozdíly:
1/
binární hodnota lowbyte má dělení nikoliv po 0.5˚C ale po 0.125˚C. To znamená, že jsem musel dělit 8 místo 2.
2/
highbyte vrací 11111111 pro kladné teploty a 00000000 pro záporné teploty. Tedy opačně než v datasheetu.
Vyhledal jsem na stránkách Analog Devices aktuální datasheet. Ten je stejný jako od Maxima z roku 2010. Rozdíly tam nejsou. Jediné možné vysvětlení, že obvod DS18S20+ koupený v GME je padělek z Číny a není to originál od Analog Devices. Tomu by asi odpovídala také cena Kč 90.
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 22 črc 2026, 01:58
od JPLABS
Jiná věc, někde v tomto vlákně se píše cosi o displeji na SPI. Takže jeden poznatek, který se může hodit i Arduinistům:
GME prodává OLED displeje of Winstar. Ty mají jiný čip než klasické LCD řádkové displeje. Čip má více kódových tabulek a více možných interface. Když se na plošňáčku displeje zezadu přepájejí tři odpůrky s hodnotou nula Ohm, které fungují jako zkratovávací spojky, dostane se z displeje který je normálně v paralelním režimu displej s rozhraním SPI. Jestli je zájem, udělám fotky co se musí kde přepájet....
Winstar má samozřejmě přímo displeje s SPI, akorát v GME je neuvidíte.
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 22 črc 2026, 20:20
od JPLABS
Update k popisu DS18S20 od GME:
ráno mne napadlo DS18S20 pofoukat fénem, abych se trochu zvýšila teplota. Objevil se problém. Při dosažení teploty 31˚C a kousek začal DS18S20 ukazovat blbosti. Začal výzkum proč...
Příčina se objevila rychle: lowbyte je při 31.5° ve stavu 11111111 čili overload. Vytahnul jsem DS18S20 ze zapojení a objevil jsem další neshodu. Není to DS18S20, nýbrž starý DALLAS DS1820. Jenže GME nabízel a prodal tento obvod pod "Maxim DS18S20"
https://www.gme.cz/v/1488874/maxim-ds18 ... tni-sensor . Vyrazil jsem s účtenkou do GME. Tam jsem se dozvěděl, že DS18S20 ve skutečnosti nemají žádné a že tento co jsem si koupil je stejný "jako" Maxim DS18S20. Pochybuju, že ten koupený "Dallas DS1820", co prodávají jako "Maxim DS18S20+" je ve skutečnosti vůbec Dallas.
Podle jejich webu jich GME má ještě něco přes 300 kusů skladem. Problém s omezením na maximální teplotu 31.5˚C zůstává.
Tak to byl pokus za Kč 90.-
Dneska budu dělat test v GME zakoupeného Dallas 18B20 ...
Re: konverze datových typů / komunikace s displayem pomocí SPI
Napsal: 23 črc 2026, 08:12
od JPLABS
napsal jsem přes noc program pro měření teploty s DS18B20 . Data z čipu posílám na OLED Winstar 16x2 upravený na SPI..
DS18B20 koupený v GME funguje normálně. Ofoukal jsem jej fénem až na 74˚C . Na ofukování reagoval velmi rychle, mnohem rychleji než předešlý "Dallas DS1820". Ochlazování, zejména ke konci kdy se teplota čipu blížila pokojové teplotě, se tahlo velmi dlouho. Vyzkoušel jsem také záporné teploty. Strčil jsem 18B20 na drátkách na chvíli do mrazničky a ochladil obvod na -8˚C. Teplotu zobrazovanou na displeji jsem porovnával s binární hodnotou čtenou z registrů 18B20. Hodnoty odpovídají.
V místnosti, vedle destičky s 18B20, jsem 2cm vedle posadil srovnávací teploměr a porovnával odchylky. Ty dělají +0.75˚C. Čidlo s 18B20 ukazuje o 0,75˚C více. Může to být tím, že používám 18B20 v TO92 pouzdru a čip uvnitř pouzdra sám generuje teplo, ohřívá se. Dle datasheetu může být chyba až 1˚C. Program měří s 18B20 s rozlišením 0.25˚C. To jaksi postrádá smysl, když tolerance 18B20 může být až 1˚C.
Nicméně, "Dallas DS1820", koupený v GME, který měřil jen do 31.5˚C a na ofukování fénem reagoval dost pomalu, ukazoval teplotu o 4˚C nižší než srovnávací teploměr postavený vedle destičky s "Dallas DS1820".
Další projekt bude nyní teploměr s termočlánkem typu K.