Na itt a baj!
Mivel a különböző nyelvek egymásra épülnek, ezáltal az összesnek az assembly a gyökere.
Mivel a fejlesztők nem foglalkoznak az assemblyvel, csak a meglévő őskori kódokat variálják, így lehetséges az, hogy pl. létrában megírt bit billegtetés fordítás után akár 15-20 sor is lehet, miközben a PIC18 óta ez egy egyszavas utasítás.
Épp csak senki nem veszi a fáradtságot, hogy az ősi kódokat újraírja!
Sajnos az asm.-ben programozó hobbisták is lusták.(Tisztelet a kivételnek!) Ha valamire találnak egy kész kódot, rögtön megy a "CONTROL C - CONTROL V". Hogy az a kód mennyire jó, vagy lehet ezt rövidebben is, stabilabban is, az már lényegtelen. Természetesen egy adott bonyolultság fölött már nonszensz asm.-ben programozni. De az assembly ismerete és használata nélkül nem alakul ki a megfelelő gondolkodásmód.

És most lehet megkövezni!

Ennek a posztnak a megvitatása megérne egy misét egy szaktopikban.
Röviden annyit tudok reagálni, hogy tévedsz.

Sziasztok ehhez Remek műhöz milyen picet és shiftregisztert ajánlatok???
Bővebben: Link
95 RGB led lehet kevesebből megcsinálom.

mellékesen:
Órát még tesztelem. 1 sec et siet eddig naponta. Majd pénteken leírom az adatokat.

Elnézést a dupla postért.
Egy telefon órája is tud csalni secundumokat??

Sziasztok,

PIC24F04KL100 szeretnék használni. a Működési feszültsége 1,8V - 3,6V. Ez a típusú aksi, tápfeszültség gyanánt megfelelő lenne? : NiMH 3.6V 750mAh GB375824

Előre is kösz!

Egy teljesen feltöltött 3,6V-os aku feszültsége 4V fölötti.
Nem biztos, hogy a PIC bírná.

Shift regiszter helyett a Holtek HT1632C LED mátrix vezérlő is számításba jöhet.

Tegyél két ilyen aksit és stabilizáld a feszültséget..

Pic-el szeretnék megoldani egy esemény számlálását. Olyan tápellátás megoldás kellene a kontrollernak ami nem igényel nagy helyet és újratölthető. Szóval hálózatról történő trafós + 5 V regulálás kizárt. Az áramkörbe épített aksis megoldás lenne jó. Tudtok ajánlani valamit?

Köszönöm!

De neked elég a 3v stabilizálása, vagy akár kevesebb.
Mindenképpen arra kell figyelned, hogy a PIC ne kapjon több feszültséget mint 3.6v, ha 3v-os, vagy 5.5nél ha 5v-os PIC-et használsz.
Amúgy az 5v-os PIC simán elfut alacsonyabb feszültségein is, csak az óra jele lassul, de ez szerintem nem fog gondot okozni. (tán 2.5v-ig nem lesz gondod egy 5v-os PIC-el sem, adatlapot meg kell nézni)

Ha nem kap többet 5v-nál soha, akkor használj 5v-os PIC-et, az elfut alacsonyabb feszültségről és nem kell a stabilizátor.
Órajelet a legalacsonyabbra állíts be (pl. 1MH) és akkor ott sem lesz érzékelhető változás.
Feszültséget viszont nem tudsz majd mérni mert ahhoz stabilizált referencia kell. (maximum azt tudod beállítani, ha egy bizonyos mérték alá süllyed akkor jelezzen, vagy ha egy bizonyos fesz fölé megy a mérés akkor számoljon egyet, fiktív mérés)
Töltés számoláshoz elég lesz ez a megoldás..

Hsz-m

74hc595 helytállna???

Én pl. ezzel a típussal dolgozva készítettem 4x4-es LED kockát és RGB bináris órát is, tehát megoldható.
Arra azért figyelned kell, hogy te RGB-ből akarod mind ezt, tehát mindent 3 szorozni kell és nem árt meghajtó IC-éket is beiktatni.

De a kérdésre a válasz igen, jó lehet.

LiFePo4 akkut tudsz keríteni?

Az 5 V -os táplálás jónak tűnik.

Volna még egy kérdésem. A kontroller egyik bemenetére lenne kötve egy szenzor és a kontroller 500 ezer esemény változás után jelezne egy LED diódával, hogy a számlálás elérte azt a mennyiséget. Ebben az esetben szükséges, hogy a mikrokontroller rendelkezzen 32 bites időzítővel? Ezt abból feltételezem mert a 16 bit csak 65536 esemény számlálására képes?

Kösz!

Nem!
Elég a 16bites is, sőt akár a 8 bites is.
Túlcsordulás esetén tovább számoltatsz egy változóban.

Nem kell, elég a 8bit-es is.
Használj struktúrát, hozz létre union-t, vagy használd ki a C nyújtotta változók teljes palettáját.
Esetleg lehet használni több változót is és túlcsordulás esetén új változót vezetsz be.

Pl.:
unsigend char szamolo_a;
unsigned char szamlalo_b;
Használd az a változót, ez 255-ig tud számolni, majd mikor a 256. érték felvétele megtörténik használj egy másik változót ami legyen a b, ez szintén 255-ig képes emelkedni.
Ez kapásból 256*256 lesz vagy is, 65536 érték.
Ha ezt még egy változóval megfejeled akkor 256*256*256 értéket tudsz tárolni. (16777216)

De unsigned int-es változóval már is 65536 értéket tudsz eltárolni.
Ott van még a long a long long, és így tovább.

Mire gondolsz ??nagy feszültség miatt???
Ha igen akkor tranziztor is jó?

Igen, bár inkább a terhelés miatt, ezért írtam a meghajtó IC-ét.
Én például ULN2003-at használtam meghajtónak..

Feltételezem, arra gondolt, hogy te fényerőt is szabályozni akarsz majd, és akkor bizony impulzus üzemben kellene hajtanod a ledeket, amihez rush current kell. Mondjuk olyan 240 hz-en (minden második állapot aktív).

Használhatsz meghajtó ic-t, vagy tranzisztorokat. Ízlés dolga.

Az 595 jó választásnak tűnik.

Majd rakj fel róla szép színes videót, ha kész

Részemről annyit fűznék hozzá, hogy a ctrl-c / ctrl-v szerintem is majdhogynem szentségtörés. Én mindig ctrl-ins / shift-ins kombinációval copy / pastelek. A többi stimmel

Az akku jó lesz. Azokat a 3.6-os akkukat jellemzően úgy használják, hogy bemenetről kapcsoló üzemű tápegység tölti, és kimeneten low drop out regulátor stabilizál. Ha nagyobb feszültségű akkut használnál, rakj a kimenetére is kapcsolóüzeműt, kevesebbet fog elfűteni feleslegesen.

Valaki elmagyarázná a ULN2003 működési elvét??
Még annyit hogy milyen "derót" ot használ a cikk készítője??
Ellenállással helyet van valami más eszköz amivel áramot lehet szabályozni??

Két megjegyzést a programozás technikájához:
- A meglátom és máris ^C, ^V több problémához vezet, mint ami elsőre látszik. Változók, bankok, stb... Még magasabb szintű nyelven, sőt a saját forrásunkban sem ajánlott a gondolkodás nélküli copy - paste. A legtöbb megbújó hiba innen jön, hiszen a program lefordul...
- Egy adott kontrollernél egy adott bonyolultság fölött visszajön az assembly (betét), hiszen a program memóriája igen erős korlát lesz. Minél magasabb szintű a parogramnyelv annál "kódszátyárabb".
Egy 16 bites szó növelése és az átfordulás vizsgálata 18F -en, assemblyben 3 utasítás (az ugrással együtt). C18 -ban előbb készít egy 16 bites (1) számot két munkaváltozóban, majd 16 bitesen összeadja.

A copy / paste nyilván a programozó felelőssége. Szabad országban élünk, itt mindenkinek kötelessége szabadon akkora marhaságot csinálni, hogy azt legalább egy valaki biztosan bánja meg Én csupán arra kívántam rámutatni, hogy ha mindazt én ctrl/shift-insert helyett ctrl-c/v -vel csinálnám, levágnám érte a saját fejemet, és kidobnám a kukába

