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

A gyári példa DS1307? Mert azt nekem most nem tölti be, mondván, hogy makrót tatralmaz..??
Korábban már egészen biztosan használtam. Most a legújabb progit ismét felraktam, mert a korábbi átváltott németre és sehogyan sem tudtam angolra bírni. Most meg nincs benne a makró funkció!!?? Registry-ből kiölök minden korábbi, programra vonatkozó utalást, akkor sem. Mikor elküldök a fejlesztőknek egy ilyen hibát képernyő mentésekkel, mindig kapok egy korábbi verziót, hogy próbáljam ki. Ugyanez, ha más hibát vélek felfedezni, ami nem program, hanem uC. Már bánom, hogy megvettem a programot, mint a kutya, amelyik kilencet kölykezett. Nem is maga a program miatt, az nagyon jó koncepció, hanem a nem létező support miatt, ami miatt állandóan böngészni kell az adatlapokat..

8722-t használok. Az Spi az megy 2 példányban is egyszerre (MAX6675-t olvasok 2db-t) mindkettő 3-3 lábat használ el. Az I2C-re van egy példa a DS1307 RTCC-vel, ha jól emlékszem ez SW megoldás (?) Pár hónapja próbálgattam akkor olvasta az időt. Előzőleg meg kell konfigurálni a Help szerint az I2C folyamatot írásra és olvasásra is és le kell menteni. Ha lerakod a modult ezt kell megjelölni, olvasásra és írásra is. Hamarosan előveszem újra mert elkészült az RTC-s nyák.

Az MSSP modult tartalmazó 18f uC-k esetében hogyan lehet bekapcsolni a programban az I2C modult? Lerakom az SPI base modult, az él az adatlap szerint. De ha I2C base modult rakok le, az nem. Akkor sem, ha őt teszem le elsőnek, és nincs SPI modul. Se lábat ne lehet kiválasztani, se a software/hardware kiválasztás nem aktív. Próbáltam a 18f25k80-at, a 18f8722 és 23 uC-ket, de nem jövök rá miként lehet aktiválni. Vajon MSSP esetén nem támogatott az I2C, vagy csak én nem találom a módját? Megvettem a 18f25k80 chipeket, és most figyelek, hogy nem tudok I2C-t használni..

A táblázat csak a memóriát "terheli", de gyors tud lenni. A mérésnél inkább leredukálom egyszerű matematikai műveletekre. A referencia feszültség megválasztása, ellenállásosztó, mintavételek száma és utólagos rotálással általában megoldható.
Pl. 0-5V jelet leosztani 0-2V-ra, 2048mV referencia (így 0-1000 az eredmény, 10 bites AD esetén), kijelzésnél utolsó digitet nem kell kijelezni.

Az ADC eredménye 8 bites felbontás esetén 256, 10 bites felbontás esetén 1024 és 12 bites felbontáskor 4096 különböző állapotú lehet. Ettől jóval egyszerűbb és ésszerűbb is a számolás.

8 bites felbontás esetén kb. 0,39 %-os felbontást lehet elérni, végkitérésen így 100 % helyett 99,45 % -ot fog mutatni. Ha 0,3922 -vel számolsz, akkor végkitérésen 100,011 %-ot fog mutatni.

10 bites felbontással kb. 0,0978 %-os felbontás érhető el, végkitérésen 100,0494 /-ot fog mutatni.

Túl sok matematikai művelet nem kell. ADC értékét megszorzod 39 -cel (8 bites felbontás használata esetén) majd osztod 100 -zal. Így 0,39 %-os felbontású mérési eredményt kapsz, a tizedesjegyeket eldobva, tehát mindig lefelé kerekítve. Kijelzés 0 - 99 % -ig mehet el.

Ha nagyobb felbontás kell, akkor a feniek alapján nagyobb számokkal kell dolgozni.

Sziasztok!
ADC jelének a feldolgozásakor melyik lehetőség "terheli" meg kevésbé a PIC-et?
1. különböző matematikai műveletek sokaságával létrehozom az ADC értékéből a számomra hasznos, LCD-re kiírható értéket (pl vízszint kijelzése 0-5V-ból 0-100% kijelezhető értékké alakítása)
2. egyszerű előformázás után csak beillesztek egy táblázatot és a végeredmény rögtön a kívánt érték.

Flowcode v5-tel kezdtem ismerkedni. Találtam pár oktatóvideót. Mindkét rendszernek megvan a maga előnye. A flowcode nagy méretben átláthatóbbnak tűnik. Pillanatnyilag játszom. Elleszek vele egy darabig. Még egyszer köszönöm a segítséget!

Flowcode-ot lényegesen könnyebb kezdőknek használni, mint bármi mást. Nem árt némi programozói alapismeret. Ha megvan, kb. gyerekjáték a használata.

A Parsic-ot megtanulni tökéletes a 3.56 verzió. Szerintem vegyél egy olyan processzort, amit támogat a te verziód. Én a PIC16F877A-t használtam. Ezt javaslom neked is. Hogy mért, ha elolvasod ezt a topicot, akkor te is rájössz. Próbáltam a Flowcode-ot, nekem nem jött be. A Parsic azért szimpatikus, mert elég sok készüléket javítottam, amelyek logikai kapukkal voltak megvalósítva, ezek analógiájára könnyen tudtam a gyakorlatban jól használható vezérléseket csinálni és ami fontos, rövid idő alatt. Asm-ben egy hasonló applikáció fejlesztése jóval több időt vesz igénybe. Most már áttértem a négyes verzióra, de kezdetnek jó az ami neked van.

Mivel nem tudom mit szeretnél csinálni a uC-vel, mennyi időd/energiád/kereted van rá, így ezen ismeretek hiányában nem tudok javasolni semmit.
Illetve azt, hogy mivel ez nem parsic, máshol folytassuk.

Hardverkulcs? Pill. nincs 70e-m, így a v4 téma pillanatnyilag pihen.
Tudom, hogy nem lehet megkerülni a asm ismeretét. De valahogy nem tudom leképzelni, hogy alacsony szintű nyelvvel valaki összetett dolgot fejlesszen. Inkább a hibakereséshez hasznos.

Melyiket javaslod?
1. MPlab->asm
2. Régen picit szórakoztam C-vel. Úgy tudom van PIc-re C
3. Amennyire utánaolvastam van egy flowcode nevű program. Grafikus. Azzal is ugyanitt járnék?

A 3-as sorozat még teli van hibával. (A 4-est legalább hébe-hóba javítgatják).
A 4-esből nem fogsz találni törtet, hardverkulcsos és még nem láttam törést hozzá. 70E Ft körül van, és ha tényleg használni akarod, jelenleg nincs más megoldás a vásárláson kívül..
Viszont ha ezt akarod használni, nem árt, ha az assembly nyelvvel tisztában vagy, a külső IC-k kezeléséhez kellhet a saját rutin + a fordított kód megértése, hogy be tudd tenni a saját asm forrást anélkül, hogy a meglévő kódot borítanád (pl. nem célszerű a saját asm betétben várakozni, vagy megszakítást babrálni, stb.). Fentiek tudatában, ill. látván, hogy a szimpla asm fordítás sem megy, nem biztos, hogy ez a te programod.

v3.56. Keresek újabbat. Esetleg van lelőhely?

Idézet:
„Couldn't locate build tool. Check tool locations.”

Nem találja a fordítót sem....

Benne van a 16F870. Ha nem találod, valószínűleg valami régi tört verziód van.