Szia!

Mivel fűtőszál lesz,ezért maradok akkor a 4 Mhz-nél.
Amiket írtál eseteket,próbáltam figyelembe venni. Azért vannak a negatív irány kezelési modulok. Ekkor nem a túlcsordult eredmények íródnak a munka számlálóba,hanem az ellentétes oldalé. Remélem sikerült érthetően leírjam.

Hello! Félreérted a dolgot. Nem a fűtés fog fűteni, hanem a meghajtó tranyó melegedni, a PWM magasabb kapcsoló frekvenciájától.
Ha már ez egy műszaki fórum, akkor legyet oly jók és írjátok le tisztességesen, hogy MHz!

Még annyit hozzáfűznék, ugyanis nem értem azt a mondatot hogy "a PWM akkor is fűteni fog,amikor nem kellene." Itt érdemes tisztázni azt, hogy a PID abban segít, hogy mindig csak azt a mennyiségű energiát szolgáltassa amennyire szükség van ahhoz, hogy az elvárt hőmérséklet legyen. Tehát elvileg akkor is szükség van fűtésre, ha a tényleges érték nagyobb mint az elvárt érték, csak kevesebbre, vagyis csak akkor nem fűt, ha egy külső energiaforrás biztosítja a teljes energiamennyiséget (Pl. besüt a nap az ablakon)

Ha nem akarod a PWM frekvenciáját asm-ben buherálni, akkor az szerint kell eldönteni a Quartz értékét, hogy mit is kapcsolsz vele, ugyanis minél nagyobb a pwm frekvenciája (4mhz oszcillátorral ez kb 4 khz és arányosan nő az oszcillátor frekvenciájával), annál jobban terheli a kapcsolóelemet (Mosfet, vagy Darlington pl. természetesen megfelelő vezérlő áramkörrel). Nagyobb frekvencián jobban melegedhet. Én elég gyakran építek kisfeszültségű motorvezérléseket. Pl. kefés DC motorhoz nekem a 4 mhz vált be, de BLDC motort vezérléséhez már inkább 20 mhz értékű kristályt használok. Mivel te fűtést vezérelsz, szerintem célszerűbb a 4 mhz.
Én is gondolkodom egy PID vezérlésen parsic-ban, de mivel a parsic az előjeles számítást nem kezeli, ezért szerintem külön kell választani tartományonként, vagyis én úgy gondolom, hogy külön kell kezelni a következő eseteket:
1: Kívánt érték nagyobb mint a tényleges érték.
2: Kívánt érték kisebb mint a tényleges érték.
3: Hőmérséklet emelkedik
4: Hőmérséklet csökken
valamint ezek kombinációit is.
Ugyanis szerintem az átfordulás akkor van amikor kivonsz egy értéket egy másikból és az eredmény kisebb mint nulla.

Szia!

Köszönöm válaszod. Quartzot mindenképp teszek majd. 20 vagy 4 megásat tegyek majd bele?
Milyen frissítési időt javasolsz? Minden tanácsra vevő vagyok. Esetleg a fent írt érték átfordulásra valami ötlet?

A teljes siker csak a konkrét berendezésen kipróbálva ismerhető meg. Ha jól látom nem használsz Quartzot, ez esetleg szükséges lehet, a kettő timer miatt. (tapasztalat) A 20ms frissítési idő az szerintem túl gyakori. Ilyen szabályzó kört még nem csináltam, elvi dolgokat tudok így hozzáfűzni...

Sziasztok!

Egy kis segítséget szeretnék kérni tőletek. Nézzétek át légyszi az alábbi Pid körös szabályzómat,hogy egyáltalán működőképes-e Ha az egész úgy ahogy van rossz,miként lehetne működőképessé tenni? Ami biztos hiba benne,hogyha a mért hőfok meghaladja a kívántat,akkor a min érték mindig átfordul és újrakezdi a számlálást a felső értéktől,ami nagyon nem jó a működés szempontjából,mert a PWM akkor is fűteni fog,amikor nem kellene. A PWM egy fűtőszállal vizet fog melegíteni.

Segítségeteket előre is köszönöm.

Üdv. Peti

A parsic kényelmessé tesz, de nem hagyott nyugodni a probléma, ezért jöhet az asm buhera, csak három sor az egész:

BCF UCON,1
BCF UCON,3
BSF UCFG,3

A lényeg az, hogy az RC.4 és RC.5 csak akkor hozzáférhető, ha az USB-t kikapcsoljuk.

Bocsánat, RC.4 és RC.5

