Azt írtad, a program memóriában vannak az adatok. Mi az akadálya annak, hogy oda már rendezetten kerüljenek? 40 darabot nem lehet több 2 perc idő fejben sorbarendezni, és úgy betenni a programba.
Miért nem lehet betűket ASCII kódjuk alapján összehasonlítani?

Köszi mindenkinek. Azért leírom, hogy sima assembly a nyelv, PIC18 ra. Az adatok felépítése viszonylag egyszerű, gyakran várok Ok, ERROR, READY, BUSY stb -t, de várhatóan ettől jelentősen hosszabbak is előfordulnak.
Tényleg nem nagy idő lenne sorba rendezni az adatokat, csak ügy meglehetősen romlik a program olvashatósága.
Akkor megpróbálom a jellemző részeket megkeresni bennük és azokat ASCII alapján összehasonlítani. Mondjuk ahogy most elképzelem elég sok ugrást fog tartalmazni a kód. Például ha látom, hogy az első karakter egy "E" akkor tudom, hogy ERROR. De ha pl. egy "Z" akkor tovább kell vizsgálni a második karaktert hogy ZERO vagy ZITA jött -e.
És így tovább ha szükséges ki kell terjeszteni a 3. betűre, stb.

Ha nem olyan idő kritikus az ügy, akkor miért nem írsz egy string összehasonlító függvényt és lépkedsz végig az összes letárolt adaton összehasonlítva őket a bejövő adattal.
Az ugrálós, karakterenként kizárós megoldás szerintem nehezen átlátható és nehezen bővíthető, viszont gyors. De hát a sebesség nem minden.
A sima string összehasonlítás kiválóan bővíthető, ha pl. az utolsó letárolt adat egy "" üres karakterlánc. Így addig mehet az összehasonlítás, míg ""-t nem talál.

Szia!
Ha megoldható a periféria ne szöveget hanem egy számot küldjön, ekkor egy táblázatból azonnal kiolvasható a küldött szöveg.Ez a leghatékonyabb, főleg, ha az egyes szövegek azonos hosszúságúak (szóközzel kiegészítve). Ekkor egy szorzás, és máris a megadott szövegnél vagy.

Esetleg némileg egyszerűsítheti a dolgod, ha a szerkezeted tud szám formában is kommunikálni.Az M35-nél pl csak egy AT parancs, és minden üzenetet,talán az error kivételével, szám formátumban küld. Lehet az egész dekódolás dolog érvényét veszti.
Ha viszont a stringet választod, én legalább az első 2-3 karaktert mindenképpen vizsgálnám, már zavarvédelem miatt is.
Ha tárhely van bőven ,az első karakter dekódolását egy ugró táblával is megoldhatod. A karakterkódot átalakítod, a soha nem változó biteket kinullázod. Így egy 0-20H közötti számot kapsz. Ez alapján egy ugrótáblával az első betű szerinti szétválogatás eléggé gyorsan megvan.Igaz eléggé nehezen bővíthető a stringes változathoz képest.

A foxi63 és proba által vázolt megoldás talán a legegyszerűbb és gyorsabb. Egy másik lehetőség, hogy -amennyiben megoldható- áttérsz c-re és egy strcmp()-vel meg egy egyszerű for ciklussal megoldod.

És C-ben mennyivel lesz gyorsabb? Mert látszólag pár sor az egész?

Sziasztok!

A PIC-em adatlapjának DC Characteristics részében az Input Low Voltage-hoz max 0.8 V van írva, a Input High Voltage-hoz min 2V. Azt szeretném megkérdezni, hogy ha a PIC lábára 0.8-2V közti feszültség jut éppen, és lekérdezem a PIN állapotát, akkor most arra mit fogok kapni?

Onnan jön ez a problémám, hogy egy egér tekerőgombját a hozzá tartozó infraled+2 db egybeépített fototranzisztor együttessel szeretném felhasználni, és ahogy tekerem szép lassan a tekerőt, akkor a fototranzisztoron (attól függően, hogy a lyukacsos tárcsán keresztül mennyi infrafény jut rá), más más feszültség esik, azaz a PIC-en lábán 0.2-4.5V- ig mindent mérek a tekerő helyzetének függvényében. És az a problémám, hogy lehet hogy emiatt, de nem működik a tekerés irányának meghatározása.

Szia!
Ez a kezdő elektronika rovatba kellett volna ... !
Ez nem meghatározott logikai szint, tiltott tartománynak szokták nevezni, mert bizonytalan, hogy minek értékeli az adott PIC, illetve áramkör ( a gyártási szórások függvényében ! )!

Nem lehetne átkötni olyan lábra, amin schmitt triggeres bemenet van?

