Nem tudjátok? a WEB áruházban az árak nettó vagy bruttó árak? Sehol nem találok erre utalás.

Ja úgy. Nekem ez jött le:

Meg ez. Te beléptél?

Sikerült megoldani a 12F629 OSCCAL problémám. Sok-sok próbálkozás után se volt hajlandó a megfelelő helyre (0x03FF címre) bekerülni a megfelelő kalibrációs érték. Hiába írtam be kézzel, hiába próbáltam automatán generáltatni, mindig kitörlődött onnan az érték.
A megoldást végül a PICKit2 program automata regenerációja hozta, DE! Végül csak úgy volt hajlandó beíródni a retlw utasítás az utolsó programterület részbe, ha a kódvédelmet (Enable Code Protect, avagy ctrl+p) is bekapcsoltam.
Azóta teljesen jól felprogramozódik a PIC, minden gond nélkül (igaz azt a kerülő megoldást alkalmazom, hogy MPLAB-bal legeneráltatom a hexa kódot, és a PICKit2 program automata beégetés funkcióját használom).

Sziasztok!
Segítséget szeretnék kérni: Egy 12F617-es PIC-et szeretnék felprogramozni, de sem a PICKit2, sem az MPLAB nem ismeri. Mivel lehetne felprogramozni?

watt kolléga programjával. WPB_F18_F16_F12_v1.32b

Szia!

Töltsd le a Pk2DeviceFile.1.62.14 -et és tedd be a PICKit2 telepítési könyvtárába. Indítsd újra a programot és láss csodát: A 16F617 -et fogja kezelni.

Hálásan köszönöm!
Pjg! Neked is köszönöm szépen a segítséget!

Frissíts MpLab -ot is, a 8.88 ismeri és PICkit2 -vel alóla is tudod programozni.

Ezt külön köszönöm! (Sajnos, amit megtaláltam, az ennél régebbi verzió volt.)

Hello!
Hogyan tudok két PIC között kommunikálni? Konkrétan az lenne a helyzet, hogy az egyik PIC számol, a másik PIC pedig a LEDeket kezeli. Ehhez át kellene vinni azt az adatot, hogy éppen melyik LEDeknek kell világítani, villogni, stb, és mindezt lehetőleg kevés I/O port használatával, hogy maradjon elég láb a LEDeknek. Keresgéltem, de nem találtam ilyesmit.

I2C, ha nincsenek túl messze egymástól.

Sziasztok ha már erröl van szó, milyen meszire lehet szétrakni két pic-et I2C komunikációval, persze stabilan ja és milyen vezeték kell hozzá?

Szia!

Ha csak ketten vannak, akkor jobb az uart RS232 szintkonverterrel, ha többen, akkor RS485 -tel. Ekkor többször 10m is lehet köztük. Ha nagy a távolság és máshonnan kapják a tápot, akkor optikai leválasztás is kellhet.

Azt olvastam, hogy az 1Wire átvitellel akár 300m is lehet a távolság.

Kicsit későn, de még engedjétek meg, hogy visszatérrjek az USART FIFO eredeti kérdésemre.
Hp41C nagyon részletes magyarázata érthető, de kis kiegészítésre szorul nálam mikor ezt írja:

vagy egy másik rövidre fogott magyarázat:

Az az eset érdekes, mikor van még kiküldendő adat a FIFO ban. Ekkor adási megszakítási engedély mellett belekerül a TXREG be az adat.
Eddig ok.
Viszont az idődiagrammok szerint meglehetősen hamar (!) akár egy utasításciklusssal átkerül a TSR be (szimulátorral azért többnek tűnik, de nem garantált, hogy az pontos...), ezáltal felszabadul a TXREG, ami TXIF beállását hozza maga után.
A gondom az aHp41C magyarázatával, hogy mi biztosítja, hogy valaha is kikerülünk az adási megszakításból, mikor még lenne kiküldendő a FIFO ban és nem az utolsó byteot adjuk, mikor majd TXIE = 0 ra állítjuk?
Csupán azt használjuk ki, hogy TXREG kiürülését nem azonnal követi TXIF beállása, és ha elég rövid a megszakítási rutin már ki és lépünk belőle, majd vissza ha eljött az idő a következő adás indításához?