Azt szeretném megkérdezni az okosabbaktól, hogy PIC18F4550 esetében hogy lehet Parsic-ban az RC.5 és RC.6 lábakat digitális bemenetekként beállítani

Köszönöm az észrevételeket ,megfogadom őket,mint írtam kezdő vagyok.Még egyszer köszönöm.

Nos, néhány észrevétel: Az adatsebesség az 4mhz esetén érvényes, az Uart modul konfigban pirossal írva. vagy használj 4Mhz-t, vagy 8, 16 Mhz-t, és a sebességnél azt vedd figyelembe vételkor. Pl 16MHz esetén 2400 beállított sebesség esetén 9600-t kapsz. Ez jelenleg 3600! Továbbá kiszámoltad, hogy 20ms esetén 1200-as sebességgel mennyi bit megy át ennyi idő alatt? EEPROM: Gondolom a tápfeszt figyeled és annak esése esetén az analóg bemenet kezdeményezné az írást. Ha nem használsz kijelzőt, ezt így nehéz teljesen lekövetni, hogy mi, a hiba. Pl használj nagyobb pufferkondit, kb220-470uf. Próbáld ki az eepromot így csak egy két Bit/Byte letárolásával a többi programrész nélkül. Ha a ZV-re nem kötöd rá az EEpromot, akkor használj helyette adatforrást (mint az ADC, csak nevezd el valaminek) és kombináld multiplexerrel) A sok Timer és késléltetés helyett használj egy "ötemadót" pl 20 vagy 50, vagy 100ms és ezeket osszad le ZV modullal. tettem rá fel példát. A sok idő alapu modul sok megszakítást csinál.

Hali ! van itt valaki ? Szeretnék megkérni egy hozzáértőt ,hogy nézzen már rá erre a programra.Én kezdő vagyok ezen a "szeren,,. Több problémám is van vele,1-nem tudtam megoldani,hogy kikapcsoláskor beírja zv1,zv2,zv6,zv7,zv11,zv12, értékeket.2-nem tudom miért van az hogy az uart-on átküldött 15 számláló értékéből az elsőt nem tudom venni,gyanítom hogy időzítési probléma de nem jöttem rá a megoldásra.3-szimulációban minden ok,lefordítva és beégetve viszont nem azt csinálja mint a szimulációban,pl-nem lehet kézi módon állítani az 1-es motort fel irányba vagy memória híváskor egyszerre indul az 1-3 motor. Röviden a progiról,3 motor 3pozíció megjegyzése gombnyomásra pozícióba áll egymás után 1-2-3.
Előre is köszönöm!

-- Sziasztok!

Érdeklődnék, hogy valaki próbált-e PICkit2 UART Tool eszközével és egy Parsic-ban megírt (UART-ot tartalmazó programmal feltöltött) PIC-kel kommunikációt létrehozni.

Nekem nem sikerült eddig. Két PIC egymásközt szépen kommunikál oda-vissza, de külön-külön a PICkit UART Tool-lal nem.

Nem életbevágó a dolog csak érdekességként kérdezem.

Előre is köszönöm!

Ki mondta, hogy egy megoldás van? Nekem sok eszközöm van, mind SW, mind HW terén, és mint kiderült, két másik platformon tökéletesen megoldható a feladat. A vásárolt 18f25k80 is képes rá, csak nem a Parsic-val. 2db-ot meg nem teszek bele, mikor egy 800Ft-os arduino nano képes elvégezni a feladatot, mert a fejlesztő környezet támogat mindent, ami a uC-ben benne van (minden arduino vizuál nyelv a hivatalos arduino fordítóra épül, ami teljes mértékben támogatja annak a pár db 8 bites AVR-nek minden HW funkcióját. A választással egyúttal a 16MIPS is együtt járt az összes boardon, ami nem hátrány).
Ergo ennél a projectnél Parsic kiesett. Amit azért sérelmezek, mert a Parsic használatával lehetett volna a legkisebb energiát befektetnem, és ez a legdrágábban vett (legális) fejlesztő környezetem.

A 8722 tud 40Mhz-n is járni. esetleg 2db PICel nem lehet megoldani a feladatot? ...stb... Nem tudom mi lehet az a különleges projekt, amihez csak egy megoldás van? Évek óta csinálgatok egy "baráti" cégnek kisebb-nagyobb projekteket egyedi, vagy kisebb daradszámban. Azzal oldom meg, amihez van eszközöm. Ezt értem a HW, SW és a saját felkészültségem alatt. Ami még fontos az elkészülési idő, vagy az esetleges módosítás gyors lehetősége. Továbbá az SW I2C esetén megnézném, hogy a Parsic-al nem lehetne-e 2 vagy 4 vonalat működtetni egyszerre. Az SPI az megy 2 példányban kb egy éve használom több projektben. A nemrég mellékelt példa szerint akár 4 is lehet.

