Hm .... Logikusnak tűnik ... de mégis bekavar valamit ...
Az LDC kijelző frissítésén látszik, hogy valami változik ha 500Hz-ről felteszem 20kHz-re ...
Timer1-el vezérlem, ami 1ms-ként generál megszakítást, megszakításon belül ezt számolom, 100 megszakítás után főprogramból megy a kijelző frissítése, és "hullámzik" az LCD

Rájöttem hol szúrtam el!

Ez benn maradt a programba, mert azt hittem engedélyezni kell... Igaz, a megszakításban nem csináltam semmit (üres volt), de mégis alaposan visszafogta a procit.
Mióta nincs engedélyezve a Timer2 interrupts, azóta mindegy milyen frekit állítok be a PWM-nél!
Ez a Hardverből megy dolog vezetett rá a megoldásra. Köszönöm!

Olyan feladatot szeretnék megoldani, hogy PIC-el mérek hőmérsékleteket, és ezeket az értékeket szeretném hálózaton keresztül (pl ESP8266 wifi modul) számítógépre küldeni, és a számítógépen egy web böngészőn megnézni.

Sok sikert hozzá!
Ugyan nem értem pontosan mit is akarsz, de örülünk hogy próbálkozol.
Csak megjegyzé képp:
Nem értem miért kéne a mért adatokat számítógépre küldeni, ha úgyis webböngészőn nézed?
Akár ey ajaxal a honlap közvetlenül lekérheti a mért értéket anélkül hogy látszana hogy az nem a szerverről jön.

Ja ... bocs .... A lényeget hagytam ki!

Hogy álljak neki?
Csinált már valaki ilyesmit?

Csináltunk, és sokkkkkal bonyolultabb, mint a PWM frekit beállítani.

"Hogy álljak neki? "
1. Google: ESP8266 getting started vagy ESP8266 tutorial
2. esp8266.com fórum látogatása
3. esp8266.com/wiki/ tanulmányozása.
4. nodemcu.com felkeresése, tanulmányozása, magas tetszésindex esetén nodemcu firmware telepítése.

A 4. pont miatt nem sok értelmét látom a PIC belekeverésének. Interaktív webszerver mintapéldát itt találsz. Ha keresgélsz a neten, ThingSpeak mintapéldákat is találsz.

Köszi! Ezt megérdemeltem!
De legalább tanultam a hibámból!
Ha mindig csak olyant csinálok amihez értek, akkor nem fejlődöm!

Ha mondjuk lenne egy mintaprogi, amin átrághatnám magam, az is sokat segítene...

Egyszerűbb lenne-e lényegesen a dolog, ha vezetékes LAN kapcsolat lenne?

Sajna ki kell egészítenem még egy ponttal:

0. Megtanulni angolul

Olvasd már végig, amit előző hozzászólásomban írtam!
Nem.

Angol? Addig örülj, amíg nem kínai, japán vagy koreai leírásokból kell kisilabizálni a tudományt! Már nincs messze...

Természetesen végig olvasom amit írtál!

Az a baj, hogy nekem az angol is kínai!

Mintaprogiból meg próbálok CCS-C keresni, idáig nem sok sikerrel...

Ha a CCS C-hez ragaszkodsz: Ez a mintaprogram CCS C nyelvűnek tűnik (Pic18f4550 és CCS C 5.025 van említve).

Továbbra is fenntartom, hogy az ebben a hozzászólásban (a VÉGÉN) adott linken található NodeMCU mintapélda százszor egyszerűbb, mint a PIC mikrovezérlővel és az AT parancsokkal való kínlódás.

Köszönöm, ezen a programon el csámcsogok egy darabig, aztán meglátom merre tovább!

Van egy 4x20-as kijelzőm, azon szeretnék megjeleníteni adatokat, de zabálja a ROM-ot.
Mit kéne máshogy írnom hogy kisebb legyen a kód?

Valami hasonló kiírások lennének, 4-5 képenyő:

A printf eleve sok memóriát foglal, ha még float típust is akarsz kiíratni, akkor főleg. Első körben próbáld olyanra megírni a programot, hogy ne legyen benne float típus, ezzel nyersz egy csomó helyet és sebességet. Utána ha ez még mindig nem elég, akkor muszáj lesz a printf helyett saját implementációt készíteni, ami csak a szükséges változótípusokat kezeli.

Átlakaítottam a float típusokat, signed long-ra de így is kevés a ROM.

Ez mi is pontosan?
Első olvasatra ez meghaladja a programozói tudásomat.

Lehet, hogy inkább PIC-et váltok, "hardweresen" nem kell sok átalakítás a PIC16F887-et kicserélni egy PIC18F4550-re.

Kicseréltem a procit.
Belső oszcillátort használok, elvileg 8MHz-re van állítva de úgy tűnik lassabban megy.
Timer0-val csinálok egy időzítést, amivel vezérlek egy kimenet váltását, elvileg 1mp alatt kéne váltania (16F887-el rendesen csinálta) most viszont kb 4mp alatt vállt.




Kell még valami mást is állítani, vagy hol keressem a hibát?