... az első karakter, s azután hosszú néma csönd, amíg a karakter ki nem shiftelődött a TX lábon.

Ha a többi karaktert is olyen gyorsan lehetne pakolgatni, ahogy gondoltad, akkor nem kellene szoftveres bufferelésel, meg interrupttal bíbelődni!

Köszi de igazából a távolság a kérdés illetve hogy milyen vezeték (UTP vagy sima riasztós esetleg lisy).

Na ez az amit nem értek, de nagyon!
A TXIF már akkor 1 lesz, mikor a Start bit adása megkezdődik!
Mivel a program Tcy ja jelentősen kisebb mint a pl. 1/9600 (bit/s) ezért még a Start bit ki sem lép teljesen, máris magasba megy a TXIF! Tehát a megszakításrutinban lévő néhány programsor gyakorlatilag biztos, hogy lefut a Stop bit előtt. A retfie -nél meg ott állunk egy régóta (!!!) magasan álló TXIF el, ami ismételt megszakítást okoz! (nem töröltök az engedélyezést, mert van még kiküldendő karakter)
Ha a TRMT jelzőbit okozna megszakítást az jó lenne, mert az kivárja, hogy ténylegesen kilépjen a soros adat.
Sajnos azt pollingolni nem szerencsés, mert rendkívül lelassítja a processzort, sok adat esetében gyakorlatilag csigává téve azt.
De Ti nem is erről tesztek említést, meg a TRMT nem is okoz megszakítást.

Pont azt próbáltam elmagyarázni, hogy ez csak az első karakternél van így, s ha rátöltöd a második karaktert (mert visszaugrottunk a megszakításba, ahogy elmondtad), akkor utána már nem lesz bebillenve egyhamar a TXIF, majd csak ha az első karakter kiküldése befejeződött.

S az újabb megszakításkor, ha betöltöd a harmadik karaktert, megint nem lesz megszakítás-kérés addig, amíg a második karakter küldése be nem fejeződik.

Hú így már pontosan értem!
Erre gondoltam már én is, de mivel nem említettétek nem is feltételztem az ilyen működést, mivel eléggé egyszerűsítve volt fogalmazva. Pl:

Ez tehát igaz is, csak közben meghívja saját magát mégegyszer az int kiszolgáló rutin az első körben a harver FIFO t feltöltenő... Aztán már minden megy tényleg egyszerűen...
Persze gyakorlatikag a Back To Back szerit megy.

Nagyobb tavolsagra (4000 lab, 1300 m) UART es RS422 (duplex), RS485 (simplex ketiranyu) adatatvitel ajanlott mindenfelekeppen. SPI, I2C nem alkalmas csak panelon beluli kapcsolatra (max 40-50 cm). RS485 akar 115 kBaud sebessegre is kepes a halozat megfelelo kialakitasaval. Alkalmazhato olcso UTP kabel, 120 ohmos lezarassal a vonal ket vegen. RS485 reference. Persze lehet alkalmazni CAN, vagy mas atvitelt is, de sokkal bonyolultabb es dragabb, valamint specialis HW-t kell alkalmazni.

Szia!

Amint írtam, az TXIF azonnal 1 lesz, ha a TXREG írható már. Ebből adódik, hogy hosszabb szünetet követően az első karakter beírása után szinte azonnal TXIF megint 1 lesz, hiszen a TXREG ből az adat átkerült a léptető regiszterbe. Ha az imént beírt karakter nem az utolsó volt (TXIE = 1 maradt), akkor kilépés után ismét a megszakítás kezelés fut le, a következő karaktert is beírja a TXREG -be. Ezután következik a jelentősebb ideig tartó várakozás - az első karakter adásának végéig. Aztán a folyanat ismétlődik, ameddig el nem küldtük az utolsó adatot is, ekkor TXIE 0 -ra állítjuk és nem lesz több megszakítás. Ha a főprogram újabb adatokat ír az adási fifo -ba, a móka újrakezdődik. Nézd meg szimulátorban.

