Rendben de akkor ezek szerint semmiképpen nem lehet ugy megcsinálni ezt hogy ha nincs lcd akkor serialra irjon mig ha van akkor az lcdre?

Szia!

Sok a hiba ebben a kódban jelenleg. Legalábbis szerintem. Lehet, hogy a C nyelv trükközése ver át engem, de259. sorban nem kell { karakter, míg a 267. sorban egy }


Ugyanez a gondom a 243-249. sorig.

De, meg lehet csinálni, csak ahhoz nem kontans kell, mert azt futásidőben nem tudod módosítani. Futásidőben egy változó értékét tudod módosítani.
Két lehetőség van, mindkettőt leírtuk már:
1. minden egyes kiiratást megírsz kétféleképpen, és a korábban beállított változó alapján egy if-fel eldöntöd hogy hogy melyik fusson le
2. csinálsz egy saját fv-t, ami tartalmazza ezt az if-es vizsgálatot, és ez alapján meghívja a megfelelő print függvényt.
Az utóbbi kisebb kódot jelent, forráskódban és binárisban is, cserébe némileg lassabb lesz a kód, mert a függvényhívásnak mindig van valamekkora költsége futásidőben.

Lehet automatikusra is, de akkor nem dől el fordításkor. A Serial és az LCD is elvisz önmagában 2-4 kB flasht... Plusz némi RAM-ot. A libek használata költséges, nincs ingyen.
Én a futásidejű döntést olyan esetekre tartogatnám, ahol kint a terepen, használat közben kell eldöntenie az eszköznek, hogy mi a helyzet. Nálad most nem így van.

Nem lehet. Az I²C scanner az futásidőben mondja meg, hogy van-e LCD, míg a preprocessor makró még a C/C++ fordító ELŐTT megy végig a kódon.

Igazatok van amugy mert ez csak tulcifrázás valoban.Az Ide-n belül elég gyorsan átlehet irogatni egész sorokat a cserével,csak azt hittem hogy meglehet egyszerüen oldani hogy a libes parancsokra változoval tudjak hivatkozni és akkor nem kellene átirogatnom.

Látjátok én ezért szeretek ide irogatni mert elég hamar rátudtok engem vezetni arra hogy nem biztos hogy minden jo és szép amit én elképzelek.

Na meg szeretem néha tulbonyolitani a dolgokat

Ja és most mindenkinek megy a mancs
Köszönöm szépen mindenkinek az épitö hozzászolását.

Serial- segítségével megnézheted pl 0.1 másodpercenként, hogy van-e usb csatlakoztatva. Lefuttatod a i2C scannert (ami ne VOID legyen hanem int.)

loop:

if (serial)
{
Soroportra('A szöveg');
}

if (I2cScan==1)

{
LCD_re('A szöveg');
}

delay(10); Ok, lehet milis()
.
.
.
A többi kód



Void Sorosportra(char* Szoveg) 'Vagy ahogy szöveget kell átadni a függvénynek.
{
ide az a kód ami kirakja a szöveget a soros portra
}

void LCD_re (char * szoveg) 'Vagy ahogy szöveget kell átadni a függvénynek.
{
ide az a kód ami az LCD-re ír
}

Int I2cScan() 'itt is meg lehetne oldani, hogy a címet is itt megkapja de akkor a loop-ban a hívás változik
{

Ha van akkor return 1;
ha nincs a címen az LCD akkor return 0;
}

Nekem nem jött le elég tisztán, mit szeretnél?

Egy eszközt hordozni kétféle környezet között?
Vagy egy programot használni, kétféle hardveren?
Esetleg programot fejleszteni, kétféle eszközön felváltva?

Mert ettől az ismerettől nagyban függ az ajánlható megoldás!

Amit én javaslok neki az nem pont az amit kér. Azért írok ilyesmit, mert ha működik akkor az jobb szerintem és lehet villogni a megoldással.

Neki az kell, hogy gyorsan tudjon tesztelni serial-ra is, mert nincs LCD mindig nála. Azonban gyorsan lehessen LCD_re átírni a kódot. Erre a #DEFINE tökéletes megoldás.

Ettől nem lettem okosabb!!

Mit tesztel?

Program fejlesztés közben, akármit?
Mert akkor ott van a feltételes fordítás lehetősége.
Bővebben: Link

Vagy hordoz egy eszközt, és annak a kijelzője változó?
De mért szedné le róla mindig az LCDt?

Tisztelt Fórumozók!
Hozzátok fordulnék 2 kérdéssel.
Nem tettem le az ELM327 bluetooth-al való gk. adatok kijelzésére TFT LCD-n arduinoval. Uno és a 1604 LCD-vel megy, csak kevés a memória ezért Wemos D1 Minivel(160MHz), STM32F103RC8T6-al és Maple Minivel próbálkozom. A 2,8” TFT LCD touch screen kijelzőt mindegyik szépen meghajtja de az alábbi problémák léptek fel.

A Wemos D1 Minire sehogy sem csatlakozik a HC-05 vevő. Sem a TX,RX-re, sem a SoftwareSerial BTSerial(D2, D1);-re. A vevő 3,3V-os és UNO-ra csatlakoztatva (TX leosztva) szépen olvas, tehát működik és jók az AT beállítások. Kérdésem: Miért nem olvassa a Wemos D1 Mini a HC-05-t?

Az STM32F103RC8T6 az #include <OBD.h> beszúrása után „fatal error: avr/io.h: No such file or directory” Annyit kinyomoztam, hogy ő nem AVR alapú ezért nem is kellene keresnie az avr/io.h-t. Mit lehet tenni?

Ezek szerint az OBD.h nem platformfüggetlen, direktben használja az AVR MCU-t regiszter szinten. Így ez nem használható az STM32 MCU-val.
Amúgy mi ez az OBD.h, honnan szerezted? Egy link a használt libek forrására sokat segítene ilyenkor.

Szia!

Erről van szó?

Bővebben: Link

Arduino Ide-ben írod?

Ezeket megcsináltad?

Bővebben: Link

Ez a fentiből van.

Az obd.h a git.hub.com-ról származik. Szerintem Ő rendeli el a TX,RX figyelését.

A Wemos-sal az AT parancsokat is szépen megírtam és visszakérdeztem.

Igen, megpróbáltam.

Link?

https://github.com/stanleyhuangyc/ArduinoOBD

Soros kommunikációhoz szükséges pár beállítás. Byte order, Paritás bit, start/stop bit hasonlók. (fejből tolom, nem biztos mindegyik.)

Ezek be vannak állítva? Illetve mindkét eszközön azonosak?

Csak mert a példa linken lévő kódoknak futnia kellene, ha minden helyesen van bekötve, közös föld, mindegyik 3.3V stb.

Illetve a HC-05 képes Master/Slave üzemmódban futni. Remélem ez nem kavar be, de ha minden kötél szakad akkor ennek is utána néznék.

Az sem tiszta, hogy a Bluetooth serial baudrate mennyi. Alap, vagy fel van turbózva? Gondolom ezt a hibát nem vétetted mert az uno-val ment.

13. oldal Innen:

Bővebben: Link



HC-05



innen:
Bővebben: Link

Ezeknek meg kell egyeznie mindegyik hardveren. Egész pontosan a wemos-t kell belőni a hc-05 gyári értékeire.

Amúgy ha elég fordítási időben eldönteni hogy van-e lcd, akkor a libeket is tetszőlegesen csereberélheted, mert a #define makró pont ezt tudja.


Ez azt csinálja, hogy ha a USE_LCD 1-re van állítva, akkor a print() függvény helyére az lcd.print()-et helyettesíti be. Ha más van beállítva, akkor meg a serial.print()-et.
Ha csak annyi a feladat hogy fordítási helytő függően vagy az egyik vagy a másik libet használd, akkor ez teljesen jó megoldás lehet.

Ha a #define USE_LCD sort kirakod egy külső .h fájlba, akkor megteheted hogy a munkahelyi verzóban 1-et állítasz be, az otthoniban meg nullát. Maga az .ino forrásfájl lehet bájtra pontosan ugyanaz, a .h fájl határozza meg hogy hogyan forduljon le.

program.ino:


config.h:

Ezek jó ötletek, de ahol lcd.print van, ott van más is, mint pl.: set.lcdCursor, tehát nem elég csak a print cseréje.

A fentiek alapján remélhetőleg már azokat is meg tudja csinálni...

Ez sem nehéz probléma. Akkor legyen

és


Tehát ahol kell (lcd) pozícionál, ahol meg nem kell (serial) ott meg nem használja fel a plusz paramétereket. A fentiek csak fejből, de szerintem így mennie kellene. Lényeg hogy a #define makró tartalmát szolgai módon bemásolja a szövegbe, és csak azután fordítja a kódot. Lehet vele trükközni.

"Egész pontosan a wemos-t kell belőni a hc-05 gyári értékeire. " Ilyet még nem csináltam. Ezt hogyan kell?