Köszi.
Akartam írni tegnap, de a rendszer nem engedte, remélem most már jó lesz.
Én is így csináltam, annyi változással, hogy bites struktúrába rendeztem az elmentett adatokat és csak az aktuális bitekre hoztam létre feltételeket. Köszi a logikai leírást.

Köszi, tán az a rész nem jó számomra, hogy ha R és S nem változott, akkor értelem szerűen a T lesz. Mi van, ha éppen fázis kimaradás vagy valamilyen hiba lépet fel?
De köszi szépen a logika itt is szépen látszik, a szükséges hiba kezeléseket már megírtam, mert fontos, hogy ha kimarad vagy elmegy egy fázis vagy netán egyforma két fázis, akkor bizony azonnal hibát kell jelezzen a rendszer. Köszi srácok.

Üdv!

Megint nem értem pontosan mi történik, mert megint hulla fáradt is vagyok már.

Minden működik, de tényleg. UART-ról fogadok karaktereket, küldök sok adatot, de az SPI csak nem megy. Az is a baj, hogy Proteusban csak p33FJ32MC202-t tudok szimulálni, de nekem p33FJ128MC202-m van. A szimulációban minden tökéletes, simán jó. A valóságban meg....
Átírom mindenhol a header-eket, hogy a p33FJ128MC802.h forduljon bele a kódba. Feltöltöm, ráteszem az analizátort és a csatolt képet kapom. Elvileg RAM-ba kellene írni. Az írás nem jó, mert nagy vonalakban, mikor olvasnék ki akkor az óra jele megjelenik és jó. Előtte a három próbálkozás az az RAM felé az instrukció, cím felső byte, majd alsó byte, majd ami már jó, az az olvasás lenne. Nem tudom mia baj. Lehet kellene lehúzó ellenállás, meg ilyesmi, de akkor olvasáskor miért jó? Nem értem.
A MOSI sem jó, ott is hiba van, semmit nem csinál. A képen látszik, hogy az első 3 próbálkozás, ami a write lenne időben sem jó, sokkal rövidebb, nem csak hiányzik az óra impulzus sorozat.
Itt a kód:



Elvileg a pin remapping jó, mert akkor nem jelenne meg az óra, mikor a read()-t hívom meg. A csatolt képen látszik a hiba, de olvasáskor a megjelenő óra ideje jó, 80 MHz van leosztva 128-al.

Szerintem ne szimulálj Debuggered nincs? mivel tolod fel a programot?

PICKIT-3-al. A debugot nem tudom még hogyan kell használni. A logikai analizátor mutatja, hogy mi a helyzet. Nem jó!

Nem ismerem ezt a PIC-et, de ha a kódban lévő megjegyzések jók, akkor:

SPI1BUF = data;
várakozás, amíg elindul az adás
flag törlés
SPI modul kikapcs

Nem lehet, hogy túl korán kapcsolod ki az SPI modult? Egyáltalán miért kell ki-be kapcsolgatni?

Nekem sem világos, ezt valahonnan nyestem, a szimulációkban ok minden.

Adatlapból:



Eddig azt hittem az a while azt csinálja, hogy megvárja, mire vége lesz az átvitelnek. Itt lehet a hiba? Nincs vége, de már bezárom? Ok, kipróbálom, majd, hogy csak az init-ben indítom el és nem kapcsolom ki. De addig is nincs olyan lehetőség, while, ami megmondja, hogy mikor ment át az adat? Hasonlóan a read-nél lévőnél? Melyik regiszter és bitje lehet ez. Sajnos most nem látom már át rendesen.

- Nem kell kikapcsolni az SPI modult, főleg nem egy távirat közepén (Write_SPI).
- HA beírunk egy adatot az adó bufferébe, akkor nyilván tele van a buffer (SPITBF == 1). Meg kell vérni, amíg üres lesz.

Köszönöm!