A 16 bites PIC-eknél az UART hardver FIFO-ja 4 mélységű, ott pl. az első 4 byte simán egyből a TXREG-be rakható. Én egyébként ezt így csináltam meg: van ugye két függvényünk. Az egyik ami fogadja a küldendő byte-okat (nevezzük most SendByte-nak), a másik ami az UART TXIF (nevezzük most TxIrq-nak) megszakítása esetén fog lefutni.
SendByte:
- Ha a szoftver FIFO üres és TXIF==1 akkor TXREG = küldendő adat
- egyébként a küldendő adatot betolom a szoftver FIFO-ba és TXIE-t 1-be állítom.
TxIrq:
- Ha TXIE == 1 és TXIF == 1 akkor kiveszek egy byte-ot a szoftver FIFO-ból
- ha van benne adat, azt a TXREG-be rakom.
- ha már üres -> TXIE = 0

Nem kell megnézni, értem, csak nem gondoltam erre, mert nem írtátok ezt a részletet.
Egyébként már írtam egy TX FIFO programot, ami jól működik.
Köszönet érte mindkettőtöknek!
A 16 bites válaszért külön köszi, megpróbálom szimulátorban!
Már néztem miként lehet velük dolgozni.

Hát ezzel a PIC közötti kommunikációval nagyon befürödtem. Azt hittem ez lényegesen egyszerűbb. Keresgélek a neten, de egyenlőre tök homály a dolog. Ha jól értem ezekhez spec hardver támogatás is kell a PICbe, vagyis nem mindegyik PIC használhatja akármelyiket.
Az én elképzelésem az volt, hogy a két PIC 1-1 lábát összekötöm. Az egyik PIC elküldi a lábán az "11011" jelsort, amit a másik tárol, értelmez, és bekapcsolja a 3-as ledet. És így tovább.
Vagy ez teljesen hülyeség?
(Jól gondolom, hogy ez hasonló lenne mint a 1-wire? Kevés adatot, egyszerűen, egy vezetéken továbbítani? Ezt nem említette senki. Ez nem jó, vagy csak nem használjátok...?)
Amiket említettetek (köszönöm szépen) nekem nagyon bonyolultnak tűnnek, ahhoz amit szeretnék csinálni. (konkrétan: egy PIC dolgozik, de kevés a lába a LEDek kezelésére. Ezért lenne egy másik PIC, ami egy vezetéken kapná, hogy mikor melyiket kell bekapcsolni, az összes többi lábára lehetne LEDet kötni)

Ehhez kapcsolódóan: Azt hogyan tudom megtenni, hogy az lábon beérkező inputot "elraktározza" folyamatosan egy változóba (amíg van hely benne. Gondolom ha már nincs akkor jönnének a memoria chipek, ami megint a bonyolult kommunikációs protokollokhoz vezet...)? Arra gondolok, hogy jönnek be folyamatosan 1-ek és 0-k, ezeket eltenné egy változóba, sorban, amiket után ki lehet értékelni, melyik mit jelent, a "holt időben".
PL: Morzejel tanító: rávillogtatok akármit egy optotranzisztorra, és azt a PIC kérésre egy leden visszavillogtatja és egy LCD kijelzőn a visszavillogtatással együtt kiírja az üzenetet betűkkel.

