Magyarországon sehol nem találtam. Elég új dolog, Kínai fejlesztés. Vagy a gyártó oldalán vagy Ebay -ről beszerezhető.
Az FTDI cégtől Ft80x es széria van itthon is de sokkal drágábbak ennél.

OK, köszönöm az infót !

Ez amit generál a fájlból a bin2hex és a microbrn.exe-nek ez nem tetszik próbáltam más hex-et azt simán beégeti

Amit beéget a microbrn normálisan, ott is 0x20 hosszú sorok vannak? Nézz bele abba a hex-be is. Én jellemzően csak 0x10-es hosszúsággal találkozom az MC kimeneteken. Ezt a hex-et milyen bin2hex tool csinálta?

Ha mást nem, át lehet konvertálni azt a hex állományt, de pepecselni kell majd vele külön programot írni rá, hogy szétszedni a sort kettőbe, és cím + ellenőrző érték módosítással egy másik file-ba úgy írni bele.

Edit:
Hmm ez a kérdés inkább @Hp41C-nek szól, lehet, neki kellett volna inkább címeznem. Furcsak az a bin2hex tool, amit fellinkelt. Honnét van az?

16f1824-es PIC esetén az 500kHz-es belső oszci akár ±5%-os eltéréssel is dolgozhat a hőmérsékelt függvényében. Az EUSART BRG16 beállításának engedélyezésével a 2400-as baud 1% alatti hibával működik a fent említett eltérés esetén. Ha így sem működik neked, akkor ott valami más probléma lesz.

SYNC = False
BRGH = True
BRG16 = True
SPBRG = 48

Én 16F690 -el belső oszcillátorral meg... tam. Az UART mindig szétesett. Véletlen szerűen vagy vitt át adatot vagy nem. (9600bps...)

Szóval akkor elvileg 16bites brg-vel gond nélkül kell menjen különféle hőmérsékleteknél is? Vagy mi van akkor , ha a Mester egyik pwm kimenetét használnám a slave-en órajelnek? Az nem segít?

Erről a HMI-ről érdemes lenne egy új fórum témát nyitni!


Egy kérdés fel is merült bennem PIC-es felhasználásával kapcsolatban: ha a PIC-nek egy soros portja van, és azon már lóg mondjuk egy ESP8266 modul, akkor hogyan lehet rákötni a HMI-t?

Igazad van!

Nyitottam: Nextion HMI topik

Azért, hogy a PIC -es kérdésre válaszoljak.
Vagy másik típust választassz amiben legalább 2 UART van, vagy ha belefér akkor szoftveres uart.

Hogy egyes programok milyen válogatósak.... Az eszem megáll. A PICkit2 simán beolvassa a 32 byte -os verziót is. Ha netán ez meg túl hosszú lenne, a FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF adatot tartalmazó sorok törölhetők.

Igen mennie kell. Ha behúzol még egy vezetéket órajelnek, akkor inkább használd valamelyik szinkron sorosadatátvitelt.

Annyit lehet tenni, hogy figyeljük, mikor keletkezik átviteli hiba a soros vonalon. Ez megadhat egy karakterszámot, aminél rövidebb bokkokra bonjuk az átvitelt. A START bit újraszinkronizálja az UARTokat.
Másfajta megoldás lehet az aszinkron mód helyett szinkron üzemmód használata, amikor az órajelet a master adja, a slave pedig fogadja. Ilyenkor, ha induktív, kapacitív tényezők nem nagyon torzítják a jelet, nagyobb átviteli sebességet is el lehet érni két kontroller között.

Nekiálltam Spi-vel. Ha elakadok (valószínű), jelentkezem...Addig is köszönet!

A linkre az jön be, hogy a téma nem található !?

Törölték a topikot. Ezekszerint itt megy tovább...

@Hp41C nekem linkelt egy választ a rövidített-soros .hex file-al, töltsd le azt a verziót is, és tájékoztass bennünket róla, mit jelez róla a microburner.

Ne engem szidj, én is pk2/3-at használok

A linkeddel lehet valami, mert a topik él és virul...
Bővebben: Link
Pontosabban... valami zavar van az erőben. Ha a fórum elejéről keresem, akkor ott van, a Figyelőbe berakható, de ha [Link]-et csinálunk róla, akkor eltűnik.

A szerkesztők törölték a topikot! Amit létre hoztam a Nextion TFT -nek.
Pedig az nem ide a PIC -es topikba tartozik. De ha szerintük igen akkor itt írunk róla.

Itt valami félreértés lehet. Nem anyáztál, vagy valami politikai színezetű megjegyzést tettél a topiknyitóban?
Nem hiszem, hogy kínai elvársaink saját fejlesztésű termékcsaládja embargós lenne.

Csak annyit írtam. hogy" Akkor itt folytathatjuk a Nextion HMI témát".
Erre valaki írt egy olyan választ, hogy nem ilyen módon kéne megnyitni egy topikot. Pár óra mulva kaptam a rendszer üzenetet miszerint a szerkesztők törölték a topikot.

