Fórum témák
» Több friss téma |
XC8-ban valóban nem működik. Gondolom valami visszafelé kompatibilitás miatt, vagy csak úgy maradt miután bejöttek az új vezérlők LAT regiszterrel.
A 16 és 32 bitesben működik. Mindenesetre magát a regiszter bitjét tudod invertálni. LATCbits.LATC0 ^= 1;
Gugli most valahogy a barátom... Meg tudná valaki mondani, hogy milyen PIC lehet az ami 14 lábú, 8 bites és a 4. és 11. lábai a táplábak?
Ezen már túl vagyok. Az a gond, hogy a tápláb helyzete fix és arra nem lehet keresni, anélkül meg túl sok a találat.
Van egyáltalán ilyen? 8, 14 és 20 lábúaknál a bal oldalon vannak a tápfeszültség lábak, a 18 lábúaknál vannak középen. Van egy-két típusnál variálás a THT és SMD tokok között de ebben a feltételben nem játszik.
2017-11-04 előttiek között ilyen PIC nincs. Ha van, csak a legújabbak között lehet, vagy nem PIC.
2017 előttieknél 1. és 14. a táplábak, a 4. a programozófeszültség. A hozzászólás módosítva: Aug 1, 2020
Üdv!
Ismerősnek problémája akadt egy automata kapu vezérlővel. A szerelő nem tökölt, panelcsere. A hiba, a szerelő szerint a vezérlő chipben van, ami egy PIC16F57-es. Mivel a hiba nem volt állandó, a kapu hol nyílt, hol nem, hol csak részben, ezért arra tippelek, hogy a chip nem halott. A kérdésem az lenne, hogy ezekben is (mint az AVR-ekben) van e olyan zár, tiltás, amitől ezeket nem lehet kiolvasni? Érdemes próbálkozni? Milyen olvasóval/programmal működik? Ha tippelnem kell, akkor blokkolva van... de gondoltam rákérdezek. SB
Szia!
Idézet: „hogy ezekben is (mint az AVR-ekben) van e olyan zár, tiltás, amitől ezeket nem lehet kiolvasni?” Igen, védetté tehető a tartalom kiolvasás ellen (én is a blokkolásra tippelek!).
Szerintem jól tippelsz. A kiolvashatóság a Code Protection bittel tiltható (0x40 cím felett 0-kat ad vissza, ha jól olvastam). De egy kiolvasást megér.
Azzal is egyetértek, hogy a chip valószínű nem halott. Sőt, azzal is egyetértek, hogy az illető szerelő volt, nem szakember. Sajnos.
Köszi. Végül megoldódott. Nem tudom hogy, a netről kimásoltam egy részletet, ami kinézetre ugyanaz, mint amit én írtam, és azzal megy a makrózás. Én is a regiszter bitjét invertálom:
#define LED1 LATCbits.LATC0 LED1 = LED1^1;. Ez egy utasítással rövidebb asm-ban, mint a tied (bár sokat nem oszt vagy szoroz).
Sziasztok!
Pic18f26k22-ben szeretnék checksum-ot assemblyben számolni. Sima 8bittel nem is lenne gond de ez ha jól értem 16bit. Példa: 0x01 + 0x04 + 0x14 + 0x08 + 0x98 + 0x03 + 0xE8+ 0x00 + 0x00 +0x08 + 0x98+ 0x00 + 0x00 + 0x00 + 0x00 + 0x00 + 0x00 + 0x01 + 0xF4 + 0x00 + 0x64 + 0x00 + 0x00 + 0xHH + 0xLL Tudna valaki segíteni?
Lehet, hogy nem értem jól a problemát, de 8 bites számokat összeadni úgy kell, hogy
1. A carry(C) bitet törlöd, elvégzed az összeadást a LO-ba, majd a C függvényében a HI byte-ot növeled vagy sem (ugrás történik, BNC, vagyis átugrod az INCF HI-t, ha nincs C). vagy 2. A C bitet törlöd, elvégzed az összeadást a LO-ba, majd ADDWFC-vel 0-t adsz a HI bytehoz (itt nincs ugrás, mindig ugyanannyi utasításciklus) Ha a kérdés arra vonatkozik, hogy a képletben a HH és LL mit jelent, az semmi különös, ugyanúgy 8 bites hexaszám. A fenti képlet végeredménye mindenképpen csak 2 byte-on tárolható. Ha csak sima checksumot kell számolnod, azt lehet 8 biten is, a felső byte-ot eldobod.
Az adatküldés megkezdése előtt töröld CHECKSUM_L és CHECKSUM_H változókat.
A küldendő adatot tedd "ADAT" változóba. Mielőtt elküldöd, hívd meg a mellékelt rutint. Az utols adt elküldése után küld el CHECKSUM_L, majd CHECKSUM_H változót is. A fogadó oldakon ugyanígy add össze az érkező byteokat, majd vond ki CHECKSUM_L-ből az első ellenőrző byteot. Ha nem billen be a STATUS,Z hibás az adatátvitel. Ha bebillen, akkor vond ki CHECKSUM_H-ból a másodk ellenőrző byteot. Ha STATUS,Z bebillen, akkor jó volt az adatátvitel.
A hozzászólás módosítva: Aug 11, 2020
Sziasztok!
Segítséget szeretnék kérni megszakításokkal kapcsolatban. Van egy pic16f887, ebben egy timer0 megszakítás ami belső megszakítás. Szeretnék egy nyomógombbal külső megszakítást produkálni, de nem tudom hogyan,hogy az interrupttok ne akadjanak össze. A program mikroc-ben íródik.
Jól értem hogy az a kérdés, mi történik akkor, ha "egyszerre" két megszakítás fut be?
Szia!
Végül is igen, de az is probléma, hogy a két meghívó függvényt hogyan készítem el.
Szia!
A nyomógomb megszakítás nem időkritikus, tehát bőven elég ha a már meglévő időszámláló függvényedbe 0.1 s időnként lekérdezed az adott nyomógomb lekérdezést. Ezzel egyben a pergésmentesítés is meg van oldva. Egyébként pedig ha megszakítás következik be, akkor meg kell vizsgálni mi okozta a megszakítást, tehát a TMR0 if bitet, ha az nem, akkor az INT0 if bitet (külső negszakitás.) és amelyik be van billenve annak a függvényét kell végrehajtani. Ha valami oknál fogva nem kerül végrehajtásra a jelzőbitek visszaállítása, akkor a megszakító rutin újból és újból lefut lefagyást eredményezve.Tehát a megszakításkor illik végigkérdezni a használt jelzőbiteket. Ha megszakítás alatt érkezik egy újabb kérelem, akkor megint lefut a megszak.rutin. üdv.: Foxi A hozzászólás módosítva: Aug 12, 2020
Beállítod pl. a PORTB megszakítást a gombot kezelő bemenetre. Engedélyezed.
A megszakítás kiszolgálót kibővíted: Az "Enter Your code here" után beszúrsz még egy blokkot: if (PBIF_bit){ ... WREG = PORTB; PBIF = 0; } Az IOC megszakítás működéséhez ki kell olvasni a PORTB regisztert, mert ez az olvasás tárolja el az új mintát, mihez a változást figyelni kell.
Köszönöm szépen! Ez az információ bővebb és gyakorlatiasabb volt
Szia!
Sajnos nem jön így ki. Felteszem a forrást hátha valaki észrevenné a hibát. Online kalkulátor kiadja a végeredményt.
Valami eleve nem kerek. A modbus eredmény nem sima összeg.
Ha megnèzed a mod 256-os végeredményt , annak más a vége, mint a crc16-osnak.
Azt sem értem ha az online kalkulátorban számolom, a 0x00-t hogy és miért számolja.
A MODBUS egyfajta CRC16 kódot használ ellenőrző összegnek: MODBUS protokol.
Szia!
Mihez számolod, hol van az eszközhöz tartozó leírás, példa ?!
Szia!
Ha megnézed a programot esetleg szimulálod ott van a példa. Az utolsó kettő a végeredmény.
A 4. oldal.Bővebben: Link
A hozzászólás módosítva: Aug 15, 2020
Hogy érted, hogy az utolsó kettő a végeredmény ?
Erről a számsorról beszélsz: F80414091F041B0000039C00000517000501F400260000 szerk.: és az utolsó 2 byte-ról...vagy ?! Ez a számsor az eszköz által kiadott ? A képen látható 6CC2-t várod és nem jön ki ?! A hozzászólás módosítva: Aug 15, 2020
Azon csodálkozik, hogy ha 16 bitesen összeadja a távirat byte-jait, nem a CRC16 -tal képzett ellenőrző összeg jön ki. Itt linkeltem a leírást...
|
Bejelentkezés
Hirdetés |