Több hiba is volt, nem csak ez.
- Mivel több bytenak ki kell mennie a RAM felé, ezért nem szabad mgszakítani
- A /CS select láb pillanatra sem szakadhat meg.
- Amit írtál, plusz, mivel több byte megy ki egymás után, amit a kód többi része egymás után küldi ki, gyorsabban, mint ahogy kimenne az SPI-n, meg kell oldani, hogy az SPI wrire/read várjon, míg kész nincs. Ennek egy kis trükkje is van, mivel ugyanaz a buffer, de végül megy. Amit írtál az addig vár, míg az esetleges előző adat még ki nem ment. De mivel gyorsan küldeném az adatokat a kódból, ezért meg kell várni míg kész nincs. RAM-nak kell 1 byte instrukció, 2 Byte cím, és 1 byte adat. Azaz minden egyes byte-ot meg kell várni. Mindeközben a /CS nem szakadha meg. Miután a várakozás megoldódott rögtön lehetett látni a többi hibát, amit perc volt javítani.
Mert valójában olyan, mintha két szál indulna el. Egy a fő program, a másik pedig egy timer vezérelte eseméy. A kettő nincs szinkronban, azaz kiküldüm a RAM_Write függvénnyel az adatot, amiben 4 Byte lesz végül, még ki sem ment, már küldené a másikat. Erre is figyelni kell.

Na pont ez a bajom a PIC-ek hardveres kommunikációjával.
Hogy nincs egy nagyobb buffer, vagy nem jelölhető ki egy adott memóriaterület buffernek, hogy oda beteszek x byteot, azt küldi. Vagy fogad x byteot, azután szól.
Mivel csak egyesével küldhető - fogadható, értelmetlen. Akkor már inkább küldöm szoftveresen, legalább átlátom az egész folyamatot.

Erre van a megszakítás. Csinálsz magad egy ring buffert, amibe berakod a kiküldeni kívánt byte-okat. Elindítod az első byte küldését, majd ha az UART/SPI/I2C modul 1 byte-os buffere kiürül, akkor keletkezik egy megszakítás, amivel a saját bufferedből veszed a következő byte-ot a kiküldésre. A főprogramnak nem kell várnia ha elég nagy a buffered, ha kiment egy byte a IT küldi a következőt. Közben a főprogram csinálhat mást. A fogadás is hasonlóan megvalósítható. Példa ITT

Szoftveres küldésnél a küldés alatt nem csinálhatsz mást még IT-ből sem.

Hát, egyelőre nem értem ezt pontosan, de értem nagyjából ezt. A hiba nem annyira a PiC-ben van szerintem, hanem abban, hogy igen tömören fogalmaz minden datasheet. A megoldás ugyan benne van, de a pontos példa kódok nem. Azaz leír egy megoldást, egy példát az írásra, olvasásra, de ilyen problémra nem térnek ki. Utólag persze minden tökéletesen érthető, de az oda vezető út kicsit rázós volt. Főleg a buffer cseréje, ami megoldja a várakozás problémáját. Az nélkül nem megy.

A másik igen fonts tapasztalat, hogy a szimulációk néha köszönő viszonyban sincsenek a valósággal. Engem ez is megvezetett, folyton hardver hibára gondoltam. Forrasztás, eleve hibás IC-k stb. De nem, a hiba logikai volt.

De nagyon örülök, hogy megy, simán megy a LED villogtatás, UART-ról adat fogadás/küldés, miközben SPI-RAM is tökéletesen fut. A szerencsétlen RAM még úgy is megy, hogy párszor elgörbültek a lábai.
Valamelyik kolléga itt említette, hogy logikai analizátor nélkül nem megy. Igza volt! Persze kellett oszcilloszkóp is...

Lehet ez nem éppen kezdő kérdés volt különben.

Vagy DMA használata, már ha tudja a kontroller.

Az előző hozzászólás mondjuk nem a kezdőknek ajánlott, de tudjuk sonajkiz már rég óta gyűri a PIC-eket, nem árt továbblépnie a SW UART-ról, ha akar.