Igen, több lehetőség is van: USART, SPI, I2C, stb. Ezek hardver modul szinten jellemzően benne vannak a PIC ben.
A fentiek közt a legegyszerűbb az USART vagy az SPI megoldás. Ez utóbbi esetben valakinek kell lennie mesternek, míg a másiknak a Slavenek.
USART -ot tudsz használni közvetlen két PIC között (nem általános, de akár működhet is), igaz így az áthidalható távolság nem nagy, gyakorlatilag csak a panel mérete. De így van ezzel az SPI is....
A TX porton a jel sorosan lép ki, és a másik PIC RX oldalán sorsan érkezik meg. Viszont amint belép a 8 bit a vételi regiszterbe, már ismét 1 byte -á áll össze az adat, ha mindegyik bit megérkezik. Igaz ez némi időbe kerül. Tipikusan 9600 bit/s os átvitelt használnak.
Ajánlom figyelmedbe az RS232 leírását olvad el a neten, ott írnak olyasmiről hogy Start bit, meg Stop bit is. Ezek szerepe megkerülhetetlen.

Sziasztok,

Rendeltem a HEstore-ból egy PIC18F2550-es PIC-et, PICKit2 építése céljából. Helyette az LF változatot tudják küldeni.

Mi a különbség a kettő között? Egy printer portos programozóval szeretném felprogramozni, ami 12 V Vpp-t ad ki. Fel tudom programozni ezzel is, vagy valamit alakítanom kell rajta (mármint a programozón)? Pl. a 12V Vpp-t lecsökkenteni 5V-ra...

Kösz: kistee

Küldeni könnyű, fogadni bonyolultabb. Hol kezdődik egy bit és meddig tart? Mikor kezdődik a jelsorozat? Az UART, I2C, SPI, 1-wire szabványos megoldások ezen problémák megoldására (meg még másra is, pl. a fogadó partner megcímzésére, stb.)

Csinálhatsz egyéni megoldást/protokolt, nem szakad le tőle az Internet! A fenti problémákra akkor is megoldást kell találni. Pl. egy hosszabb szünet jelzi, hogy új adatsor fog kezdődni. Egy kötelező szintváltás a legelején segíthet a kommunikáció szinkronizálásában. A bitek időtartama pedig lehet előre egyeztetett. De így lassan az UART protokolnál tartunk (már csak egy STOP bit kell a végére... Hardveres támogatás híján szoftveres bitbillegtetéssel (bit banging) is lehet kezelni - nyilván szerényebb átviteli sebességgel.

Vannak periféria bővítő IC-k (pl. MCP2308, MCP23017, MCP23S17), de egyszerűbb esetben egy (vagy több) shift regiszterbe is kiforgathatod a LED vezérléséhez a biteket. Lásd pl. 74HC595, amiből többet is sorbaköthetsz.

Sziasztok!

Kérdezném hogy abban az esetben amikor meghívok egy rutint (CALL) és a rutinban van egy feltételes elágazás aminek az egyik szála a RETURN a másik viszont egy GOTO, hogyan lehet helyesen visszatérni a rutinhívás helyére? Mert ha GOTO val megyek tovább (mert eleve nem is a rutinhívás helyére akarok visszatérni hanem a program egy bizonyos részére...) a rutinból akkor a verem előbb utóbb megtelhet és ez ugye nem szerencsés.

Én arra gondoltam hogy a rutinban a GOTO helyett az elágazás tól két RETURN el tudnék visszalépni. Az egyik simán visszalép a rutinhívás helyére, a másik ugyanez, de előtte beállít egy flag et amit a visszatérés után kiértékelek majd e szerint ugrok tovább GOTO val vagy fut tovább a program. Tehát egy rutin két kilépési (RETURN) ponttal. Jó megoldás ez, vagy van erre egyszerűbb megoldás? Hogyan szoktátok Ti profik ezt lekezelni, vagy hogyan kéne csinálni hogy jó is legyen? Van egy kütyüm ahol ezek miatt a GOTO s rutinok miatt előbb utóbb összeborul az egész program, valószínűleg a verem túlcsordulás miatt.