Sziasztok!

Egy anomália megfejtésében kérem a segítségeteket.
Számítógépre szeretnék adatokat küldeni egyszerű terminál felületre.
Megírtam egy tesztprogramot, de részleges a működése.
Uarton adok-veszek egy CH340-esen keresztül.
Két féle terminál programmal is próbálkoztam, az eredmény mindig ugyan az.
Az OK parancsot küldöm, amire a válasz az lenne, hogy "ITT VAGYOK"
Helyette ezt kapom "ITVGOK"
Mellékelem a programot:

Az biztos hiba, hogy sehol nem törlöd a megszakítás jelzés bitet (TXIF, RXIF). Azt minden TXREG írás előtt, ill. RCREG olvasás előtt törölni kellene.

Ne a txif-et nézd, hanem a megfelelő soros vez. regiszter bitet. Meg nézd meg az erratát, mert pic24valamiben futottam bele, hogy dokumentáltan rossz az egyik vezérlőbit
UTXBF /* wait if the buffer is full, not working correctly!!!!*/
TRMT jó
https://www.mouser.com/datasheet/2/268/80522c-19131.pdf
Module: UART (TX Buffer)
If the transmit buffer is filled sequentially with
four characters, the characters may not be
transmitted in the correct order.
Work around
Do not completely fill the buffer before transmitting data; send three characters or less at a
time.
Affected Silicon Revisions
5. Module: UART (Transmit)
The Transmit Buffer Full flag, UTXBF
(UxSTA<9>), may become cleared before data
starts moving out of the full buffer. If the flag is
used to determine when data can be written to
the buffer, new data may not be accepted and
data may not be transmitted.
Work around
Poll the Transmit Buffer Empty flag (TRMT,
UxSTA<8>) to determine when the transmit
buffer is empty and can be written to.

Próbáltam úgy is. Semmi változás.
Az adatlap szerint amúgy a jelzőbitek maguktól törlődnek. Az RXIF akkor, ha új adatot írok bele, a TXIF pedig akkor, amikor kiolvasom.
Végül úgy sikerült eredményt elérnem, hogy kiszámoltam az átviteli időt, arra még rátettem egy picit, és két adás közt ennyit késleltetek.
Csakhogy ez nem a megoldása, hanem a megkerülése a problémának. Így nem vagyok előrébb, mintha szoftveresen csinálnám meg az uartot.

Itt én más sorrendet látok a teszt és a regiszterbe írás, meg a goto $-1
http://teachers.cm.ihu.gr/kalomiros/Mtptx/Lectures/Lecture_Embedded..._4.pdf
inkább cimkézd meg a goto-t akkor nem téved


De én továbbra sem a txif-et használnám

Bocsánat, az elfelejtettem leírni, hogy a kérdéses PIC 18-as szériájú, azért kell 2-őt visszalépni a GOTO-val. Amúgy tényleg jó ötlet külön rutinba tenni.

A TXIF törlése két utasítás végrehajtásnyi idővel késik a beíráshoz képest. A PIC UART-jának van egy 1 byte-os puffere. Ha beírtad az I-t, enegedi beírni az első T -t is, a TXIF nem változik. A következő T beírásáig nem törlődik a TXIF.
Bufferelt vételt és adést javaslok, ezzel az adás alatt beérkező adatokat is fel lehet dolgozni.

Én ugyanígy TXIF-re várva küldtem adatot, eddig mindig működött, szerintem nem ott van a hiba:



Milyen PIC, milyen órajelet használsz és hogyan néz ki az inicializálás?
Szerintem azért nem kapod meg minden második byteot, mert a PC UART framing error miatt eldobja. Ugyanúgy neked is le kell majd kezelned a végleges programban fogadáskor ezeket az eseteket:

A "I" közvetlen bekerül a Transmit Shift Register-be, amiből az adás megy, a "T" meg a TXREG-be ami az 1 byte buffer, de utánna már várni kell a második "T" beirása előtt, ez normális.
A TXIF flag akkor lesz beállítva amikor a TXREG átkerül a TSR-be, ekkor még megy az adás, de van bőven idő betölteni a következő byte-ot a TXREG-be.

Amit irsz viszont igaz:


Szóval nálam azért működik, mert nálam van pluszban call + return

Szia!
Amíg nem írod le a PIC pontos típusát, nem biztos hogy tudunk érdemben segíteni.
Viszont 2 hatalmas hibát látok.
Ez életveszélyes, lehetőleg soha ne használj ilyet:


