Sziasztok! Az USART-tal kisérletezem. Pickit2 meg egy f887 között. Valamit biztosan elronthatok.. Addig jól megy a kommunikáció még a Pickit2 szoftverének a Send sorában maximum 3 byte áll, vagy nincsen semmilyen program csak az RCIF vizsgálata. Tehát szerintem valamelyik flag lehet a baj, de sem a FERR és sem az OERR törlése CREN visszaállítás nem hozza vissza a kommunikációt. Szóval ha egyszer kifut újraindítás nélkül ott is marad.

Sziasztok!
Van arra esély, hogy a PICkit2-vel felprogramozzak egy 16LF1824-et?
Csak mert evileg nem támogatja...

LInk

Itt van a bővített dat file. Másold be a pk2 könyvtárba, (írd felül) a másikat.

Köszi!
Ezt nem is néztem...

Szia!
Csomagok vételét máskép kell megírni: Megszakításos vétel és adás kezelés, két független gyűrűs fifo. A feldolgozó program a vételi fifo-t olvassa és az adásit írja. Ekkor a feldolgozás alatt beérkezett karaktereket a megszakírás beteszi a vételi fifo -ba és nem lesz (annyi) ráfutási hiba. A fifo -k méretét a táviratokhoz és a feldolgozási idő alatt beérkező karakterek számához kell méretezni.
Ha OERR vagy FERR volt, nem elég letiltani és visszaengedélyezni az UART -ot, az RCREG -et ki is kell olvasni.

Én csak egyelőre veszem amit a géppel küldök a pic-e. És nézem az RCIF-et aztán olvasom ha 1 az RCREGET. De ha ottvan ez a delay késleltetés akkor amit írtam 3 byte a teteje utána se kép se hang a restartig. Ha nincsen az időzítés akkor akármennyi bájtot küldhetek nem "fagy" be.

Sziasztok! Tudna nekem valaki ajánlani, esetleg linkelni 24bites BIN-BCD átalakító asm algoritmust? Üdv! Balage

Itt találsz ilyeneket.

Hűha, köszönöm!

Szia
CCs-ben van működő kódom, nem rég volt téma. Nekem hibátlanul működikEZ.

Üdvözletek!
Ismerkednék 2 pic (18f4620) közötti rx/tx kommunikációval. Lemartam egy próbapanelt ,de a nagy kapkodásban lemaradtak a kvarcok . A kérdésem az ,hogy a pic belső órajele elég pontos ehhez a kommunikációhoz, vagy inkább szenvedjem rájuk a kvarcot ?

Elég pontos hozzá.

Üdvözletem. Új vagyok itt de nem annyira kezdő. PIC-es mp3 lejátszót szeretnék csinálni, de olyat ami usb portról olvassa be a zenét, esetleg ogg-t vagy flac-ot is tudhatna akár.
Valaki tudna-e segíteni, hogy hogy induljak ki stb?

Szia!
PIC24F, dsPIC33F, PIC24E, dsPIC33E, PIC32MX kontroller, ami tudja az USB mastert is.

Van ilyen topik: MP3-lejátszó építése

Üdv!
Köszönöm!

Visszatérve a kérdésemhez és Hp41C válaszához. Azt kérdezném miért csak megszakítással jó a vétel? Most megszakításban megy így működik.

Szia!
Az előző csomag feldolgozás alatt beérkezik a következő csomag (eleje vagy a teljes csomag). Ha szét szeretnéd választani a soros kezelést a feldolgozástól, akkor megszakításos kezelés a legkézenfoghatóbb megoldás. Egy másik megoldás, hogy (karakter) időnként megnézed, hogy jött-e már karakter, vagy kell-e küldeni a következőt. Ezzel a módszerrel teletűzdeled a feldolgozás nem oda való utasításcsoportokkal, de eredményül egy kezelhetetlen, kusza rendszert kapsz, ahol kisebb módosítások hatására újra és újra előjönnek a soros vonali hibák (hiszen beszúrva vagy törölve utasításokat felborítottad az időzítéseket). Csak olyan kontrolleren használd, amiben nincs megszakítás.

Renben nagyjából értem. De ez azzal jár, hogy végérvényesn leáll a kommunikáció? Csak újraindítás után megy?

A feldolgozást az információnak nem illő helye a saját megszakítása gondolom. Pl ha egy 2x16 soros lcd-re akarok kiírni, mivel az lcd lassabb a kommunikációnál, akkor minden egyes karakter mentsek el külön változóba?

Még azt szeretném kérdezni, hogy a Pickit2 Uart-tool-jában ha Ascii ben beírom hogy "hy bryan" és úgy küldöm ki akkor hibásan küld el 1-2 karaktert. Ha ugyanaz beírva átkapcsolom Hex-re akkor rendesen el küldi a kiírást. ?

A szokásos eljárás az, hogy a beérkező karakter egy gyűrűtárba kerül (valójában egy tömb, amelynek a mutatója túlcsorduláskor visszaugrik az elejére). Onnan egy getc függvény veszi ki, célszerűen a főprogramból meghívva, amikor szükség van rá. Ha a gyűrűtár betelése valószínűsíthető (túl sok adat jön túl gyorsan), akkor valamilyen adatfolyam-vezérlést is használni kell (RTS/CTS vagy XON/XOFF).

Miért állna meg?

Ha van egy késleltetés a feldolgozásban, legyen az megszakítás is. Akkor nem működik a Pickit2 és a pic kommunikációja. Az lehet amit mondtál, hogy folyamatos félreértelmezésbe kerül.

Szia!
Interrupt rutinban SOHA nem várakozunk. De ezt más 10^6 -szor leírtuk ide is. Ez a 6 regiszter nem egy fifo. Olvass utána... Az RCREG -et nem szabad gondolkozás nélkül kiolvasni, mert lépteti az uart vételi fifo -ját (ha csak 2 elemű, akor is fifo) és elveszted az ehhez a karakterhez tartozó RCSTA értéket. Itt a fórumban keress rá az RCSTA szóra. Azt figyelembe vetted, hogy a 19. sor nem ugyan azt az adatot fogja használni, mint a 4. .. 11. sorok?

Nem szoktam megszakításban várakozni, csak odatettem, a példa kedvéért. Ez csak egy nyers próba, ahol nem törődöm az RCSTA-val, de persze ha alakítom ez nem így lesz. Az meg persze egyértelmű hogy nem azt használja, az csak arra van hogy ha 0xff et küldök előröl kezdi a kiírást, ezt használtam, hogy tudja a pic merre áll most. Az egész csak arra szolgált, hogy bemutassam hogy ha van egy delay vagy akár egy hosszabb programrész akkor teljesen "megáll" a kommunikációm. És ami érdekelne, hogy ha ilyen van akkor mi ami "beáll" és mit kellene tenni az újraindításához!?

Kezdjül elölről:
- Kötelező kiolvasni az RCSTA -t, minden adat kiolvasása előtt egyszer. A teszteket egy másolaton kell végezni. El kell dönteni, hogy van-e ráfutási vagy keretezési hiba.
- Ha ráfutási vagy keretezési hiba van, el kell tiltani a vevőt, ki kell olvasni az RCREG -et, engedélyezni kell a vevőt.
- Ha nincs ilyen hiba, ki kell olvasni az RCREG -et, de csak egyszer. A kiolvasott karaktert be kell írni a vételi fifo -ba. Nem szabad a megszakításban feldolgozni.
- Kell írni egy fifo olvasó eljárást, ami jelzi, hogy sikeres az olvasás és visszaadja a vételi fifo -ból kiolvasott adatot, ill. jelzi, hogy nincs adat benne. Ezt hivogatja a főprogram. Ha van adat, akkor értelmezi, feldolgozza. Neki van ideje... Az értelmezéshez kell valami protokoll - táviratformátum...
- Ha válaszolni is kell az uart adójával:
- Kell írni egy eljárást, ami az adó fifo -ba írja a válasz karaktereit és engedélyezi az adási megszakítás kérést.
- Az adót kiszolgáló megszakítási rutinrészletben meg kell nézni van-e még küldendő adat. Ha nincs tiltani kell az adási megszakítás kérést. Ha van, ki kell olvasni az adatot az adási fifo -ból és be kell írni a TXREG -be.
Ha a fentieket betartod, nem fog "leállni". Két eset állhat elő: Veszi hiba nélkül az egész táviratot és végrehajtja, válaszol vagy hibás karakterre fut, a feldolgozó észreveszi, hogy hiba történt és megkeresi a következő távirat elejét (az addig kiolvasott adatot eldobálja).
Nincs királyi út, ha lépéseket hagysz ki, valahol hibázni fog.

Sajnos ezt a nyelvet annyira nem ismerem, de azért kösz a segítséget. Idő közben lassan rátalálok a helyes kódra, hamarosan működni fog.

Köszi. Ezt elemzem és eszerint írom meg a programot. A fifo egy általam kreált regiszter?

A FIFO egy olyan tároló, amiből olyan sorrendben tudod kivenni a belerakott elemeket, mint ahogy beleraktad (ellentétben például a veremmel). Ebben az esetben egy tömb lehet a tároló. Javaslom a C nyelv tömbkezelésének, átnézését.