Hogyan próbálod dekódolni a jelet és meghatározni a tekerés irányát?

Elnézést, a Pic kezdőknek akartam beírni, csak siettem, és nem olvastam végig a fórum címet.

A tekerés irányát úgy próbálom meghatározni, hogy ehhez az egértekerőhöz van egy infraled, és ehhez egy tokba épített 2 fototranzisztor van. Kipróbáltam, hogy figyelem külön-külön a PIC azon lábait, amikre a fototranzisztor van kötve, és ha a jelszint magas, akkor a neki megfelelő LED-et felkapcsolom, ha meg alacsony, akkor lekapcsolom (a jobb érthetőség kedvéért a PIC RB5 és RB6 lábára vannak kötve a fototranzisztork, a RC0 és RC1 lábra egy-egy LED, és az RB5 láb jelszintjeinek függvényében kapcsolgatom az RC0-ra kötött LED-et, és az RB6 láb jelszintjének függvényében kapcsolgatom az RC1-re kötött .LED-et). És ahogy szép lassan tekertem az egértekerőt, akkor először felkapcsolódik az egyik LED, majd a másik is, majd lekapcsolódik az 1. LED, majd lekapcsolódott a 2. LED is. Úgyhogy elvileg jól működik a dolog.
Ezután kipróbáltam, hogy interrupt-on-change-re kötöttem az RB6-os fototranziszort, és az interrupton belül a másik jelszintjének függvényében a 8db PORTC-re kötött LED-eken egymás után jobbról balra vagy balról jobbra léptetem a felkapcsolt LED-et, de ez már nem működött, állandó irányú tekerés esetén is felváltva villódzott az egymás melletti LED-ek, van hogy továbblépett, de ott megint az egymás mellettiek villództak a tekerés hatására.
Úgyhogy emiatt már az utolsó tippem az, hogy az okozhatja a problémát, hogy van egy rész, amikor a tekerés hatására a PIC lábán a tiltott tartományba esik a feszültség, és ez okozza bajt.

Üdv
Ha jól emlékszem, akkor Topi írt egy cikk sorozatot Nullától a robotokig címmel (vagy hasonlóval) és az egyik részben pont ezt valósítja meg egy 16F877A-s Pic-el mint amit te szeretnél, szerintem tanulmányozd át az ő cikkét is, hátha szerzel valami ihletet hozzá.

Mindkét fototranzisztor bemenetét interrupt-on-change-re állítsd. Ha megjött a megszakítás csak egyszer olvasd ki a portot, tedd el változóba, az aktuális és az előző értékből megállapítható, merre mozdult el a kerék, a megszakításban növelj vagy csökkents egy szálmálót. A kijelzést bízd a főprogramra.

Ezzel csak az a gond, hogy fel és lefutó élre is reagál, így teljesen logikus az alapján, amit leírtál, hogy az történik, amit látsz. Ha csak az egyik lábon történő változás alapján figyeled forgást, akkor nevezd ki, hogy csak pl. lefutó élre reagálsz. Ekkor már attól függően, hogy az élváltáskor a másik láb hol volt, tudni fogod az irányt. Ezzel csak az lesz a baj, hogy ha egy köztes helyzetben áll meg a tárcsa, hogy a pic lábára tényleg ilyen tiltott tartományú feszültség jut, akkor minden zaj számít, és oda-vissza fog ugrálni a feszültség, ezért fals megszakításokat fog generálni. Ezért a következő lépés, hogy minden élváltásra reagálsz az egyik lábon, ekkor az élváltás irányából és a másik láb állapotából ki lehet találni, hogy merre fordult el a tárcsa. És ekkor jön a következő verzió, hogy mindkét láb mindkét irányú élváltására reagálsz, és a megszakítást kiváltó lábon az élváltás iránya és a másik láb állapotából állapítod meg a forgás irányát. Jó lesz ez, csak gondold végig pl. ezen kép alapján, hogy mi mikor merre változik: http://en.wikipedia.org/wiki/File:Quadrature_Diagram.svg

Azt nem írtam, de az interrupt-on-change próbánál felfutó élere történő megszakítást állítottam be. De próbálkozom tovább, és kipróbálgatom a javaslatokat.

Milyen típusú PIC ez?

16F1829

Abban van 2 komparátor, az analóg funkció. Ha rám hallgatsz, akkor azt használod inkább. Ugyanis a digitális bemenetek nem szeretik, ha a tiltott tartományban tartod huzamosabb ideig a bemenetet, a kapcsolásodban pedig ezt semmi nem tudja megakadályozni.

Kedves hozzászólók. Nem tudom miért, de mostmár működik.