A dsPIC sorozatnál már az adatlap magában kevés, de van családonként egy sokrészes Reference Manual sorozat, annak a megfelelő részét kell fellapozni, pl. SPI a te konrolleredhez: ITT

Az adatlap az SPI-t 6 oldalban foglalja össze, a RefManu SPI fejezet lényegi része meg 37 oldal, példákkal is megtűzdelve.

Ahogy Bakman említette van DMA is bizonyos kontrollerekben, például a te kontrolleredben is, sok adat mozgatásánál jól jöhet.

Idézet:
„említette van DMA is bizonyos kontrollerekben”

Az ős öreg Z-80 is tudta már ezt

Igen, bár nem a Z80 CPU-ban volt ilyen lehetőség, hanem a periféria családba tartozott egy DMA kontroller IC is. Viszont a DMA nem jellemző a low és mid range mikrokontrollerekre, mert ezeknek más a célja mint egy mikroprocesszornak, ritkán mozgatnak sok adatot, a 24 és dsPIC család viszont tartalmaz már DMA-t, ha nem is minden típus.

Már az új 8 bitesekben is van DMA.

Sziasztok!

Azt olvastam valahol, hogy előre megírt függvények vannak az MPLAB X IDE v5.50 környezetben. Hogyan lehet ezeket előcsalni?

Köszönöm!

Mire is gondolsz pontosan? Megnézed az include fájlokat, benne vannak a definíciók...
Egyébként meg külön letölthető graphics, tcpip stb library a Microchiptől.
Mostanában nem néztem, de külön letölthető a Microchip Code Configurátor...

Ha a Code Configuratorra gondolsz, itt találsz róla némi infót: MPLAB® Code Configurator.

Srácok MPLAB X stimulus létrehozásában van valaki aki jártas?
Tesztelném a programomat és a 3 fázist illetve a 3 fázis okozta különböző megszakításokat kellene tesztelnem szimulátorban.

Meg lehet ezt egyáltalán tenni?
Köszi előre is.

Csak az MpLba 8 -on használtam stimulust.
Itt lehet találni módszereket.
Register injection: Egy regiszter értékét lehet a stimulussal beállítható idővel vagy időközönként módosítani.

Igen, google-val kezdtem én is. MBLAB X kicsit bohóckodik, de biztosan rájövök egy helyes beállításra. Egyszer..

Sziasztok!

Tudnátok segíteni, hogy vajon a valóságban miért nem működik ez a program? 4 bites LCD vezérlés. Az Az A0 bemeneten lévő feszültséget szeretném kijeleztetni. A D0-t kötöttem az LCD D4 lábára...... és a D3 kimenetet a D7 lábára. Azt gondolom, hogy az iniciálást ronthattam el. (8 bites vezérléssel működik) Az MPLAB szimulátora alapján a PORTD rendben van. PIC16F877A mikrovezérlőt használok és 2×16-os LCD kijelzőt.
Köszönöm!

Megoldódott! Segítségképpen, ha esetleg másoknak is hasonló problémája lenne, az volt a baj, hogy a 0x30-as és a 0x20-as parancsot még 8 biten kell kiadni és csak ez után 2×4 biten.

Üdv. Mindenkinek! Kérdezném, hogy vállalna-e valaki egy PIC18F458-as kicserélését programozással.
Köszönöm.

Pár infó azért még nem ártana hozzá. Pl. ki van vezetve a programozó felület? Meg van az eredeti hex állomány? Hogy néz ki a panel, amelyen dolgozni kellene? Kb. ilyen kérdések biztos érdekesek, annak aki vállalná.

Ha jobban körülírod a feladatot (akár magánban is), lehet, hogy vállalom (Bp. 1173)

Üdv. Ez egy op-com. Hamis PIC18FXXXX-el. Egyébként működik. Azt hiszem,hogy kint kell felprogramozni.

Üdv. Ez egy op-com. Hamis PIC18FXXXX-el. Azt hiszem kint kell a programot rátenni.