A teljes ciklus sebességét nem tudom addig csökkenteni, amire szükségem van. Megcsináltam PSoc5-re a vázat, ott annyira gyors, hogy ha a teljes program realizálódik, akkor is nevetségesen alacsony ciklusidő jön ki. Csak relatíve sokat kell pötyögni. MSSP nélkül itt 10 eszközig beleférek, 16 eszköznél már nem. És én is hobbista vagyok, bár ez egy barátom cégének készül, de teljesen ingyen csinálom neki.
Nagyon nem érdekel, hogy ők is hobbiból csinálják, ui. ott az ingyenes FLProg, a fizetős, de jóval olcsóbb Embrio vagy a nevetséges árú Visuino, ahol folyamatos a support is és a fejlesztés is.. napi szinten lehet beszélgetni velük, és nem ráznak le. Jelenleg Embrioval csinálom Nano-ra, I2C már megy, és úgy néz ki, röhögve meglesz a ciklusidő.. pedig nem is asm.

Az hogy mennyi pénz nekik meg "nekünk", ez két külön dimenzió. Ezt gondolom hobbi szinten csinálja, mert ebből nem lehet ott (N.o.) megélni. Egy ilyen képzettségű szakember(mérnök) simán megkeresi a 5-8e eurót. A száz euró nagyságrend neki 2-3 óra munka... Erről ennyit. Nekem nem okozott még gondot, hogy az I2C-s eszközt milyen úton kezelem, kimondottan jól jött a szabad láb választás lehetősége. Zárójelben jegyzem meg, pár éve egyik ismerősöm több cuccot készített I2C-s eszközökkel, C-ben írta a progikat és nyílván a MSSP modult használja, máig is néha-néha lefagynak. Nyilván az Ő hibája, de az SW-vel ilyen nem történt még velem az elmilt 9 ávben! Kérdezem: most, hogy HW vagy SW emiatt mit nem tudsz megoldani?

Ma megjött a válasz Vitotól, a szokásos remek support:

"This is no problem.
The hardware MSSP is planned for the future. Not implemented now.
Because there are no big advantages to the MSSP and in Software (Parsic) it works with each PIC at each pin. At the moment, this is more important."

Hát ma már kifakadtam és megírtam neki, hogy marhára nem ezt a hozzáállást várnám ennyi pénzért, mivel ennél olcsóbb, sőt free programjaimnak sokkal jobb támogatása van. Gondolom le se fogják szarni, mivel ezek szerint nekik ez így tök jó, hogy semmit nem kell csinálni vele.
Ez egy jó tanuló pénz volt, ez a program ennyit tud, nincs benne több potenciál. Ha többet/jobbat akarok, nekem kell váltani.

Igaz, pl. PSoC 5-ös sorozat nagyon jó HW, és kb. a PIC18f8723 árával egyezik, holott használhatóságban össze sem lehet hasonlítani, annyival jobb (számomra, de ez szubjektív, és nem vita indítónak szánom). Csak az megint egy másik uC, másik fejlesztő környezet. Ahány project, annyi fejlesztő környezet használata nem jó, nincs idő kiismerni se a procit magát, se a környezetet. Túl sok idő.
A Parsic nekem nagyon tuti lenne, ha szabadabb kezet adna, ahogy Proli is mondta, vagy rendesen fejlesztenék. Így a support (hiánya) miatt elég soknak tartom utólag az árát. Az MSSP-s kérdésemet múlt héten feltettem mindkét e-mail címen, válasz persze semmi, a HW szorzást már nem tudom hányszor megírtam nekik..
Mondjuk szerencsére éppen te szoktál itt egy-két trükköt mutatni, ami elég jól használható, és ezt köszönjük!

Ezzel nagyon egyetértek! Maga lenne a kánaán, több szinttel ugrana fel azonnal a program használhatósága! (A makró ezt azért nem helyettesíti).

A 16 db I2c-s eszköz ha egy "család" cím szerint, akkor nagyon egyszerű a P4-el megoldani még SW módszerrel is. Voltak és vannak is mindig akadályok számomra is a rendelkezésre álló eszközök tekintetében. Általában átfogalmazom, továbbá újra átfogalmazom a projektet, hogy milyen SW és HW megoldásokat tudok biztonsággal használni. Sokszor a filléres perifériákban gondolkodunk, meg a legolcsóbb processzorban. A végén meg fél évet szórakozunk vele mire elkészül. Ez még hobbi esetén is "elgondolkodtató". Ha rászánunk pár ezer Ft többletet a HW-re, esetleg másik megoldásra, töredéke idő alatt elkészülhet. Nem is beszélve arról az esetről, ha valakinek anyagi (vállalkozási) érdekeltsége is fennáll egy adott projekt esetén. Ezekből "az utcákból" már néhányszor megfordultam. Más- (Proli007-nek): A macro az valójában adott esetben egy önálló modul, tetszőlegesen lehet használni másik projetkben, ehhez megfelelően kell elnevezni a ki-be meneteket és a változókat. Lásd, RTCC példa fentebb. Továbbá ASM betétet is tehetsz macroba...stb.

Hello! Igazán jó az lenne, ha nyitott architektúrás lenne a program, és magad is készíthetnél modulokat. Mint ahogy egy "normális" nyáktervezőben is képes vagyok alkatrészeket generálni és nem kell túrni a hálót..

Semmi előnye nincs azon kívül, hogy a fejlesztőknek ez így nagyon kényelmes. Pl. még a hardveres 8 bites szorzást is képtelenek belerakni sokadik kérésem ellenére is a PIC18-as szériába, kézzel kell mindig belemaszatolni.
Nekem most nagyon jól jönne a HW I2C, 16db I2C eszközt kellene kezelni, miközben rengeteg más feladata is lenne a uC-nek, és nem túl nagy sem méretre, sem sebességre. SPI meg nem kell. Épp azért vettem a progit, hogy ne kelljen asm-ban túrkálni, de mindig kiderül, hogy valamiért kell..

Biztosan meg van az előnye, ha az SPI és a I2C is SW. Gondolj bele itt még nagyon sokan régebbi PIC-eket is használnak. Továbbá, egy példát mellékelek, ott egy programbn megy 2db SPI és egy I2C ott is jól jön ez a megoldás. Ha belegondolunk arra a rengeteg HW változatra, amit a MC csinál, képtelenség lenne minden chip-et minden feladatra alkalmassá tenni a Parsic alatt. Továbbá, a P4 a P3.60-utáni fejlesztés, ott még a régi chipek voltak előtérben, van belőlük itt is...Én nem látom a hátrányát még, majd talán ha SPI va gy I2C -vel akarok egy CNC gép encoderét kezelni, akkor jól jöhet az a néhány us.

"Mint ahogyan azt már mindenki tudja,..." A Parsicban a BV modul helyett egyszerűbb esetekben használható az adott változó egy bitjére utaló jelölés, ponttal tagolva. Pl VALX.3 (mindkét irányban) Ez lehet akár egy kapu bemenete, stb...vagy a példában szereplő módon is...

Nahh, megvan, a program kissé szétesett, az első, CD-s setup + 4.15.6.16 után működik a makró. De az eredeti problémám maradt, a képen látható, hogy csak software I2C van (az is csak úgy, ha kézzel írom be a kivezetést, a HW-es kivezetéseket fel sem ajánlja), holott a 8722 (is) tudja a HW I2C-t is, csak az MSSP modult kellene konfigurálni, mert vagy SPI vagy I2C lesz hardveresen. De a program nem is ajánlja fel. Szép szürke. És az MSSP-s PIC-ek esetében mind így van. Nekem viszont HW I2C kellene. Erre ötlet?

Most telepítettem újra a 4.15.6.16.-ot, ez a honlap szerint a legfrissebb. Makró nincs, hibajelzés van. Én is ezt az e-mail címet használom, ha valami problémát vagy fejlesztési javaslatot jelzek, de sosincs érdembeli reakció.

Most hirlelen ezt találtam, az alapján amkor abbahagytam. ha előbbre jutok akkor ide felteszem. Ez le is fordul...

Én az összes Updatet lementem előtte, mielőtt futtatom. [infokukacparsic.de] a tényleges fejlesztőnek az elérhetősége. eddig minden valós problémára kaptam választ, vagy a következő update tartalmazta. Azt nem állítom, hogy azonnal válaszolt, de egy héten belül. Néhány hónapig nem használtam a Parsic-ot mert egy nagyobb PLC-s projekt lekötött, az RTCC-s progit nekem is most kell újragondolnom...