Fórum témák
» Több friss téma |
Nálam ez úgy mokodott, hogy mplabx ipe elindit és úgy dugtam rá a pk3-at, hogy nyomva tartottam a kis gombot ami rajta van.
Utána már felismerte és tudtam használni.
Olyan példánnyal küzdök, amit valami szélütés ért és a következőket csinálja:
Nem kapcsolódott hozzá sem az MpLab sem az MpLabX sem a Pk3 még akkor sem, ha a gombot lenyomva csatlakoztattam az USB -hez. Kiolvashatatlan volt. Törlés után kiválóan lehet programozni, de semelyik általam ismert firmware -t beleírva sem kapcsolódik hozzá sem az MpLab sem az MpLabX sem a Pk3 még akkor sem, ha a gombot lenyomva csatlakoztattam az USB -hez. Valamelyikkel (most nem emlékszem melyikkel) az USB eszközöknél megjelent valami. A PID és a VID jó volt, HID eszközként nem lehetett megtalálni. A hozzászólás módosítva: Dec 13, 2018
Sziasztok.
Rég óta az MPLAB IDE v8.92-őt használom Pickit3 programozóval. Aztán ezt felraktam egy laptopra is és azon is jól működött. Viszont ezek után a PC-n már nem látja a programozót, a laptop pedig felismeri a programozót, de a Pic-et nem látja. MPLAB X IDE v5.1-el viszont működik. Nem tudom, hogy a laptopos használat okozhatta-e. Két különböző típusú (18F1330 és 10F220) Pic-el teszteltem, újakkal is. Találkozott-e már valaki ezzel a problémával és van-e rá megoldás?
Az MpLabX 5.xx eltérő programot tölt le a PICkit3 -ba, amivel a régi MpLab8.vv nem tud együtt működni.
És ezt a régi MPLAB v8.nn nem tudja visszaírni, hogy újra jó legyen?
Sziasztok!
Új problémával találkoztam a mikroc-ben. Szorzást szeretnék elvégezni több számmal: int i; long int j; j=i*24*3600; ezt a szorzást hibásan végzi el. A j=i*86400; hibátlan. Miért?
Tippre azt mondanám, hogy a "j" típusát rosszul határozza meg és az int mérete miatt túlcsordul. A 24 és a 3600 is belefér az int16 határaiba, viszont a 86400 már túllóg rajta. Amikor az első verziót próbálod, akkor szerintem int16-nak deklarálja a változókat és mikor összeszorozza, akkor túlcsordul. A második esetben viszont látja, hogy túllóg az int16-on, ezért int32 lesz, amibe viszont vígan belefér.
Az elég durva lenne, ha fordító futási időben a PIC-el számoltatná ki a 24*3600 értékét.
Mikro C, ki tudja.
A legegyszerűbb tudja az ember, hogy nem fér el a szám. Ezek miatt nem szabad bízni egyik fordítóban se. Vagy castolni az i-t (longra) vagy 24 vagy 3600 mögé egy L és már longban is számol.
Sziasztok!
Azt hiszem meg van a megoldás. Típus konverzióval kell kiegészíteni műveletet:tehát j=(long)i*24*3600; és az eredmény hibátlan. Viszont a j=(long)(i*24*3600); is hibás eredményt ad. Csak az előző formátum ad jó eredményt. A kérdésben bemutatott j=i*86400; azért adott jó eredményt, mer 86400 maga is long.
Egyébként a te javaslatod is jó eredményt ad.
Idézet: „azért adott jó eredményt, mer 86400 maga is long.” A 24*3600 is long.
Nem tudom feltűnt-e, de már rögtön long int a j változód ezen a képen. Próbáld meg, hogy int16-nak definiálod és rögtön be kell, hogy jöjjön a hiba, amit felvetett.
Nekem itt most csak VisualStudio c++ van felrakva, ahol short int-ként kell definiálni az int16-ot, ez ne zavarjon meg. A hozzászólás módosítva: Dec 17, 2018
Szia!
Idézet: „A 24*3600 is long.” A szorzatuk igen, de egyenként egyik szorzandó sem volt long, ezért az eredmény is int-ben képződik ( és az íródik be a long j-be!)! Ezért kell az egyiknek longnak lennie vagy kényszeríteni rá ( cast!) ! A hozzászólás módosítva: Dec 17, 2018
Miért kellene int16-ként definiálni?
Bővebben: Link
Akkor megint elmondom.
Az eredeti felvetésben a típus int volt. Ez a te általad is mellékelt táblázat szerint 2 bájt hosszú, azaz INT16. Ha így definiálod, ahogy az eredeti kérdés szólt, akkor láthatod, hogy előjön a hiba, mert nem kasztol rögtön a fordító, mikor azt látja, hogy int16 = int16 * int16 * int16, csakhogy az eredmény már nem fér be az int16 határba. Ezt te megmutattad, hogy ha úgy csinálod, hogy int32 = int16 * int16 * int16, akkor nem jött elő a hiba, mert belefért. Erre írtam neked, hogy próbáld ki az eredeti kérdést, s azután rájössz mi volt a gond. S egész pontosan az eredeti kérdés úgy szólt, hogy miért nem működik az int16 = int16 * int16 * int16 úgy, ahogy szeretné, ha az int16 = int16 * int32 viszont megy. Ugyanis ez utóbbi esetben a fordító automatikusan kasztol és az int16 méretű j változó helyett int32 méretű lesz belőle. A hozzászólás módosítva: Dec 17, 2018
Itt long int, azaz 32 bitesként deklarálta...
Akkor azt elnéztem. Ezzel együtt a gond az, hogy mikor kasztol a fordító. Mert az [int32](int16*int16*int16) eredménye az lesz, hogy int32-re kasztol egy int16 méretű számot. Ugyanis előbb történik meg a szorzás (aminél ugyebár nem fog kasztolni, mert csak int16 számok vannak benne), majd utána kasztol int32-re. Ha viszont a szorzáson belül bárhol is van már egy kasztolt int32 szám, akkor az eredmény is int32 lesz.
Ott egy kommutatív kifejezés van, a konstansok szorzásával kellene kezdeni, ezek után castolni az i-t.
Az meg nonszensz lenne, ha az előbbit a PIC-el végeztetné, odaírnál három konstans float szorzatot és megtelne a PIC.  Idézet: Szerintem az lenne a nonszensz, ha ezt engedély, ill. utasítás, azaz tudtom nélkül csinálná ( jól jön, hogy pl. egy int-ből csak a belevalót teszi a byte-ba és nem cast-olja figyelmeztetés nélkül „ezek után castolni az i-t.” !) szerk.: A PIC-el történő szorzásról senki nem beszélt ! ! A hozzászólás módosítva: Dec 17, 2018
Sziasztok!
Pic eeprom jába szeretnék adatokat írni és onnan visszaolvasni. Annyi már kiderült, hogy a pic eepromja bájtonként tárolja az adatokat. Tehát, ha egy int számot írok bele, azt két bájton fogja tárolni, pl:2018-at ami hexadecimálisan 07 E2 úgy fogja tárolni, hogy az 07 számot egy bájton és a E2 számot a következő bájon. Vissza olvasáskor úgy járok el helyesen, hogy veszek egy int változót, majd ebbe beolvasom a 07-t majd az << operátorral eltolom 8 bittel ezzel elkerül a felső bitek helyére, majd beolvasom az E2-t a változóba és megkapom a változóban, az eepromban tárolt számot. Helyes az elgondolásom?
Igen, csak byte-onként tudod elmenteni, ill. visszaolvasni, de a byte-ok helyére íráskor és olvasáskor Neked kell figyelni !
Idézet: „veszek egy int változót, majd ebbe beolvasom a 07-t majd az << operátorral eltolom 8 bittel ezzel elkerül a felső bitek helyére,” Ez idáig OK, Idézet: „majd beolvasom az E2-t a változóba és megkapom a változóban, az eepromban tárolt számot.” Ha "csak" beolvasod, akkor felülírod, hozzá kell adnod, hogy a magasabb helyiértékű byte-ot is meghagyd a helyén !
Én viszont nem így olvasnék az eeprom-ból.
8 bit emlékeim szerint nem olyan effektív a bit tologatás én. Az int-re csinálnák egy byte-os pointer és címzéssel olvasnék
Az u_n_i_o_n -ból az aláhúzások törlendők. A fórum motor miatt kellenek, ha egybe írom a kulcsszót, üres lesz a hozzászólás. A hozzászólás módosítva: Dec 18, 2018
Köszi! Majd átrágom magam rajta. Most még nekem elég zavaros. De remélem kitisztul majd.
Sziasztok!
PicKit2-vel PicKit V2.61-es szoftverrel miért nem tudom programozni a PIC16f1825 -ös mikrovezérlőt? Régi lenne a szoftver? Ha igen, akkor mivel tudom megoldani?
Üdv!
Olyan 8 bitest keresek aminek van hardveres szorzó/ósztója. Van valami ami alapján ez kiderül? Vagy pl. a bővítettekre (F1* család) ez elmondható általánosan? Olyan mikro kellene amiben ez megvan, plusz van EEPROM-ja(minimális) és egy UART, egy timer meg egy digital IO kell, hogy legyen benne. Ha nem kellene EEPROM akkor 32 bitest választanék, de azokban meg EEPROM nincs. Vagy esetleg valaki tud olyat amelyikben van? szerk: Bocsánat. 4IO, nem kettő. A hozzászólás módosítva: Dec 19, 2018
A Pk2devicefile.dat -ot kellene lecserélni V1.62.14 verzióra.
|
Bejelentkezés
Hirdetés |
! 