Most találtam rá, másnak engedték az uj topikot létre hozni ITT megtaláljátok.

Bővebben: Link Valószínűsítem, hogy azért, mert a moderátor nem értékelte eléggé, hogy hamar be akartad fejezni az offolást ebben a topikban.

Valószínűleg azért törölték, mert semmi érdemi infót/linket nem közöltél arról, hogy miről is szólna a téma, így aki nem innen tévedt oda, az csak a "nagy fehér folttal" találkozhatott.

Sziasztok,
az nem úgy van, hogy a soros átvitel minden start bit elején újraszinkronizálja magát? Szóval sima időzítési gond már egy byte-on belül is problémát okoz, vagy elvben sohasem? De semmiképpen nem gyűlik?

A soros protokolban az adat a start bittel kezdődik, van ott egy lefutó él, és igen, ahhoz szinkronizálnak a soros vételi elektronikák, plussz a saját órajelükhöz utána.

A belső órajel jellemzően nem igazodik a bit idő pontos frekvenciájához (nagyon ritka esetben képes tökéletesen igazodni), így a start bit után folyamatosan "elcsúszik" a bit szinkron.

Amennyire lehet, beállítják a mintavételi időpontot bit közép időre, ami az elején még viszonylag pontosan ott lesz. Az utolsó bit időre viszont már akkora tud lenni a hiba, hogy közelíti a negyed bit időt, és kvázi nem képes utána több bitet érdemben pontosan mintavételezni. Csakhogy addigra már nem is kell neki, mert addigra már a stop bitet találja ott, és a vételi állapotgép újra a start bit szinkront várja, ami majd megint helyrebillenti az időzítést. És az megy minden egyes byte időben újra meg újra.

Sőt, mindaz nem csak vételnél, de adásnál is, azért nem érheti el a hiba a negyed bit időt sem az utolsó bitnyi időzítésben sem, mert az a hiba duplán jelenik majd meg: az adó is meg a vevő is tévesztenek.

Némelyik pic adatlapon a soros port szekcióban találsz táblázatot olyan érték számításokkal, mint % hiba bit időnként. Na az úgy értendő, hogy start + 8 adat bit, az összesen 9 (hiba *9), és mindazt duplán számold, mert adó és vevő is tévesztenek (hiba *18). Valójában a stop bit már nem fog sokat zavarni, elég csak az utolsó értékes bitig számolni (hiba *16), de ugye ráhagyásnak az a biztos, ha maradsz a nagyobb számoknál (hiba *18). Ha a hiba úgy végül el tudta érni az 50%-ot, akkor a bitközépidő mintavételezésed már átcsúszott a végén bit középről a következő bit határára, és a soros portod nem lesz képes hibamentesen kommunikálni.

Oké, ez nem lett éppen rövid, de remélem, a lényeget sikerült leírnom.

A soros átvitelnél nem a szinkronizáció szokott lenni a baj, hanem a "gyári" függvények. Ugyanis ezek a függvények megvárják (100 % cpu idő elkötésével) a karakter érkezését vagy elküldését.
Sokkab jobb megoldás, ha egy-egy körforgó buffert hozink létre az adáshoz és a vételhez is, melyek mérete meghaladja az táküldeni kívált táviratok hosszát. A vevő megszakítást kiszoplgáló rész csak kiolvassa a RXSTA regisztert, lekezeli a hibát, kiolvassa a RCREG -et és beírja a tárba, jelzi, hogy egyel több várakozó karakter van benne. Az adás megszkítás kiszolálója megnézi, hogy van-e még küldeni való adat. Ha van kivaszi a tárból és elküldi a TXREG -be, ha nincs letiltja a TX megszakítás kérést.
A többi a főprogram dolga. Így nincs akkora várakozás, hogy lekéssük a vételt.

Szia!

Meg szeretném kérdezni, melyik adatkommunikációról van szó? Kezdő vagyok ezen a téren, de én úgy tudtam, hogy csak az 1-wire idő alapú.
Ráadásul, bár mindenki arra hívta fel a figyelmemet, hogy nagyon pontos időzítésekre van szükség, én egyáltalán nem ezt tapasztaltam. Sőt, számomra úgy tűnik, hogy az 1-wire bitenként szinkronizál.
Ez volt az első rutinom, amivel a DS1821-es hőszenzort kezeltem:

Kísérletképpen elállítgattam az időzítéseket. Ráadásul még csak nem is szinkronban, hanem eléggé össze-vissza. Itt látható.

Zökkenőmentesen működött tovább. Pedig némely időzítést több mint 50%-al állítottam el.
De mint írtam, kezdő vagyok ezen a téren, és a csapdák elkerülése végett szeretném tudni, melyek még az idő alapú kommunikációk.
Köszönöm.

Az aszinkron soros kommunikáció (UART) is időalapú. Bár half-duplex módban az is 1-wire...

Ez hány vezetékes kommunikáció, és PIC-ek esetében hol használatos?