Fórum témák

» Több friss téma
Fórum » PIC programozás mikroC fejlesztőkörnyezetben
Lapozás: OK   8 / 8
(#) Szárnyas válasza haffre hozzászólására (») Máj 29, 2020 /
 
A program azon részét is másold be, ahol értéket adsz a tömb elemeinek.

A Windows alatt a Ctrl+Alt és az AltGr billentyűk egyenértékűek egymással, ezért az AltGr+W lenyomásakor az Ctrl+Alt+W (ugyanígy az AltGr+G és az Ctrl+Alt+G esetében is) gyorsbillentyűhöz rendelt funkció is meghívódik, ami úgy tűnik, hogy a programban ütközik a speciális karakter megjelenítésével.
Én a ] zárójelet az AltGr+H billentyűkombinációhoz rendeltem hozzá a Microsoft Keyboard Layout Creator 1.4 programban. A | karaktert is hozzá lehetne rendelni valamelyik másik gombhoz, amire nincs definiálva a programban gyorsbillentyű. Sajnos jobb ötletem nekem sincs, a magyar billentyűkioszással nem éppen kompatibilis a program újabb változatai.
A hozzászólás módosítva: Máj 29, 2020
(#) haffre hozzászólása Máj 29, 2020 /
 
Szia, köszi a gyors választ és a gyorsbillentyű tanácsot!

A program-részlet:
unsigned tomb[] = {1,2,3,4};
unsigned tmp, ADC;
char i;
unsigned atlag (unsigned *a[]) {
tmp = 0;
for (i = 0; i <= 3; i++) {
tmp += a[i]; //4 elem összege
}
tmp = tmp >> 2; //átlag (osztás 4-el)
return tmp;
}
....
void main() {
ADC = atlag(tomb);
...
}
Ez csak egy átlagszámítási kísérlet, eredetileg több ADC mérést szeretnék átlagolni.
(mikrobasic-ben működik az átlagolás, a gyorsbillentyűk azonban ott is ugyanúgy viselkednek.)
(#) Szárnyas válasza haffre hozzászólására (») Máj 31, 2020 /
 
Ha még nem sikerült volna rájönnöd azóta a megoldásra, akkor úgy próbáld meg, hogy az átlag függvényed paraméterében ne unsigned tömbre mutató változót adj meg, hanem csak unsigned tömb típusú változót, mert a C nyelvben a tömb az eleve egy mutató, ami jelen esetben a meghívott atlag függvényed tomb nevű tömb típusú változójára mutat, tehát eleve cím szerinti paraméterátadás valósul meg.
Szerintem így már az elvárt módon kell működnie a kódonak.

Így gondolom:
  1. unsigned atlag (unsigned a[]) {
  2. tmp = 0;
  3. for (i = 0; i < 4; i++) {
  4. tmp += a[i]; //4 elem összege
  5. }
  6. ...
(#) haffre hozzászólása Máj 31, 2020 /
 
Igen, így helyes eredményt kapok. Köszönöm!
Azt nem tudod véletlenül, hogy hol lehet a mikroc-ben a gyorsbillentyűket be/át-állítani?
Sem a 7.1, sem a 7.6 verzióban nem találom.
Kösz mégegyszer, üdv.
(#) Szárnyas válasza haffre hozzászólására (») Máj 31, 2020 /
 
Szerintem nem lehet megváltoztatni a gyorsbillentyű kiosztását programban. Legalábbis én nem találtam ilyesmi lehetőséget. Azért is használom azt a módszert, amit a korábbi hozzászólásomban írtam.
(#) haffre hozzászólása Jún 23, 2020 /
 
Most, hogy -úgy, ahogy - megbarátkoztam a mikroc-vel, derült ki, hogy az általa generált coff fájlt a Proteus szimulációs program nem fogadja el, hibaüzenettel leáll, pontosabban el sem indul a szimuláció.
A hibaüzenet: Internal Exception: access violation in module 'LXLCORE.DLL' [0000EB3B].

Az mE fórumán már - évekkel ezelőtt - felvetették ezt a problémát. Az mE válasza az volt, hogy felveszik a kapcsolatot a Labcenterrel (a Proteus fejlesztője) ... bla, bla...
Mivel a probléma most is megvan, az mE-ra nem lehet számítani.
Más compilerek coff fájlját elfogadja a proteus, sőt a mikrobasic PIC16-os coff fájljait is néha, tehát a hiba egyértelműen a mikroc-ben van.
Találkozott valaki ezzel a problémával? Van erre megoldás?
A mikrobasic PIC12 és 16-os coff fájlját - ha a proteus szerint hibás volt - a cofmaker programmal lehetett átkonvertálni. Sajnos, a cofmakerem korlátos, max. 2k-s. Van esetleg valakinek aktiválója a cofmakerhez? Gondoltam, megveszem, de a fejlesztő honlapja megszűnt.
(#) Bakman válasza haffre hozzászólására (») Jún 23, 2020 /
 
.hex fájlt nem nyel le a Proteus?
(#) haffre válasza Hp41C hozzászólására (») Jún 23, 2020 /
 
Idézet:
„CMOS bemenetet nem szabad bekötetlenül hagyni”

Ezt hol olvastad/honnan tudod?
(#) haffre válasza Bakman hozzászólására (») Jún 23, 2020 /
 
A hex fájllal nincs gond! A coff azért kell(ene), mert azzal utasításonként lehet látni, hogy mi történik.
(#) Hp41C válasza haffre hozzászólására (») Jún 24, 2020 /
 
Gyakorlatilag minden adatlapban benne van. Pl.: PIC32MX1XX/2XX/5XX 64/100-PIN family DS60001290F-page 33.
(#) haffre válasza Hp41C hozzászólására (») Jún 24, 2020 /
 
Igaz, valóban ezt tanácsolják, köszönöm, hogy utána néztél!.
A gondom az, hogyha egy láb kimenetként definiálva zárlatba kerül (pl. egy mérőeszköz tapintócsúcsától), akkor elszáll(hat). Az mindegy, hogy egy kimenet a földre van kapcsolva és a plusz táppal kerül zárlatba, vagy fordítva. Bemenetként ez nem tud előfordulni.
A CMOS technológia kezdetén az elektrosztatikus kisülésre oda kellett figyelni (földelt csuklópánt), de ma már védettek ez ellen a ki, és bemenetek. Ettől függetlenül a gyártócégek, pl. Sanmina (kötelezően) használnak csuklópántot.
(#) Hp41C válasza haffre hozzászólására (») Jún 24, 2020 /
 
Idézet:
„A CMOS technológia kezdetén az elektrosztatikus kisülésre oda kellett figyelni (földelt csuklópánt), de ma már védettek ez ellen a ki, és bemenetek.”

Van, ami védett, de van olyan is, ami nem védett. Pl a Vdd -nél magasabb Vpp -t igénylő típusok MCLR lába.
Az idézet nem azt mondja, hogy egy fel nem használt láb nem lehet bemenet, csak azt, ha bemenet, akkor húzzuk Vdd -re vagy Vss -re.
Miért is ajánlják a kimenetnek való beállítást. Egy sok-sok lábú SMD tok esetének az a rengeted ellenállás bekötési nehézséget okoz. Emellett 20 - 50 ellenállás a sorozatgyártásnál idő veszteség és nem utolsó sorba költség (maga az ellenállás, a panel méret növekedés, a beültetés időigénye, hibalehetőségek stb.)

Ha lebegni hagyjuk a CMOS bemenetet, a fogadó P ill. N csatornás tranzisztorok nem a tervezett feszültség tartományban lesznek, hanem egyszerre lehetnek (többé - kevésbé) nyitva, ami tápáram növekedéshez, hőtermeléshez vezethet. Alvó kontrollernél ez a fogyasztás nagyobb lehet, mint a kontroller összes egyéb fogyasztása.
A hozzászólás módosítva: Jún 24, 2020
(#) haffre válasza Hp41C hozzászólására (») Jún 24, 2020 /
 
Amit írsz, mind igaz!
Azoknál a kontrollereknél, ahol bekapcsolható a felhúzó "ellenállás", ezt javasolom, ahol nem (pl. PIC18F26K20 A portja), ott én a jövőben a földre húzott kimenetet fogom használni.
(#) kaqkk válasza haffre hozzászólására (») Jún 26, 2020 /
 
Oda ezt ajánlom az egyszerű szerelhetőség és a pici helyigény miatt
A hozzászólás módosítva: Jún 26, 2020
(#) haffre válasza kaqkk hozzászólására (») Jún 26, 2020 /
 
A felhúzó "ellenállás" nem egy külső ellenállás, henem egy ki/be kapcsolható FET a kontrollerben.
Ha a portnak van ilyen (WPUx weak pull up) regisztere, akkor én a nem használt portnak a bemenet és bekapcsolt WPUx.Bx -t beállítást javasolom.
Ha nincs a lábra WPU és helyigény/ár kevéssé fontos, akkor én továbbra is a bemenetet és a külső felhúzó (valóban) ellenállást állítom. Ez zárlatbiztos!
(#) kaqkk válasza haffre hozzászólására (») Jún 27, 2020 /
 
Idézet:
„s a bemenetet és a külső felhúzó (valóban) ellenállást állítom. Ez zárlatbiztos!”
Ennek az alternatíváját ajánlottam Az ellenállás háló helyigénye és a nyákra tervezésének egyszerűsége klasszisokkal veri az egyedi felhúzó ellenállásokat ...
Következő: »»   8 / 8
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu