Fórum témák

» Több friss téma
Fórum » PIC programozás assemblyben
 
Témaindító: sonajkniz, idő: Máj 30, 2015
Témakörök:
Lapozás: OK   27 / 27
(#) nemgyuri válasza nedudgi hozzászólására (») Jún 16, 2022 /
 
Ha 1 soros input lenne, nem lenne problémám. Az egyidejüséggel -ütközés- van problémám.
----Közben szétnéztem a PIC-ek között és találtam jó-néhány PIC-et amiben benne van 3 hardveres UART. --- Az érdekelt, hogy egyszerübb PIC-el hogyan oldható meg a 2+1 soros port kezelése software-ből.
( Azt hiszem, hogy maradok a 3 UART-os PIC-nél...)
(#) nedudgi válasza nemgyuri hozzászólására (») Jún 16, 2022 /
 
Minden egyes UART külön megszakításhoz köthető (pontosabban másik bit jelzi a megszakítás okát), nem lehet itt semmi probléma. (Az gond lehet, ha túl nagy az adatátviteli sebesség, és a kontroller nem bírja.) Ha csak egyirányú az adatforgalom, két UART is elboldogul a dologgal.
Ütközés nem számít, a FIFO-ba írás sokkal gyorsabb, mint egy adatbájt átküldése.
A hozzászólás módosítva: Jún 16, 2022
(#) Peter65 válasza nemgyuri hozzászólására (») Jún 17, 2022 /
 
Szia!
Ha a soros kommunikáció sebessége alacsony, akkor nem olyan lehetetlen dolog a szoftveres UART. Adni értelemszerűen egyszerűbb, sőt ha van egy kihasználatlan SPI modulod, azon is ki lehet adni a soros kommunikáció szerinti adatsort.
A vétel sem lehetetlen, több féle módon felépíthető, például itt is olvashatsz egy megközelítést.
(#) benjami válasza nemgyuri hozzászólására (») Jún 17, 2022 /
 
Ha az output bitsebessége megegyezik valamelyik input bitsebességével akkor elegendő 2 uart is. Amúgy szoftveresen az output könnyebben megoldható, egy timer-t használva akár több uart outputot is működtethetsz (bár ebben az esetben erre pont nincs szükség). Az viszont lényeges, hogy szoftveres uart esetén a megszakításokat úgy kell kialakítani, hogy ne okozzon túl sok bitidő változást a többi megszakítás. Ezt megszakítás prioritással vagy alacsony bitsebesség esetén nagyon rövid végrehajtási idejű megszakításkiszolgáló eljárásokkal lehet megoldani.
(#) asch válasza nemgyuri hozzászólására (») Jún 17, 2022 /
 
Elméletileg tűpontos UART adót Timer+Output Compare hardverre építve lehet csinálni, vevőt pedig input capture-re építve. Ezzel a megoldással a legkevésbé szigorú az interrupt kiszolgálás reakcióideje.

Kevésbé pontos, ha a kimenetet timer interruptból változtatjuk, a bemenetet pedig interruptban mintavételezzük. Itt ugye az interrupt kiszolgálási idejéből adódni fog egy jitter.

Olyat is lehet csinálni, hogy interruptokat letiltva, az utasítások végrehajtási idejét számítva adjuk ki a jelet (bit banging). Ehhez hasonló vevőt is lehet írni. Szinkron esetben (az egyik adó a másik órajelét másolja küldésre) meg lehet csinálni duplex működést is, azaz azt hogy egyszerre írunk és olvasunk.

Egyrészt szép kihívás ilyeneket csinálni, másrészt viszont időrabló, és nagyon kellemetlen debuggolni, ha nem jól működik. Márpedig nekem sosem szokott elsőre működni. Plusz ha más feladata is van a csipnek, akkor az azzal való együttműködéssel egyre komplexebb lesz számolni időzítési szempontból. Úgyhogy a legjobb olyan csipet választani, amin van elegendő UART.
(#) nemgyuri válasza Peter65 hozzászólására (») Jún 17, 2022 /
 
Köszönöm, ezt még tanulmányoznom kell!
(#) nemgyuri válasza asch hozzászólására (») Jún 17, 2022 /
 
"asch" és "benjami" Köszönöm a segítségeteket, a kimenet nem okoz problémát. Az a Timeres ötlet a vételnél is működhet, ha jól gondolom. (Feltéve, hogy azonos baudrate van minden csatornán.) Startbit megjelenésétől adott időben kell kezdeni a port olvasását és bitenként beforgatni. Szerintem az nem jelenthet túl nagy problémát, hogy a két input véletlenszerűen érkezik.
(#) Bakman válasza nemgyuri hozzászólására (») Jún 17, 2022 /
 
Milyen PIC-ről van szó?
(#) nemgyuri válasza Bakman hozzászólására (») Jún 18, 2022 /
 
Nem volt szó konkrét típusról. Elvi kérdés volt. lehetőleg szoftveres megoldásra.
(#) nedudgi válasza nemgyuri hozzászólására (») Jún 18, 2022 /
 
Nemrégen még hardver portról volt szó. Itt.
A hozzászólás módosítva: Jún 18, 2022
(#) nemgyuri hozzászólása Jún 28, 2022 /
 
Segítséget kérek, PIC12F1572-t vettem (valamikor). MPLAB-ban ilyen nincs. GITHUB-ról letöltöttem a PIC12F1562.inc file-t, betettem a többi közé, de ettől még továbbra sem választható ki.
Tudja VALAKI, hogy mit kellene tennem?
(#) Pali79 válasza nemgyuri hozzászólására (») Jún 28, 2022 /
 
A pickit2-höz csináltak korábban több ezsközt ismerő állományt. A pickit2 továbbfejlesztése vagy ilyesmi a téma neve, ott kellene megnézni.
(#) user1914 válasza nemgyuri hozzászólására (») Jún 29, 2022 /
 
Keresd a "PK2DeviceFile.dat" állományt. A 2019.12.21. állományban benne van.
Nálam az eredeti telepített verzióban is megtalálható. "PICkit 2 v2.61" 2009.03.24.
Üdv. M.
A hozzászólás módosítva: Jún 29, 2022
(#) Hp41C válasza Pali79 hozzászólására (») Jún 29, 2022 /
 
Nem a PICkit2 -höz keresi az okosítást, hanem az MpLab -hoz.
Van két nem túl jó hírem:
1. MpLab fejlesztése megállítva, használja az ember az MpLabX -et. Jó adag törelem kell hozzá.
2. Az MpLabX fejlesztése közben a MpAsm -et félre tették, helyette az as nevű program jött. Még nem használtam.

MpLab8.92.JPG
    
(#) nemgyuri válasza Hp41C hozzászólására (») Jún 30, 2022 /
 
Köszönöm MINDENKI hozzászólását segítségét. Már rájöttem, hogy az MPLAB-al nem jutok előrébb ( valószinű ).
Már letöltöttem az MLABX-et, küzdök vele. ( Eddig úgy tűnik, hogy nem lesz a kedvencem. )
A hozzászólás módosítva: Jún 30, 2022
(#) sonajkniz válasza nemgyuri hozzászólására (») Júl 1, 2022 /
 
Szia!

Én MPLAB X-et használok sok éve, és teljesen jól elvagyok vele.
De az tény, hogy az újabb verziók el vannak cse*-ve.
A leg használhatóbb a v3.65-ös.
Következő: »»   27 / 27
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem