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.

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.)

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:

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.

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.

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.

.hex fájlt nem nyel le a Proteus?

Ezt hol olvastad/honnan tudod?

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.

Gyakorlatilag minden adatlapban benne van. Pl.: PIC32MX1XX/2XX/5XX 64/100-PIN family DS60001290F-page 33.

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.

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.

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.

Oda ezt ajánlom az egyszerű szerelhetőség és a pici helyigény miatt

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!

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 ...

Kedves Fórumtársak! Adott egy 16bites előjel nélküli váltózó, amit binárisan szeretnék megjeleníteni egy karakteres LCD kijelzőn, van erre jóban használható parancs a MikroC-ben?

Helpet átolvastam, én nem találtam. Ti hogy szoktátok ezt csinálni?

Sziasztok!

Szeretnék megvalósítani egy olyan alkalmazást Windowson, ami egy PIC-cel (mondjuk 18F4550-nel) kommunikál USB-n. Nagyon egyszerű dolgokkal kezdeném, mint pl. LED kapcsolása. Egy hasonló kis projektem volt már, akkor a LibStock-ból letöltöttem egy USB CDC-s libraryt, és így virtuális soros portként "beszélgetett" a PIC-cel a Windowsos program (C#). Ez egyébként a célnak megfelel, a soros port aránylag könnyen kezelhető a PC felől, és a PIC oldalán is megvalósítható a dolog.

Van viszont ugye egy olyan könyvtár a MikroC-ben, hogy USB HID, ez ugye egy másik eszközosztály. Azt szeretném megkérdezni tőletek, hogy ezt hogyan kellene kezelni Windows oldalról? Nem tudtok esetleg valami jó kis (nagyon naív vagyok, de esetleg magyar? Persze, angol is jó...) leírást, hogy ez hogy működik? Esetleg valami specifikáció, hogy mik a kommunikáció paraméterei?
Eddig mindenütt csak azt láttam, hogy a beépített HID Terminal-ból kommunikálnak a PIC-cel, és semmi több.

Előre is köszönöm a választ!

Szia!
Szintén a libstock-on találsz DLL-t Windows-hoz leírással. Lehet, hogy csak Pascal -os de nekem jól működik. Viszonylag egyszerű.

Bővebben: Link

Szia!
Köszönöm szépen! C esetleg nincs valamerre?
Ha nincs, akkor megpróbálom ezt értelmezni és használni.

C: Goooogle: windows usb hid example

How to Communicate with its USB Devices using HID Protocol

C#: PICkit2 forrása.

Köszönöm szépen, tökéletes!

Jó szerencsét! Mikroe click-ekhez keresek konkrét felhasználásokat. Amolyan "mire" tudom használni a valóságban. Inkább link-ekre lenne szükségem, de bármit elfogadnék. Köszönöm a segítséget. Üdv.: Joe

A Mikroe-nek van "pár" modulja, ha konkretizálnál legalább néhány darabot. Kicsit fura a kérdés, mert pl. milyen konkrét felhasználási tippet vársz egy RS485 galvanikus leválasztó, vagy egy páratartalom mérő modulhoz? Utóbbi pl. növényház páratartalmának beállítására lehet alkalmas, előbbi adatátvitelhez, ahol a két oldal valamilyen oknál fogva nem lehet galvanikus kapcsolatban.

Sziasztok
Valaki tudna picit segíteni hogy lehet szoftweresen olyan pwm et csinálni ami ledenként szinenkét lehet állítani RGB fényerejét??



Ezt a kódot szeretném átalakítani.

Miért nem választasz olyan kontrollert, amibe eleve van három (vagy több) PWM csatorna?

Rendben.
Anno erre is gondoltam ha a softweres megoldás nem jönne össze.

74hc595 BLANK lábákra (3 db lábra ) rákötöttem a pic PWM lábait.
5khz futt a pwm.

Mi lenne az elképzelés??A helyes irány?

Az elképzelés és a helyes irány számolással kezdődik. Mekkora felbontást akarsz és azt milyen frekvencián.

Pl. 100 Hz-es PWM frekvencia, 0 - 100 %-os kitöltés, 1 %-os lépésekben. Egy másodperc alatt 100-szor kell végigmenni a perióduson, egy periódus 100 lépésből áll, tehát 100 x 100 = 10 kHz-es megszakítást kell előállítanod, pl. Timer2-vel. Timer2 0-99 -ig számol. Ha a számláló nagyobb, mint a kitöltési tényező, akkor a kimenet alacsony, egyébként magas.

Dióhéjban ennyi a történet. Alacsony frekvenciára jó módszer, de mint a mellékelt ábra is mutatja, eléggé intenzíven igénybe veszi a kontrollert.

Amennyiben a beépített PWM modult használod, akkor kitöltési tényező átállításához elég egy-két regisztert írni, a többi a PWM modul feladata, lehet mással foglalkozni.

Akkor maradnék HW PWM megoldásnál.
PIC18F46K22 használók.

16MHZ pörög a mikrotik .
Elképzelésem van 8x5 led ami RGB vagy is x3 120 "szin"

Ha jól emlékszem 20-16ms be bent kell maradjak egy kép leképezésébe hogy egybefűgőnek lássam.

20 000 us /120 =166us egy ledre való idő.
Vagy számoljak 1ms es idővel? Ahogy a kódomba van? Mert akkor 166us helyet 8 us lenne.


Aztán ahogy az elsö ledhez ér pwm beállítjuk és utánna megy a következő ledre és ismét.
Így gondoltam ha kivitelezhető.

Mivel kelleni fog sor és oszlop meghajtás is, nem lenne egyszerűbb MAX7219-es IC-ket hazsnálni? SPI kimenettel lehet hajtani, akár 10 MHz-es órajellel is.