És ami szerintem magát a hibát okozza, hogy nem jó flag-et nézel. A TXIF erre nem jó. Én a TXSTA, TRMT bitét javaslom.
Mivel a küldés részig eljut, ezért a fogadásnál nem akad el.

A küldés részt alakítsd át pl. erre:


Ez saját kód, nálam már évek óta bevált.

Habár az időzítés most megoldotta, de a későbbiekben jobb módszer kell, mindenképp ki fogom próbálni.
Mindenkinek köszönöm a segítséget.

A TRMT akkor vált, amikor a shift regiszter (TSR) is kiürült, ez jó arra, hogy például RS485-nél az adatirányt visszaváltsd, és a példádban is jó, amikor nem csinál mást a kontroller, de ha a TXIF helyett használod, akkor pont az 1 byteos bufferelést hagyod ki, ez elég mezítlábas megoldás.

Ha a TXIF-et használod, akkor van 1 byte kiküldésének megfelelő időd, hogy újra feltöltsd a TXREG-et. A delux megoldás pedig, ha ezt valójában egy IT-ből egy ring bufferből teszed. A küldés ekkor annyi, hogy feltöltöd a ring buffered és elindítod az adást, az IT pedig mindig feltölti a TXREG-et, amikor az kiürül. A főprogram meg bármi mást csinálhat az egész adás alatt.

Igen, ez így van.
De ehhez kell megszakításkezelés is.
Szerintem a kérdező által bemásolt kódban a TXIF flag pollingozása azért nem jó, mert ott a kód még azelőtt betölti a TXREG-be a kiküldendő adatot, hogy az előző átkerült volna a TSR-be.
Szóval "ráfutás" történt.

Sziasztok!

Egy anomália megfejtésében kérném a segítségeteket.
Az itt bemutatott PIC boardom számára írtam egy bővítményt a bootloader alá. Ez a bootloaderrel együtt kerül feltöltésre és a programmemória legvégén, közvetlen a bootloader előtt kapott helyet.
Tartozik hozzá egy makro gyűjtemény, amit a készülő programba lehet behívni. Nélküle nem is lehet meghívni. 24 btes előjeles számok matematikai műveleteit végzi. Kivonás, összeadás, szorzás, osztás, valamint linearizálás. A mellékelt képek tanúsága szerint szimulátorban futtatva minden számítás végeredménye jó. Ellenben a PIC a linearizáció végeredményét elhibázza.
Több PIC-re is feltöltöttem, mind ugyanazt a hibát véti.
Mi lehet ennek az oka?

Több külömböző variációban is lefuttattam mind szimulátorban, mind PIC-en a linearizációt.
Változtattam a tartomány értékeket, a bejövő értéket. Minden tesztben a szimulátor helyes eredményt adott, a PIC viszont konzekvensen 1-el kevesebet írt a H byte-ba.
Ezt nem úgy teszi, hogy a 0-ás bit mindíg 0, ami utalhatna ramhibára, hanem akár 6 helyére 5-öt ír. Azaz a H byteból valamiért mindíg levon 1-et.

Esetleg ha a LIN macro belsejét is láthatnánk ...

Magával a makróval nem sokra lehet rálátni, az egész pedig elég hosszú, de feltöltöm.

Ez pedig maga a linearizáció:

A linearizació 153-ban van egy elírás szerintem.
a CBLOCK vagy RES nem működik ebben a fordítóban?
Igy elég átláthatatlan a kód, hogy minden címmel szerepel benne.

Sas szemed van, hogy ezt így kiszúrtad, de sajnos nem oldotta meg a problémát.
Egyébként működik a CBLOCK, és magam sem értem, hogy miért így csináltam. Sokat nehezítettem saját magamnak.

A linearizació 40-41 sorok nem kellenek, mert később is kinullázod, addig meg nincs használva.
43 sem kell, mert azt sem használod.
A gyanus még a 195 (GOTO $+14), ez hova ugrik?

Átneveztem minden címet, hogy érthetőbb legyen.

Igazad van megint. A 40-41-et már azóta én is észrevettem és töröltem, a 43. sor pedig egy hibajelző bit lenne 0-val történő osztás esetén a normál osztó rutinban, de itt nincs szerepe, így a vizsgálatot kihagytam. Tehát ez sem kell.
A 0X1FF,0, vagy ahogy átnevezted FLAGS,0 egy vezérlőbit. Mivel előjeles szám, pontosabban negatív szám nem osztható vagy szorozható, ezért 3 vizsgálata van. A szorzat 2 eleme, valamint az osztó van vizsgálva. Ahol kell, komplementálva van. minden komplementálás fordít egyet a jelzőbiten. A jelző bit a legelején törölve van. Mivel mínusz*mínusz az plusz, illetve mínusz/mínusz is plusz, ha nincs fordítva, vagy ha kétszer van fordítva, akkor a végén lévő komplementálást átugorja. A te változatodban a 256. sorban lévő NOP-ra ugrik.
Ilyen kiszámított ugrásokat gyakran szoktam használni. Különösen makróknál kedvelem, mivel ott macerás lokális ugrási címeket létrehozni.

Egyébként eszembe jutott, miért nincsenek nevesítve a változók.
Mivel ez a program a bootloader részét képezi, viszont a matematikai makrók nem, így nem fordította le a fordító amíg nevesítve volt.

a FLAGS,0-ra rájöttem miért van. A $+14-gyel viszont nem tudok kibékülni. A 14 itt 14 wordot jelent vagy 14 byte-ot? Akárhogy számolom nekem nem a NOP lesz a vége, de inkább használj labelt.
A CBLOCK nem foglal memóriát csak cimkéket generál neked, azt szerintem tudnád itt is használni.
Azt kellene megnézni, hogy a szorzás után a RESULT részeredmény még egyezik-e.

Kedves majkimester!
Te egy zseni vagy, én meg egy ökör.
Még el is magyarázom neked, hogy mi ez, és még akkor sem veszem észre, hogy a 0x kimaradt belőle.
Kijavítottam, és helyreállt a rend.
Most már csak azt mondja meg nekem valaki, hogy a fordító miért nem dobta ez ki mint hibát, és a hiba ellenére miért adott jó értéket a szimulátorban?
Nagyon köszönöm a segítségedet!

Szuper. Na ezért kell mindig label-t használni. Én sosem használtam a $ offsetes megadást. 18-as családnál meg vannak két wordos utasítások is, ott mégjobban figyelni kell rá. Nálam a macro-n belül sem volt soha probléma a label, csak kell egy local-t csinálni, igaz csak a régi MPLAB-ot használtam. Az újban mostmár új fordító van, azzal nem tudom mi a helyzet:

Az is lehet, hogy a RADIX a szimulátorban HEX és a fordítóban meg DEC, (ugye ez határozza meg hogy minek vegye a számokat amiknek nincs megjelölve a formátuma. A decimálist is lehet jelölni, én direkt szoktam is kódban: D'14' és így nem lehet eltéveszteni)

Ponttal is lehet jelölni a decimálist, én erre szoktam át, mert egyszerűbb.
Tehát helyett

Nyertél!
A bootloaderben az alapértelmezett számrendszer a decimális. A matematikai részeket is ez tartalmazza.
Ez ugyebár fel lett töltve a PIC-re, ezután már a tesztprogramot a bootloader töltötte be.
Viszont a szimulátorban össze kellett vonjam a két programot, hogy szimulálni lehessen.
Itt pedig már a tesztprogram beállításai működtek, ahol az alapértelmezett számrendszer a HEX volt.
Ezért működött jól.
Ismét tanultam valamit. Máskor majd jobban figyelek.

Segítséget kérek! Nem sikerült az PORTA4-es pint kimenetnek konfigurálnom. MPLABX-et használok, PIC12F1572-el. (MPLABX simulátor-hiba lenne? PWM valós kimenet kis hibával megfelel a számítottnak, a "Logikai Analizátor" szerint ötször nagyobb!)
( PIN1572.PNG-ben: RA4 Din T1G0 van kiemelve)

Szia!

Nem egészen értem ezt a beállítást.

Először mindent bemenetre állítassz, majd valami ravasz betűjelzéssel akarod kimenetté tenni.
Erre való utalást, hogy a TRISA regisztert címezni lehetne én nem találtam az adatlapon. Ha a fordító elfogadja, még indig nem biztos, hogy azt is fordít, amit te szeretnél.
Sokkal tisztább ezt beírni: BCF TRISA,4
Akkor biztos, hogy kimenet lesz belőle.

Szia!
A TRISA beállítást bemenetre állítás már csak azért volt, mert így tudtam figyelni a beállításokat.
A beállítások korrektek, de az PORTA4-et nem sikerült kimenetnek állítani! Ugyanezzel a módszerrel másik portot sikerült kimenetnek beállítani, és vezérelni. USART TX továbbra sem megy, kénytelen leszek szoftveres adatkivitelt készíteni. (bőven van idő az adatküldésre..)
megj.: "FSKbe" és a többi definiálva van az elején