Hello!

Csak szeretném újra felhozni ezt a kérdést.

Karácsonyi ajándék.
A rajz is ott van mellette, de nyák nincs. Nekem most itt működik az asztalon egy 16F628A-ban(627A-ba is belefér, nem kell módosítás a hex-en), igaz sima LED-ekkel, de ez mindegy. Az AUX nem működik, nincs is a rajzon, de igazából nem is jöttem rá mire való...
A gombot, ha röviden nyomod, akkor megáll a fény, ha folyamatosan, akkor kikapcsol(sleep). Visszakapcsolni szintén hosszabb megnyomással lehet.

Én is kérdeznék, milyen RGB LED-ed van, hol vetted?

Szia! Kaptam egy volt kollégámtól smd rgb ledeket ezek ambi light tv-ben voltak. A lomexnél van rgb led ha minden igaz.Köszönöm a forrást ez ugyan az a projekt?

Most boldogabb vagy, ha leírjuk, hogy: NEM?

Igen, mert így legalább nem várok válaszra. Köszi azért, körbe leskelődök még hátha.

Ugyanaz, de módosított, természetesen...

Sziasztok!

Egy pic18f2620-ra C-ben szeretnék írni egy programot ami egy bonyolult matematikai függvényt számít ki.
Kérdésem az lenne, hogy hogyan lehetne lemérni a program lefutásának sebsségét, vagyis hányszor számolja ki különböző értékekkel 1 mp alatt a függvény eredményét? gondolom debuggolás alatt pickit2-ből valahogy meglehet oldani. van-e a mirkovezérlőben olyan regiszter ami inkrementálódik vagy változtatja az értékét függetlenül a program futásától órajelfüggően, amit le lehetne kérdezni bizonyos időközönként? tudom kicsit lusta vagyok utána nézni de egy egyszerű rávezetés és megkímél ezernyi dolgom mellett több óra fáradságos görnyedő kutatástól!
A válaszokat előre is köszi!

Timer mond-e valamit?

Használhatod az MPLAB beépített szimulátorát is. Teszel egy breakpointot a függvéyed elejére, egyet meg a függvényt követő utasításra. Megnyitod a debugger menupont alatt található stopwatch eszközt, abban az első breakpoint elérése után kinullázod az értéket, nyomsz még egy run-t és amikor eléri a második töréspontot a szimulátor, láthatod is az algoritmus futási idejének hosszát. Megjegyzésként azért ideírnám, hogy a debugger settings- ben előzetesen be kell állítani a kontroller órajelét, hogy pontos adatot kapjál.

Adatlap.... Mindig ez az elsődleges információforrás. :yes:

Csinalsz egy timer interruptot pontosan 1mp-re es a foprogramban szamlalot novelgeted minden alkalommal mikor a szamitasod veget ert. Interruptban meg kiirod a szamot egy LCD-re vagy oda teszel egy break pointot es megnezed a szamot debuggerrel. Csak arra vigyazz, hogy a szamlalo megfeleloen nagy legyen nehogy tul csorduljon ha ne adj isten a szamolo rutin tul gyors lenne...

Tú is csordulhat, csak akkor azt is számolni kell... De a szimulátor sokkal egyszerűbb és gyorsabb.

Sziasztok ujra.
sajnos ugyfest a sorosporti adatkommunikációt mégse tudom elég gyorsan lekezelni mint hogy a gép egy adatcsomagot küld, így nem teljes az adatfeldolgozás. Át kell térnem az interruputos megoldásra, viszont azért is nem használtam eddig mert az elképzelés nincs meg hogy tudnám a folyamatos adatfeldolgozást végrehajtani. Szoval a lényeg hogy a gépről egy adatsorozatot küldök ki az eszköznek és ezeket 8bitenként dolgoznám fel. pl a 2. 8bit az adatfolyam hosszát tartalmazza(hány bájt) és ezalapján lehet tudni hol az adatfolyam vége. nahmost hogy tudnám eltárolni ezeket a bájtokat és menetközben figyelni őket ha interruptosként irom meg a soros porti kommunikációt?

