A mikrocsip peldaprogramokkal erdemes vigyazni, de ezt magad is eszrevetted...
Ennel a tipusnal egesz biztosan nem kell semmifele varakozas az olvasashoz. Igazabol az irasnal sem kell a hagyomanyos modon varakozni, bar ketsegtelenul egyszerubb, mint az ACK polling. Amig az EEPROM belul vegzi az irasi muveletet, addig a tovabbi irasi kezdemenyezesekre nem kuld ACK-ot valaszul, es innen lehet tudni, hogy meg nincs kesz a kovetkezo muveletre. Elkepzelhetonek tartom, hogy esetleg az I2C kezelessel van a problema, es azert mukodik neked csak varakozasok beiktatasaval. Az Atmel EEPROM ugyanugy mukodik, mint a mikrocsip.

Mint írtam, nagyon is elképzelhető....
De legalább végre működik, elég sokat görcsöltem vele.

Ertelek. Ha te megelegszel azzal, hogy mukodik, de nem tudod, hogy mitol, akkor nem erolkodom tovabb.

Sajnos így is ugyan az a probléma

Tehát ezek szerint az XC16 fordító a karakterláncokat mindenképpen erre a 32k-s területre rakja. Ez elég kretén dolog tőle...

Kíváncsiságból rákerestem a hibaüzenetre és a Microchip szerint van erre megoldás:
Bővebben: Link
210. oldal "11.6 USING MORE THAN 32K OF CONSTANTS"

Szuper, így működik!

Illetve majdnem. A program így már lefordul, nem dobja a fenti hibaüzenetet, viszont a programban amikor meghívódik az a függvény amelynél a konstanst kicseréltem az újonnan létrehozott tömb címére:

akkor újraindul a PIC. Természetesen be van include-olva a Szoveg1 tömbböt tartalmazó fájl headerje.

Viszont van nekem egy C fájlom amelyben WAV fájlokat tárolok const char tömbként. Az 5db ilyen tömb összesen 28924 bájt. Ezekhez is hozzáírtam ezeket az attribútumokat, és így igen jelentős hely felszabadult erről a 32k-s területről, egy jó darabig most már megint irkálhatok tovább ilyen karakterlánc-konstansokat.

A helyzet viszont itt sem tökéletes. Az öt hangfájl lejátszása működik ugyan így is, viszont az ötből az egyik hangfájl (épp a legrövidebbb) ha lejátszódik, nagyon kretén hangja van. Az összes többi hangfájl hangja tökéletes, csak ez az egy szem rontódik el valamiért. Mondom jó, akkor ennél az egy problémás hangfájlnál kiveszem ezeket az attribútumokat. Így viszont bármelyik hangfájl lejátszásakor újraindul a PIC.

Szia Attila!


Nekem akkor volt ilyen, amikor nem jól olvasta ki az adatokat ( szerintem elcsúszik a beolvasás során a számozás, pl. nem páros helyre tette, olvassa )! Nézd meg analizátorral vagy DEBUG !

Ramtron fram FM24C256 FM31256

Hivsz megszakitasbol olyan fuggvenyt, ami const adattal dolgozik?

Érdekes, még nem találkoztam vele. Ahogy nézem, egyszerűen betehető az EEPROM helyére.
Viszont ahogy látom, elég érdekesen "szórnak" az árak.

Igen, 62,5us-onként (16kHz-esek a hangok) meghívódik egy függvény amelyik az éppen játszott hangfájl (mely const char tömb) következő bájtját kiteszi a PWM-re.

Sziasztok!

Lehet megint nem haladó, de 32MZ/MX-el kapcsolatos.

Van valami "szabály", hogy az interruptban a flag-et az interrupt elején vagy a végén kell törölni?
Mert mondjuk az UART-nál ha nem olvasom ki a RXREG-et akkor nem lehet törölni az RXIF-et vagy amíg change notification-nél nem törlöm a portra vonatkozó CNF-et addig nem engedi a IFSx reg CNIF-jét törölni.
A kérdés csak azért merült fel bennem mi van ha az interrupt közben befut még egy és mikor az interrupt végén törlöm a flag-et akkor ugrott egy megszakítás.
Vagy ez az utolsó gondoltat csak hibás programozás esetén léphet fel mikor teli dobálja az ember az interrupt-ot szeméttel?

A megszakítási rutin elegáns esetben megszakítási "alsó fél". A teljes programod egy darab hatalmas nagy aszinkron állapot gép, aminek az alkalmazás szintű rutinjai végzik a megszakítási "felső réteg" teendőit. A két fél statikusan elég nagyra szabott memória buffereken (pld fifo) kommunikál egymással. A megszakítási rutinból csak az adatot veszed át attól a hardvertől, ami nem tudja azt sokáig tárolni, és berakod memória bufferbe "becsomagolva" minden olyan szükséges másodlagos adattal, ami ideális adatcsomaggá ki tudja azt egészíteni, hogy következő lépésben már absztrakt szinten kezelhesd az adatot. A megszakítási rutinban nem csinálsz mást. Ha az adatot átvetted, memória csomagot készítettél belőle, beraktad a fifoba / akármibe, _akkor_ törlöd az IF-et, és utána már csak visszatérsz a megszakítási rutinból.

Hmm, halványan emlékszem csak valami említésre az interrupt kezelésről, hogy az interrupt jelző flag törlése utáni utasítást még nem szakítja be következő interrupt akkor sem, ha már tűkön ülve várakozik. Ha asm szinten nincs ott más az interrupt engedélyezés után, csak egy return, akkor a következő interrupt nem "ütközik bele" az előzőbe. Ha jól sejtem, az jár a fejedben, hogy olyan sűrűn jönnek egymás után az interruptok, hogy végül túlcsordul a verem a sok egymásba futott interrupt miatt.

Csak filozófia volt. Egy 200MHz-es MZ-vel már nem feltétlen az a lényeg hogy mennyire hatásos kódot írsz bár azért itt is vannak trükkök.
De sokkal inkább csak a szépség miatt érdekelt.

De az asszinkron állapot gép meg van már többnyire az interruptban is csak flag-eket billegtetek nem tudom miért épül nagyon sok példa a while(!GOMB); ez az állítsuk meg a procit típusú elvre.

Az arak a szerint szornak, hogy milyen tipusu. CMOS vagy FRAM. A CMOS 26F256 (Microchip) kb €1 mig ugyanez FRAM kivitelben (Cypress) €5.53 Azt viszont ne feledd, a CMOS EEPROM "korlatozott" alkalommal ujrairhato, mig az FRAM szinte korlatlan. Es erdekes modon az ujrairhatosag mennyisege homersekletfuggo. Ha erdekel bovebben olvashatsz rola Itt: Microchip tutorial

Itt pedig egy jo kis osszehasonlito leiras az FRAM-rol, a TI-tol

Egyelőre EERAM-ot vettem kipróbálni. Nyilván ez is befuccsol az adott számú írás után, de - felhasználástól függően - ritkábban kellhet írni, mert elég, ha csak a kikapcsoláskor ír az EEPROM részbe. Csak egyelőre a memória mérete elég kicsi.

Ha nagyobb darab kellene, a flash kártyák "mérsékelt" kapacitású darabjai már ritka kommersz árban vannak.

Egyelőre csak próbálom "tanulgatni" a különböző komponensek kezelését, ahhoz meg elég a 2 kByte is. Bár van konkrét tervem is, mit szeretnék először nem csak deszkamodellként megépíteni.

Ha esetleg valaki ismeri a DS1307 RTC-t, érdekelne, mi fán terem az abban lévő 56 byte "NV SRAM". Addig értem, hogy nem felejtő RAM, de "miből" van. Csak az elem miatt nem felejt, vagy anélkül sem?

Az az SRAM úgynevezett statikus RAM, innen a rövidítés. Bipoláris tranzisztoros logika van benne, szemben a dinamikus RAM-mal (DRAM), amiben CMOS van. A SRAM működése bináris tárolókon alapul, a dinamikusé meg azon, hogy a CMOS gate kapacitását tölti fel vagy süti ki a bitek beírása. A kisülés magától is végbemegy, ezért a DRAM "felejt", frissíteni kell. A SRAM viszont tartja az állapotát, amíg tápfesz van.
A SRAM gyors, de alacsony integrálhatóságú, kis kapacitású memóriákhoz jó, pl. cache memória, vagy ilyen mikrovezérlők.
A DRAM kicsit lassabb, felejt, de nagyon jól integrálható, így nagykapacitású memóriák építhetők belőle. Lásd a PC-k több gigabyte-os moduljait.