Watt, nem értelek, tisztán megírta szaffo, hogy nem időkritikus a dolog, akkor miért beszélsz a gyorsaságról?

Egy kis érdekesség PIC32MZ témában: Bővebben: Link

Google Translate egész jól angolosítja.

Nekem az jött le, hogy igen. Mert ha nem, akkor mi a kérdés valójában? Mindet össze kell hasonítani sorban és kész...

Hát ez nagyon jó. Már itt volt az ideje valami upgrade-nek. A többi cég már sokkal előrébb járt mint ők, de ha ez kijön végre behozzák a lemaradást.
Lehet tudni arról valamit, hogy mire lesz ebből valami? Mert nem találtam semmi erre vonatkozó infót. Egyáltalán honnan lehetett erről tudni? Nem is reklámozták, hogy lesz.

A pletykák szerint még az idén. Most augusztus közepe-végefelé lesz a Masters Conference, szerintem ott fogják bejelenteni. Valamelyik fórumon olvastam, hogy bizonyos kiemelt fejlesztőknél már vannak példányok, de azoknak a fejlesztőknek természetesen szigorú titoktartási kötelezettségük van.

Ahogy jobban utána néztem, pár adatlapban már úgy írnak róla, mintha lenne. Valóban a Masters Conference-en fogják bejelenteni. Lesz ott egy Class direkt ezzel a témával.
Teljesítményre nagy jó lesz, viszont remélem, hogy láb kompatibilis lesz az MX szériával. Az általad küldött kínai leírás szerint sajnos vannak árnyalat béli eltérések, de "szerencsére" csak legfontosabb lábakban.

Én úgy olvastam, hogy nem kompatibilis, de nem néztem utána túlságosan. Meg a másik nagy kérdés, hogy mennyire kell profi nyákot tervezni alá. Nekem vannak kétségeim afelől, hogy ami jó volt az MX-nek max sebességen, az az MZ-nek már nem lesz elég.

Egyébként vannak benne egész érdekes perifériák is, pl. az Encryption modul, vagy a véletlenszám-generátor. Nekem úgy tűnik, eléggé elmentek a hálózati eszközök irányába.
Arra is kíváncsi leszek, hogy az MPLab hogy fogja kezelni, illetve hogy a PICKit valamelyik verziója tudja-e égetni (ha Hp41C-n múlik, a 2 is tudni fogja ).

Olyat is olvastam, hogy MMU, EBI (External Bus Inreface) az általad felsoroltak mellett.
Ahogy néztem ezeknek a PIC-eknek a nevében szerepel az EC "kód". Ahogy az adatlapból kiderült az az Embedded Connectivity rövidítése. Ennek fényében van összefüggés a név és a "tudás" között.

NYÁK ügyileg miért vannak kétségeid? Több 100nF kellene hozzá vagy hasonlók?

A programozás tekintetében, remélem a PICKit 3 vinni fogja. Elvileg arról még nem vették le a kezüket

Azért vannak kétségeim, mert ahogy növekszik a sebesség, úgy sokkal inkább játszanak azok a tényezők, amiket lassabb rendszereknél nagyvonalúan elhanyagolnak (szórt kapacitások, vezető sávok induktivitása, mindenféle zajok felvétele, stb.). Csomó mindenre kell figyelni, többek közt a vezetékek hosszára, egymáshoz képesti elhelyezésére, power/ground plane kialakítására, hidegítésekre, pufferelésre, stb.

Értem. Végülis, ha nem láb kompatibilis, akkor úgy is új NYÁK-ot kell tervezni. Csak akkor ember legyen a talpán, aki egy 100 lábú LQFP tokos IC-nek normális NYÁK-ot tervez.
Bár bízom benne, hogy ebből nem lesz nagy gond és a gyors dolgok a PIC belsejében maradnak, így csak hidegítésről kell gondoskodni No de majd elválik, remélem minél előbb. Már épp azon gondolkodtam, hogy vagy beleásom magam a PIC32 assembly-jébe, vagy átpártolok másokhoz ahol gyorsabb MCU-k vannak.

A MIPS assembly önmagában nem vészes, de a memóriamenedzselési stratégiát neked kell kidolgoznod. Ha C-vel akarod vegyíteni, akkor meg arra kell törekedni, hogy ezekkel a stratégiákkal összhangban legyen a kódod. Gondolok itt a stack/frame pointer használatára, függvénykontextus mentésére, meg hasonlókra. Szerintem inkább csak egy-egy algoritmust érdemes kioptimalizálni vele, de komplett, PIC32 tudásának megfelelő programot jól megírni irreálisan hosszú időbe tellene.

Mit akarsz építeni, amihez a PIC32MX kevés?