Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Gondolom a terminalon latod a pontokat es az y-okat. Egyik megoldas, hogy a terminalt atallitod hex kiirasara, vagy a PICben atalakitod ASCII formatumra a szamokat es azt kuldod a terminalra. Esetleg elkuldhetned a Te altalad irt progit, es akkor biztosan tobbet lehetne mondani.
Udv Vili
Aham, terminálon irja igen a pontokat és az ipszilonokat. Termite, ezt a terminált használom.
Probálkoztam már a sprintf-es átalakitással, de ugyis csak vesszőket kaptam akárhova is érintettem az ADC bemenetet. Itt a kód:
Két fajta módszerrel is próbálkoztam, az egyik ki van commentálva.
Ez csak egy bájtot fog elküldeni. Helyette ilyesmi kéne:
(Már régen progiztam C-ben, remélem jól írtam a >>-t ![]() A terminálban csak a hex kódokat fogod látni, ahhoz, hogy ott szám legyen a PIC-ben ASCII kódokká kell konvertálnod a mért értéket és azokat elküldeni sorban. Máskor, ha ilyen hosszú a kód, inkább txt-be másold és azt csatold.
Nem tudom milyen forditot hasznalsz es nem ismerem a Te putcUART2() fuggvenyedet, de pl normal printf () fvenynel ezt igy lehet megcsinalni:
Udv Vili
Na jó, de egy 16bites számot hiába alakít decimálissá, vagy ez ASCII kódokká alakítja helyiértékenkén és úgy küldi ki sorban?
A "fajdalom mentes" kifejezes amugy relativ -- printf eleg sok program memoriat fel tud emeszteni. Neha jobb az itoa hasznalata...
Igen, karakterekként írja ki, mintha pl. egy konzolra írnál ki egy számot. A printf az adott nyelvi környezettől függően valamilyen karakterküldő "primitívet" (pl. putch, putchar) fog meghívogatni minden egyes kiírandó karakterrel, azt, hogy ezt milyen néven és hogy kell megírni, hogy működjön is, az adott fordító manualjából kell kilesni.
Aha, köszi, én nem használtam még ilyen beépített dolgot. Ez biztosan az ASM miatt van.
![]()
Hali
Ezt tudjuk, de a kezdok szempontjabol, es ha van eleg nagy memoriad sokkal egyszerubb. Majd ha 98 % lesz a memoria telitettsege lehet gondolkodni mikent csokkentsuk a progi meretet. (vagy veszunk eggyel nagyobb PIC-et) De ha itoa fv-t hasznalsz akkor is kell printf, putc vagy valami amivel a terminalra kuldod. Udv Vili
Egy übergagyi eljárással így lehet egy legfeljebb 16 bites számot hexában kiküldeni:
Szia,
Használtam ezt de ezzel sem müködik : gondolom ez is ugyanaz mint a printf csak itt átrakja ebbe a változóba, ami ki tudok küldeni rs232-esen Amúgy nekem a terminálon megjelenik hexában is meg rendesen is. Pl. ha kiküldok a putcUART2("Hello world!") akkór azt ki tudom olvasni a terminálon. Megpróbálom watt ötletét hátha azzal menni fog.
Ha már itt vagyok, az lenne a következő kérdésem, hogy mért van az hogy van 4 darab PWM motor vezérlőm, külön külön szépen megy mindenik, de ha egyszerre akarom öket müködtetni akkór nem kapnak áramot a motrok. A HBridge az megkapja a teljes feszültséget, de mikór mind a 4 motórt akarom futtatni (egyszerre) akkór nem engedi át a HBridgen a feszültséget csak nagyon keveset, amitől a motrok éppen csak morrognak.
Van erre valami ötletetek? Ugyancsak PIC32-es, és minden ugyanaz mint az elöbb. Kódrészlet:
Mitől resetel a PIC-em? A watchdog ki van kapcsolva. Ráadásul olyan helyről resetel ahol eddig minden probléma nélkül továbbment. A gyakorlatban és a szimulátorban is resetel. Mi okozhatja ezt?
Szerk.: Van egy "delay100ms" nevű időzítő szubrutinom. Ezt egy helyen közvetlen egymás után háromszor hívom meg és a második meghíváskor resetel a PIC.
Hohóóó... ha a szubrutint visszamásolom az inc fájlomból az asm fájlba és az inc-ben kikommentezem akkor nem resetel a PIC! Ez így elég rossz dolog... Mitől van ez?
Szerk.: Sajnos így is resetel csak később, egy későbbi rutin-hívásnál. ![]()
Veremtar. A PIC-nel (18F) 31 szintu lehet. Ebben tarolja a szubrutinhivaskor es a megszakitaskor a visszateresi cimeket. Ha sok az egymasbaagyazott szubrutinhivas es meg 2 szintu megszakitast is hasznalsz, tul lehet lepni a hatart es akkor csinal hibakat. A STKFUL es a STKUNF biteket kell lesni a STPTR regiszterben. Magasabb szintu programnyelveknel a fordito automatikusan figyeli, de ASM-nel Neked kell figyelni ra.
UdV Vili
Ja akkor tudom mi az. Megnéztem és igen, a veremtár telítődése miatt resetel a PIC. Viszont erre nincs semmi oka! Van a programomban ez a három sor:
Az elsőn még átmegy rendesen, aztán belép a másodikba és ott elkezdi dekrementálni az egyik regisztert (időzítés) aztán egyszercsak hirtelen a semmiből az STKPTR legfelső bitje H lesz és a PIC resetel. Mindezt mondom úgy, hogy az előző "call delay100ms" szubrutinból még hibátlanul visszatért. Sőt, nem hogy a veremtár 31. szintjét, de még csak a másodikat sem éri el a PIC mert ez a szubrutin-hívás a főprogramban történik (a legfelső szinten). De ahogy nézem a probléma a megszakítás okozhatja valahogyan mert ha a GIE bitet nullára állítom az inicializáció után akkor már nem resetel a PIC (de nem is lép be soha a megszakításba). A megszakításból akárhova vissza tud ugrani a PIC, ugye?
hogy mért van az hogy van 4 darab PWM motor vezérlőm, külön külön szépen megy mindenik, de ha egyszerre akarom öket müködtetni akkór nem kapnak áramot a motrok. A HBridge az megkapja a teljes feszültséget, de mikór mind a 4 motórt akarom futtatni (egyszerre) akkór nem engedi át a HBridgen a feszültséget csak nagyon keveset, amitől a motrok éppen csak morrognak.
Van erre valami ötletetek? Ugyancsak PIC32-es, és minden ugyanaz mint az elöbb.
Hali
Idézet: termeszetesen. A keslelteteseket probald meg maskepp megoldani. Pl TMR0 IT-vel. Ha sok az egymasba agyazott szubrutin akkor eloferdulnek ezek a problemak. At kell szervezni a programot, hogy ne legyen annyi szubrutin hivas. Kesleltetest pl IT-ben flag billegtetessel is el lehet erni, es akkor nincs Delay100ms szubrutin, csak varsz egyhelyben a flag visszabillentesere.„A megszakításból akárhova vissza tud ugrani a PIC, ugye?” Udv Vili
Szia!
Nézegetem a kódot de egyszerűen elképzelhetetlennek tartom hogy eljut 31 szintig a verem! Szerintem még csak 10-ig sem de 31-ig az tényleg lehetetlen! Ennyire azért nem komplex a programom. Azt ki lehet valahogyan deríteni hogy hol éri el a 31. szintet? Szerk.: Végignéztem a programot az összes call utasításra rákeresve hogy mik lehetnek egybe ágyazva és arra jutottam, hogy a legeslegrosszabb esetben is a verem mélysége 5 lehet.
A szimulaciokor bekapcsolod a Hardware Stack ablakot es voila lathato a stack mozgasa.
Hali
Esetleg meg lehet ilyen hiba a tablazatok olvasasakor is. Tulcimzed a tablazatot, vagy laphataron atnyul a tablazat.
Ez sem lehet mert dcfsnz és retlw párossal van megoldva mindhárom táblázatom, tehát nem a PC-hez adok hozzá.
Köszönöm, így már mindjárt látom a dolgokat! A reset vektorra ugrás előtt a verem tényleg a 31. szinten van!
![]() De érdekes ez a verem, mert a 0. szintjéhez azt van írva hogy "Empty", az 1.-höz 0007FA, a 2.-hoz 000F62. A 3. és a 29. köztiekhez egyöntetűen 0006FE, a 30.-hoz 00007E és a 31.-hez 000DAE. Na ezt én nem értem. Hogyan lehet az hogy a 3. és a 29. szinteken ugyan az a cím van?
A szimulációnál nézd meg, hol jár a progid amikor arra részre pakol. Lehet, hogy véletlenül bennmaradt egy sor ami többször fut.
A verem alulcsordulásakor is resetel a proci, ha van egy kallódó return, vagy "függvény hívást" csinálsz goto utasítással call helyett. mindkettő okozhat ilyet, és ilyenkor lehet hogy a hibás rész nem is ott van, ahol kifagy a program
|
Bejelentkezés
Hirdetés |