A DS1307 -ben levő ram is CMOS technológiával készült RAM, nézd meg a fogyasztási adatokat.

Ezzel többé-kevésbé én is tisztában voltam, bár valóban nem figyeltem rá, hogy SRAM. Arra is rájöttem, hogy az "NV" a nem felejtőt jelenti. De akkor ez gondolom csak addig nem felejt, amíg nem kell éppen cserélni a CR2032-t.

Az lehet, utánanéztem (eredetileg régen tanultam róla, a technika meg fejlődött közben). De működési elv ugyanaz, mintha bipolárisakkal építették volna meg.

Pontosan, csak addig okos, amíg kap delejt.

pajti2 egy más irányú kérdés, ha már az asszinkron állapotgép és a fifo bufferelés szóba jött.
Vegyünk egy UART kommunikációt, az adatok fogadása logikus interrupt és pakolni bele a fifo-ba az adatokat (vagy épp DMA-val interrupt helyett) és amikor oda érek ki olvasni.
Na de a küldés annak is az lenne inkább a megfelelője while(!TRMT); TXREG = data; helyett, hogy be kapcsolom a TXIE-t és küldéskor a fifo-ba bele dobom az adatok[cim+1]-et majd a 0. adatot beírom TXREG-be és utána az interrupt végig küldi az adatokat (vagy itt is DMA interrupt helyett)?

UART adási megszakítás kiszolgálása:
- Ha van adat az adási pufferben, ki kell venni az adatot a pufferből, el kell küldeni a soron következő adatot az UART -nak.
- Ha nincs adat az adási pufferben, le kell tiltani az UART adási megszakítás kérését.

Az adási puffer beírásakor az adatot be kell tenni a pufferbe és engedélyezni kell az UART adási megszakítás kérését.

De, ha az UART TXREG-je üres és én engedélyezem a TXIE-t attól nem fog beugrani megszakításba csak akkor ha írtam már valamit a TXREG-be, vagy beírom a bufferbe az adatot, TXIF = 1, TXIE = 1 és mikor átment az összes adat interrupton belül tiltani a TXIE-t?

Ha az UART TXREG-je üres (soha nem írtunk még bele, de az UART engedélyezett), a TXIF 1-re áll. Ha engedélyezem a TXIE-t attól be fog ugrani megszakításba...

Még nem kezdtem hozzá, de szükségem lenne egy MPU-6050-es giro működésre bírására. Mielőtt belekezdenék, gondoltam megkérdezem, hogy van-e valakinek tapasztalata ezzel az eszközzel PIC-es (tehát nem Aurdino) környezetben.

Van 6db const char tömböm a programmemóriában (hangfájlok). Ebből a hatból kettőt ha lejátszatok a PIC-el, akkor azoknak nagyon kretén hangja van, a másik négy az jó. Elindítottam a debuggert és a Watch ablakban megjeleníttettem az egyik rosszul lejátszott hangfájl (tömb) címét, ez 0x331E. Van egy függvényem amely elindítja a hanglejátszást, ennek át kell adni a lejátszani kívánt tömb kezdőcímét:

Az első paraméter nem lényeges, a második ("hangfajl_gomb") a tömb címe, a harmadik paraméter pedig a tömb hossza, hogy milyen hosszan játssza le.
A függvény így néz ki:

A függvény második során ha átléptetem a debuggert, akkor a Watch ablakban kiírja hogy a Hang->most mutató értéke 0xB31E. Pedig 0x331E-nek kellene lennie! Megnéztem a jól lejátszott hangoknál (tömbböknél) is, ott valóban a tömb helyes címe íródik bele a mutatóba.

A Hang->most típusa u8*. A tömb pedig így van deklarálva:

Az összes hangfájl ugyan így van, csak a neve meg az elemszáma más.