Lehet, egy kicsit sok rum volt abban a süteményben..

Nagyobb pic-eken egyébként senki sem akad ki azon, hogy pocsékolsz ezt-azt. Nyilván amikor time critical cuccot faragsz, és pláne olyan környezetben, ahol még azt is 32 khz-es órajellel pörgeted egy 16f-en, hogy még több energiát spórolj, olyankor nem csak a byte-okat, de még a biteket is átgondolod, az órajeleket meg pláne egyesével számolod meg mindegyiket. De amíg valaki életében még csak 32mz boardot látott 180mhz frekin 521k rammal és 2mega flash-el, addig azt nem fogja érteni. Sokan érkeznek a pic világba desktop computer oldalról, és nekik a pic egy "kicsi számítógép", az ahhoz tartozó szokványokkal. Mások digitális elektronika oldalról érkeznek, és nekik a pic egy "négyzetméteres áramkör piciben". Ha léteznek fpga felől érkezők is, nekik a pic egy állapotgép lenne "kevesebb lábszámmal". Akklimatizálódni időbe kerül. Te is csak elkezdted valahogy, ugye? Türelem. És talán a globalizációval is fel lehetne hagyni. Mindegyik pic családnak megvan a saját szokvány halmaza. A 10-esek, a 12-esek, a 16-osok, a 18-asok, a 24-esek, a 30-asok, a 33-asok, a 32mx-ek, a 32mz-k (a 14f-ek forgalomban vannak még?) mind külön kategória, amik csak a saját rigolyáikkal együtt léteznek önálló csomagban, és a csomagok tartalmát összekeverni szimplán demagógia.

Hmm. Hogyan mondják angolul, hogy "kevesebb lábszámmal"?

Itt van a projektem, amit itt fojtatnék, mert ezt javasolták... Szóval: Találtam ezt a kapcsolást, amit módosítani kellene, hogy ezzel működjön, amin Hitachi vezérlő van, valamint elég legyen neki a rajzon szereplő 5V. A kódja itt van, amit módosítani kellene, hogy menjen a Hitachi vezérlős kijelzővel és az összes betű, szám, írásjel működjön, valamint a [home] gomb a reset, az [enter] a sorváltó és a [backspace] pedig a visszatörlő gomb legyen és üres kijelzővel induljon, amire azonnal lehet írni.

Ezzel azért vitába szállnék!
Rendszeresen használok és programozok PLC-t. Sejtheted, azokban nem 8 bites kontroller van 16MHz maximummal.
A kényelmes létradiagramos + blokkos programozás ára olyan terjengős kód, hogy a készítők lehetővé tették a programban megszakítás futtatását, és a bemenetek - kimenetek közvetlen elérését. A megszakítások automatikusan indulnak 1,25milisec-enként! Gondolj bele, milyen lassú lehet maga a program lefutása, ha többször is megtörténik benne ez a megszakítás.
Ehhez képest assemblyben létre tudtam hozni azt, hogy egy encoder jelét, szoftveresen feldolgozzam,ellenőrizzem, közben még egy kijelzővel is kommunikáljak, valamint egyéb feladatok is fussanak. Mindezt 16MHz-n egy 8 bites kontrollerrel, úgy hogy az encodertől 75mikrosec-enként érkezik jel.
Oké! Azt elismerem, hogy assemblyben tízszer tovább tartott megszülni a programot. De megérte!

Mi a különbség a kettő között?

Sziasztok Valaki tudná a nyomogomb figyelésemet Debugolni??
A problémám az hogy halenyomog egy gombot néha töbet néhanem és nem tudom miért csinálja pedig úgy akartam megírni a kódot hogy ezt pont elkerüljem.

A nyomogomb ugy müködik lenyomog egy gombot meg mégegyet azt érzékeli ésakkor hajtom végre amikor minden gomb elvan engedve.

És nem tudom hol rontom el vagy a nyomogombom "pontatlan"??

A nyomógombot pergésmentesíteni kell. Vagy hardveresen NAND kapuval vagy szoftveresen.

vagy is késleltetnem kell?? ha igen szoftveresen hogyan lenne a legjobb egyszer meg írtam késleltéssel hát nem vált be sajnos.