Nagyon leegyszerűsítve és hibafigyelés nélkül úgy, ahogy a mellékelt fájlban látod. A buffernek létre kell hozni egy tömböt, s két mutató kell hozzá: egy kimeneti és egy bemeneti. Ha a két mutató megegyezik (ugyanoda mutat), akkor a buffer üres, vagy túlcsordult. A mutatókat célszerű az ACCESS Blokkban tárolni. Bővebben: Link

Szia!
Köszönöm akkor Zener kimarad a mókából.
Üdv LAC

Harveres handshake-el probalkoztal mar? RTS / CTS jeleket kellene bekotnod es kezelned es akkor mikor epp nem birsz adatot fogadni, akkor a CTS-t alacsonyba teszed... Ha ujra kepes vagy fogadni, akkor megnezed, hogy az RTS magas-e, azaz akarnak-e kuldeni adatot, es ha igen, akkor a CTS-t magasra huzod, amugy alacsonyan hagyod. Ily modon mas dolgokat is csinalhatsz mig periodikusan rakukkantasz az RTS-re... azaz pollozol...

Amig a CTS nem kerul magasra (altalad) addig a masik oldalon az eszkoz varakozik. Tehat nem fog adat elveszni.

Ha az ado oldalt is Te csinalod, akkor pedig az RTS-el jelzed, hogy kuldeni akarsz, es figyeled a CTS-t, ameddig az nem engedelyez, addig nem kuldozgetsz... kb ilyen egyszeru.

Ami a protokollt illeti: Tokeletesre megcsinalni nem egyszeru, de altalaban a legjobb megoldas, ha csinalsz egy fix hosszusagu fejlecet (header), abban van leirva minden, hogy milyen fajta csomagrol van szo, hogy milyen hosszusagu adatot akarsz kozolni, es szokas mind a headerre mind pedig az adatcsomagra egy CRC-t is oda tenni. Elobb ellenorzod, hogy a fejlec hibatlanul atjott-e (CRC alapjan). Ha igen, akkor johetnek az adatok, varsz ameddig X szamu adat byte at nem jott, ellenorzod a CRC-jet. Ha nem jtt meg X szamu byte-, akkor egy idozito segitsegevel eszre kell venned, hogy a kapcsolat megszakadt vagy csonka adatcsomag erkezett (time-out).

Namost, ha egy oldali a kommunikacio, akkor nehez jelezni a masik felenek, hogy minden rendben volt, vagy, hogy ismetelje meg az adast. Ha ketoldalu akkor olyan fajta csomagokat is kell tervezni, hogy ACK (acknoledgement, jelzi minden ok). Aztan NAK (Not ACK...). Nezdd meg az ASCII tablat, ott 1-1 karakterrel oldottak meg ezeket a kodokat, erdemes a csomag fajtahoz is ezeket az ertekeket felhasznalni meg akkor is, ha nem csupan egyetlen byte-ot, hanem egy komplett csomagot kuldesz at.

Hát igen az RTS / CTS megoldás jonak tünik de már hardverileg nem tul megoldhato, kész nyákon már csak a program hiányos.
Ez a bufferes megoldás viszont tetszetős. Ha ezt illesztem igy be a progi elejére persze init modositás után, akkor más más alfüggvényekből is elérhető a TX és RX buffer? illetve a buffer mutatót is tudom nullázni máshonnan ? pl ha feldolgozta az adatot, és a tx bufferbe is kiküldött ujabbat, akkor az RX_inp -et nullázni tudom e h ujra elejétől töltse a buffert, és ne keljen ujboli olvasásnál körbe mennem a bufferen ?

A hibafigyelés meg elvileg megvan egy CRC16 függvénnyel , viszont eddig ugye nem igazán volt elfogadva minden adat a 'lassu' feldolgozás miatt.. És ha éppen dolgozott mikor még adat jött akkor ugye ki-ki maradtak bájtok .. Ebben a bufferesben viszont bízom nagyon .

Nem volna egészséges, ha boldog és boldogtalan matatna a bufferekben. A főprogram oldaláról ezt csak az _usart_getc(), _usart_putc() függvényeknek engedd meg! Itt csak a vételt mutatom, azt is leegyszerűsítve:


A mutató léptetése látszólag túl van bonyolítva. Figyelembe kell azonban venni, hogy a mutató módosítása csak "atomi" (azaz az interrupt által nem félbeszakítható módon) végezhető. Ez bonyolultabb előkészítést igényel, annak viszont nem árt az esetleges félbeszakítás. Így megspórolható az interrupt letiltása a kritikus szakaszon.

Egy kis homály támadt bennem az RX_outp mutatóval kapcsolatban. Az előbb csatolt .c fájlban nem nagyon láttam sehol ezt a mutatot, csak a deklarálásban, ezért nem nagyon világos a 3. sor , majd utána h miért is fogja ez azt a következő adatot visszaadni ami a következő ? Az világos hogy a mutatót növeled egyel majd egyszercsak nullázod, de a 3. sor jelentése kérdőjel.

Keresd fel a már többször megadott linket követve a honlapomon található PICula projektet, s abban nézd meg az inicializálásokat (elsősorban az init_usart() és InitializeSystem() függvényekre gondolok)!.. Ebben van a hardver inicializálása is, meg a kérdezett hiányzó láncszem, a mutatók inicializálása is:


Bővebben: Link
Az RX_inp mutatót az interrupt kiszolgálásakor léptetjük, ahogy pakolgatjuk be a karaktereket. Az RX_outp mutatót a főprogramban léptetjük, ahogy szedegetjük ki a karaktereket. Amikor a buffer végére érünk, kezdjük az elejéről (gyűrűs buffer).

Nem ez volt a kérdés Már felkerestem (nem ma először) , és az érték oké, csak a 3. sor nem volt tiszta, de azóta leesett hogy addig vár amíg a mutatok megegyeznek mert addig nincs benne friss vagy új adat. Hosszú nap volt elnézést a lassú felfogásért Még az is lehet hogy ma átírom és letesztelem , ha mégse akkor holnap írok hogy mire jutottam. Köszönöm mégegyszer a segítséged.

Az nem illik, hogy megérted, amíg be sem fejeztem a magyarázatot...

Ebbol levonhato ket orok tanulsag:

1. A mikrokontrollereknel a Hardver es Szoftver szorosan ossze tartozik, az egyik nem mukodik a masik nelkul

2. Ameddig nincs mukodokepes prototipus addig felesleges nyakot tervezni es gyartani

Van szoftveres megoldás is: XON/XOFF protokol. De ha jól értettem a problémádat, egyelőre nincs szükséged rá.

Igen szerintem se kell ez a megoldás. Viszont a program átirás után ide jutottam. Szerintem amit kellett include-oltam , de ezt kapom build-nál.
Advisory[1233] Employing 18F2420 errata work-arounds:
Advisory[1234] * Corrupted fast interrupt shadow registers
Error [499] ; 0. undefined symbol:
_usart_putc(minor_v6.obj)

Ami különbség icserny progijához képest hogy én a HI tech buildert használom nem az mplab C18as forditoját, ezért lehet hogy valami nem izlik neki . Ha minden kötél szakadna akkor a hétvégémet rááldozom hogy a picula projectbe belevésem a meglévő programot csak az elég hosszadalmas lenne

Ez elég rossz vicc.

Úristen mi roszat mondtam ? :eek2:

Ezen gondolkozz el inkabb:



Ez nyilvanvaloan azert van, mert:



...magyaran neked mas tamogatoi konyvtaraid vannak, igy a soros porti kezelo neve es valosiznuleg hasznalata kulonbozik... Doksi olvasgatast tudnam javasolni.