Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
PFff
 AVR Még nem nagyon hallodtam róla, célriányosan nyomultam a PIC-el! Itt láttam is cikket, meglesem, mi az valójában xD Köszi az infót!
Köszi szépen ezt az infót!
Átnézem rendesen, és megpróbálom leírni, hogy mit hoztam ki az ASM fájlból... Ha hülyeséget mondok, javítsatok ki légyszi  Köszi!
Csak az bosszant, hogy a régi verzióban ment úgy az inicializálás gond nélkül, de az újban nem akar és fogalmam sincs, hogy miért. Viszonylag zagyva a fájl, mert már mindent kigyomláltam belőle, meg átvariáltam, meg összecseréltem, meg...
Arra gyanaxom, hogy nem jó lábakra küldöm az infót, bár kétszer átnéztem. denisz Az ilyeneket kérnénk mellőzni! szamóca
Sziasztok!
Olyan problémám lenne hogy nem találok egy jó 16bites osztó programot! Írtam olyat ami kivonásos módszerrel csinálja de túl hosszú időbe tellik azzal. A lényeg hogy egy sebességmérőt építek a motoromhoz és a tmr1 számláló értékét kellene osztanom 33-al. Majd az így kapott eredménnyel kell elosztanom a 6192-t. A 33 onnan van hogy a tmr1 léptetésére egy 32.768kHz-es órakvarcot használok és 1ms alatt eddig számol el. (kerekítve 33-ig) A 6192 onnan van hogy a kerék átmérő 1,72m és a m/s és km/h közötti váltószám 3,6. 172*36=6192 Ha ezt elosztom a TMR1/33 értékkel kijön a sebesség km/h ban. Tudna valaki linkelni vagy küldeni egy jobb rövidebb osztó programot a kivonásosnál? Idézet: Sejtésem szerint valami GPS modul fogja bemenő adattal ellátni, az meg ilyesmi formában küldi a koordinátákat. „Én azt nem értem, hogy egy PIC-nél ennek egyáltalán mi értelme van.”
Szia!
Igen pontosan ezt szeretném.. A bejövő adatokat ez az algoritmus fogja majd kiszűrni, majd tárolom egy nagyobb külső memórián. Még csak próbálgatom hogyan tudnám feldolgozni ezeket..
Aha, így már értem.
Akkor viszont felmerül két kérdés is: 1. kell-e a "dupla pufferelés", azaz be kell-e olvasni az adatokat egy stringbe, majd ezután feldolgozni őket, vagy esetleg a (gondolom) soros porti vételi rutinba is be lehet írni a beérkező karakter azonnali értelmezését 2. kell-e foglalkozni azzal, hogy vessző jön-e, vagy elég annyit figyelni, hogy nem számjegy A kibányászott számot én nem külön tömbbe raknám le, hanem már rögtön számolnám is az értéket a karakterkódból. Lényegében egy "kérem a következő számot" rutint lehetne írni, ami a soros porton beérkező karakterekből azonnal számot is csinál az első nem számjegy karakterig.
Igen soros porti vétel lesz.
Idézet: „kell-e a "dupla pufferelés", azaz be kell-e olvasni az adatokat egy stringbe, majd ezután feldolgozni őket” Én elsőre erre gondoltam. Azt viszont nem tudom, hogy mi lenne a legjobb megoldás, mivel egyszerre kb. 200 byte-nyi adat fog érkezni, és mivel a PIC korlátos ram területben .. Szerintetek, hogy lenne érdemes, ezt megcsinálni? Idézet: „kell-e foglalkozni azzal, hogy vessző jön-e, vagy elég annyit figyelni, hogy nem számjegy” A vesszők választják el azokat az értékeket, amik fontosak lesznek számomra (lesznek köztük majd betűk is), és sajnos nem csak 1 ilyen feldolgozást kell, hanem pl: 1-2 vessző közti, majd a 4-5, aztán 9-10 stb. Remélem sikerült érthetően leírnom
Tehát 6192/(timer/33) kellene neked? Ez így két osztás, ezt le tudod csökkenteni egy osztásra, ha 204336/timer formában csinálod(talán így gyorsabb). Ha viszont a 33 helyett megelégszel 32-vel, akkor öt jobbraléptetéssel megúszod az osztást.
Watt honlapján találsz példaprogramot 32/16 bites osztásra.
Javasolnám valami 18-as PIC használatát, olyat aminek kicsit több RAM-ja van, és akkor nem kell a cipőkanálhoz folyamodni.
Igen már én is gondolkodtam ezen, és nézegettem is őket..
Viszont kicsit korlátolva vagyok e téren, mert a hw már elkészült, 20 lábú PIC kell bele és már fix a lábkiosztás is.
Sajnos 20 lábúban igen szűkös a választék, szinte egyedül a 18f14k50 van, de annak valószínűleg nem fog a lábkiosztása stimmelni, meg annak is csak 768 byte RAM-ja van. 28 lábúnál már szélesebb a választék.
Idézet: „A 33 onnan van hogy a tmr1 léptetésére egy 32.768kHz-es órakvarcot használok és 1ms alatt eddig számol el. (kerekítve 33-ig)” 32-vel kell elosztani nem 33-mal, hogy 1ms-et kapj... azt pedig nehany shiftelessel meguszod. Ha elegendo mp-kent merni akkor 15* kell shiftelni, fel mesodperchez 14-el, 250ms-hez 13-al es igy tovabb... minel nagyobb a mintavetelezes annal pontosabb eredmenyt kapsz mivel egy korulfordulas eleg kevesszer tortenik meg mp-kent (30-nal mar 185-os tempoval mesz, ld a szamitast) Az a nagy szam nem jo, mert nem 172cm/s -ben van meg a szamod, hanem 1.72m/s -ben. Jo lesz az 6.192-nek is. Namost az egyszeruseg kedveert hagyjuk el a 0.192-t. 6-tal meg egyszeru lesz osztani, elobb megszorzod 12-vel (merthogy szorozni egyszerubb felteve hogy belefersz a szamabrazolasba), tehat megszorzod 8-cal majd 4-el es az eredmenyt ossze adod. Majd ezt az egeszet elosztod 2-vel. Namost egyszerusitsunk csak. Elev csak 4-el es 2-vel szorzunk, tehat igy 30-nal 120 az eredmeny a 4-el torteno szorzas utan, majd a ketszeres szorzas utan az osszeadast kovetoen azonnal kijon az eredmeny, nem kell vissza shiftelni. Az egesz megoldhato 8 bites tarolokkal, nem kell buveszkedni... Tehat ha 30-at szamlalsz, akkor 30*1.72*3.6 tehat 185.76 -tal mesz... Ezzel a szamolassal 180 jon ki, tehat lesz egy kb 5 km/h pontatlansag 180-nal, cserebe egeszen leegyszerusodott a feladat... (megjegyzem a gumi kisse belapul menet kozben, tehat gyanitom a mert 1.72m a valosagban kisebb(?)) (remelem jol szamoltam a dolgokat...)
Megnéztem a lábkiosztást, és legnagyobb meglepetésemre szinte teljesen megegyezik 16f690 - 18f14k50.
Idézet: „A 6192 onnan van hogy a kerék átmérő 1,72m” Traktorra lesz?  Vagy kerületet akartál írni? 
Sziasztok!
Írtam egy teljesen új SPI kommunikációt(c30,dspic30f). Működik 93c típusú EEPROM-mal, de 25lc-hez alakítgatva viszont nem akar működni. Szkóppal megnézve a válasza csupa 1, de a többi 3 jel jónak tűnik. Valakinek tapasztalata 25lc-s EEPROM-okkal? Van valami extrájuk?
pont én is ezt találtam
De mielőtt eltemetnénk a mostanit, szeretném megpróbálni azért ezzel, aztán ha minden kötél szakad akkor beszerzek egy másikat..
Csak nem hagy nyugodni ez - nem volt jo a megkozelitesem, ugyanis ha azt szamoljuk hanyszor prodult a kerek 1 ms alatt akkor eleg pontatlan lesz a meres. Azt kell szamolni mennyi ido telt el egy teljes korulfordulas alatt...
Szoval: 1 mp alatt 32768-at kell szamolni azzal a kristallyal, tehat 32768 / T * 1.72 * 3.6 adja ki a km/h-t. Nyilvan valoan a muveletek kommutativak, tehat 32768 * 1.72 * 3.6 / T is megteszi nekunk, azaz V = ~202900 / T. Ez a szam egy 24 bites neretben abrazolhato, igy vagy azon kell eltoprengeni, hogy hogyan lehet ertelmes ido alatt elosztani a szamokat, vagy tablazatos modszerhez kell folyamodni. Pl ha 5km/h pontossag elegendo, akkor max 250-ig merve 250/5 = 50 tabla elemre lesz szukseg, es egy 16 bites kereso algoritmusra. Miert 16 bites? Mert a 16 biten abrazolhato maximalis szam 65536, es a 202900-at ennyivel elosztva 3-at kapunk, azaz 3km/h-val megy a jarmu. Ennyinel meg ki lehet mutatni nullat... magyaran ha tulcsordul a 16 bites timer akkor nullaval megyunk... Tehat a tablazat tobbi eleme 16 biten abrazolhato, es innentol kezdve csak ki kell keresni, hogy a meresi eredmeny a tablazat melyik elemehez all legkozelebb... Feltetelezve, hogy a motor folyamatosan gyorsul vagy lassul meg egy egyszeru linearis kereso is megteszi...
Szia!
Köszi a programjavítást, de sajna a fordító nem fordítja le, mivel const char kar[33] = "8,20,0002,0418,37,706,25,,,0,,,0"; ennél a sornál static const szükséges azt írja. Aztán ha kijavítom akkor a while ( *kptr++ ) sorra írja, hogy *kptr++ nincs implementálva.. Annyira nem tudom mit lehetne ilyenkor csinálni, mivel nem rég kezdtem a cc5x-el való ismerkedést. Adatlapját olvasom, de nem sok derült ki nekem, hogy mi lenne a teendő ilyenkor..
const char kar[33] = "8,20,0002,0418,37,706,25,,,0,,,0"; helyett inkább így add meg:
const char kar[33] = {8,20,0002,0418,37,706,25,,,0,,,0};
Eleg fura egy fordito. Ez sem mukodik?
const char *kar = "8,20,0002,0418,37,706,25,,,0,,,0"; const char *kptr = kar;
Ezt már próbáltam, de ilyenkor sok neki a három egymás utáni vessző..
Idézet: „const char *kar = "8,20,0002,0418,37,706,25,,,0,,,0";” Ennél már nem akad fenn, de a while ( *kptr++ ) sornál ismét elakad. Error beolvas.c 69: Not implemented (The syntax is not implemented. This can be a compiler limitation)
Bocs! Itt a vesző is a karaktersorozat része? Mert akkor meg ezt a változatot próbáld:
const char kar[33] = {"8,20,0002,0418,37,706,25,,,0,,,0"};
Igen a sorozat része, mivel azokat az értékeket, amiket nem tud kiolvasni a modulom vagy nem elérhető számára a hálózatból vesszőt ír helyette..
Ezekben a formában fogadja el: static const char kar[33] = {"8,20,0002,0418,37,706,25,,,0,,,0"}; const char *kar = "8,20,0002,0418,37,706,25,,,0,,,0";
Idézet: „Ezekben a formában fogadja el: static const char kar[33] = {"8,20,0002,0418,37,706,25,,,0,,,0"}; const char *kar = "8,20,0002,0418,37,706,25,,,0,,,0";” Nezd meg disassemblerrel (vagy ha tudsz generaltass LST vagy ASM file-t a compilerrel). Nezd meg melyik mit muvel, de nekem a cc5x doksibol az tunik ki, hogy ok a const direktivat hasznaljak a rom tarolasi osztaly kijelolesere. A static-nak inkabb csak az a szerepe, hogy a fuggvenyben levo valtozod globalis teruleten tarolodik el, noha a lathatosaga csak a fuggvenyen belulre korlatozodik -- ahogy ezt az ANSI C is definialja. Amikor {"..."} van az olyan, mintha egy egy elemu string tombod lenne -- es fogalmam sincs hogy tarolja le es mi lesz belole, de lehet a stringre mutato pointer amit csonkolva beletesz a 33 elemu char tomb elso helyere... Szoval nezd meg, deritsd ki ezt eloszor. Amugy van egy CCS topic, ott lehet jobban ertenek ehhez es lehet ok nem olvassak ezt a topikot is, szoval ott is felvethetned a kerdest talan?
Rendben, köszi.
 |
Bejelentkezés
Hirdetés |