Azt azért jó olvasni hogy ROM 21%

Van egy probléma aminek nem találom az okát.

Az EEPROM-ba szeretnék írni... Amíg a beolvasando_erzekelo változó értéke 1 vagy 2 addig nincs is semmi gond, de amikor 3 akkor összesen 10 memória helyet ír át, beírja a megfelelő helyre az adatokat, és az előző adatcsomag utolsó két adatát felülírja az új adatcsomag első 2 adatával.
Ha 4 akkor már 12-t változtat 4 byte-ot az elötte lévő adatokból ír felül.
Ez mitől lehet?

Szia!

Az EEPROM-okba az adat egyesével vagy csomagokban mehet. Ha csomagba küldöd, akkor csak bizonyos adat mehet egymás után újabb cím kiküldése nélkül, mert különben újrakezdi az írást! Esetedben úgy látszik 8 adat lehet a lapméret, ha ennél többet írnál, akkor a belső számlálója nullázódik !

Minden írásnál kiküldöm a címet is!

18F4550 csak bájtonként tudja írni a belső eepromját.

Na, rájöttem csodák nincsenek! Ugyan azt a programrészletet 2-szer írtam meg, két különböző függvénybe, így 2-szer csináltam meg a mentést. A gond csak abból volt hogy az egyik helyen 8 byte-al a másikon 10-byte-al toltam el az írást ...

USB kapcsolatot próbálgatok ...

de csak néha működik...
Betöltöm a progit a PIC-be, elindítom ... Windows felismeri - COM8 ... PUTTY csatalkozik ... jönnek mennek az adatok ... egyszer csak windows csipog USB kapcsolat megszakadt, COM8 eltűnt. PUTTY megállt ... aztán windows csipog hogy talált valamit, majd csipog hogy lekapcsolódott az a valami, majd fel ... majd le ... Majd látja a COM8-at de PUTTY nem csatlakozik hozzá ...
Mi lehet a gond?
Próbáltam a késleltetést kivenni hogy az usb_task sűrübben fusson, de úgy is ugyan ez a hibajelenség. Tényleg, milyen sűrün kell futtatni?

Bocsi! Megoldódott! Nem a programmal volt a gond!
Két USB kábellel próbáltam korábban, mindkettővel ugyan az volt a hiba, ezért nem gyanakodtam kábelgondra ...végül egy hármadik, rövidebb kábellel is megpróbáltam, és hibátlanul megy!

CCS C-hez nem értek, de a Full speed USB előírásaiból következik, hogy lekérdezéses módban elég sűrűn, 1 ms-onként kell tojózni az USB-t. Megszakításos módban már sokkal kevésbé izgalmas, inkább arra kell ügyelni, hogy időben kiürüljenek a bufferek.

Merem remélni, hogy alapértelmezetten a megszakításos módot használja a CCS C USB library.

Ment egy darabig ... Most megint kezdi!
Néha felismeri, máskor meg nem.

Próbáltam a késleltetést változtatni, kitörölni ugyan az a jelenség.

Valahol a usb_cdc_init(); usb_init(); nál molyol a program mert a LED-et sem villogtatja.

Nem tudom hol keressem a hibát.

Kapcsolás hogy néz ki? VUSB lábon a 470 nF rendben van? (Nekem volt már szakadt a bekötése, s az csinált ilyen majdnem-működés állapotot). Minden VDD és GND láb be van kötve?

MCLR lábon van egy felhúzó, 20MHz kvarc + 2x15pF, 2db VDD és 2db GND bekötve, 1db 100nF a táplábak közé, meg egy USB B aljzat, és 1db 680nF a Vusb lábon.

Egy logikai analizátor segítségével (Saleae logic) sikerült megállapítanom, hogy amikor megszakad a PC-vel a kapcsolat akkor a D- láb magas szinten van és nem is változik a későbbiek során, pedig a D+ lábon válltozik a jelszint.

Azt hogy tudom megállapítani, hogy miért van a D- on folyamatos L szint?
A PIC tarthatja magas szinten, vagy a PC? Mondjuk más eszköz a PC USB portján hibátlanul működik, szóval ott a hardwer hibát kizárnám. Okozhat-e ilyen gondot egy rossz meghajtó driver?

Előfordult már, hogy meggyűlt a bajom az USB csatlakozókkal:
- USB mini-B csatlakozó egyik-másik érintkezője begyűrődött.
- USB-B csatlakozó (vagy a környéke a panelon) kontakthibás lett.

Kipróbálhatnád a mikrovezérlőt a Microchip MLA valamelyik USB mintaprogramjával! A Device - HID - Custom Demos például kihagyná az USBser.sys drivert, az Device - CDC - Basic Demo pedig ezt a drivert tesztelné (az mchpcdc.inf beetetésére azért szükség lehet az eltérő PID miatt).

A PIC18F4550-hez való előfordított (HEX) demók a Precompiled Demos/PICDEM FSUSB mappában vannak. Az említett mchpcdc.inf "driver" (valójában csak információs fájl) pedig a Tools/USB CDC Serial Demo mappában keresendő.