Fórum témák

» Több friss téma
Fórum » PIC kezdőknek
 
Témaindító: Placi84, idő: Okt 3, 2005
Témakörök:
- A PIC ÖSSZES Vdd és Vss (AVdd és AVss) (tápfeszültség) lábát be kell kötni!
- A táplábak mellé a lehető legközelebb 100nF-os KERÁMIA kondenzátorokat kell elhelyezni.
- Az MCLR lábat, 10kohm-mal fel kell húzni a Vdd tápfeszültségre.
- Külső kvarc használatakor 4MHz-ig XT, a fölött pedig HS konfigurációt kell beállítani.
- Stabilizált tápegységet kell használni, a kapcsoló üzemű "telefon töltő" adapterek okozhatnak hibákat.
- Programozáshoz, használj lehetőleg PICKIT2 vagy 3 programozót. Kerülendő a JDM (soros porti) programozó.
- A PIC adatlapja (PDF), tartalmazza a lábak kiosztását és a PIC minden paraméterét. Az adatlap ingyen letölthető!
- Egyes PIC típusoknál az RA4 nyitott nyelőelektródás (Csak lefelé húz L szintre, H szintet nem ad ki!)
- Ha a PGM lábat digitális ki-/bemenetnek használod, az alacsony feszültségű programozási lehetőséget le kell tiltani.
Lapozás: OK   1189 / 1203
(#) Bakman válasza oregharcos hozzászólására (») Jan 23, 2023 / 1
 
Ha jól értem, neked ilyesmire van szükséged:
  1. char jatek = 0;
  2.  
  3. void balroljobbra(void) {
  4.     LED = 1;
  5.     Delay_nyg(150);
  6.     for (i = 0; i < 7; i++) {
  7.         LED = LED << 1;
  8.         Delay_nyg(150);
  9.     }
  10. }
  11.  
  12. void jobbrolbalra(void) {
  13.     LED = 128;
  14.     Delay_nyg(150);
  15.     for (i = 0; i < 7; i++) {
  16.         LED = LED >> 1;
  17.         Delay_nyg(150);
  18.     }
  19. }
  20.  
  21. void odavissza(void) {
  22.     LED = 1;
  23.     Delay_nyg(150);
  24.     for (i = 0; i < 7; i++) {
  25.         LED = LED << 1;
  26.         Delay_nyg(150);
  27.     }
  28.     for (i = 0; i < 6; i++) {
  29.         LED = LED >> 1;
  30.         Delay_nyg(150);
  31.     }
  32. }
  33.  
  34. void szerteszet(void) {
  35.     LED = 8;
  36.     Delay_nyg(150);
  37.     for (i = 0; i < 4; i++) {
  38.         LED = LED >> 1;
  39.         Delay_nyg(150);
  40.     }
  41.     LED = 16;
  42.     Delay_nyg(150);
  43.     for (i = 0; i < 4; i++) {
  44.         LED = LED << 1;
  45.         Delay_nyg(150);
  46.     }
  47. }
  48.  
  49. void nygfigy(void) {
  50.  
  51.     if (PORTB.F0 == 0) {
  52.         jatek = 10;
  53.     }
  54.     if (PORTB.F1 == 0) {
  55.         jatek = 11;
  56.     }
  57.     if (PORTB.F2 == 0) {
  58.         jatek = 12;
  59.     }
  60.     if (PORTB.F3 == 0) {
  61.         jatek = 13;
  62.     }
  63.  
  64. }
  65.  
  66. void main(void) {
  67.  
  68.  
  69.     while (1) {
  70.  
  71.         nygfigy();
  72.  
  73.         switch (jatek) {
  74.  
  75.             case 10:
  76.                 balroljobbra();
  77.                 jatek = 0;
  78.                 break;
  79.  
  80.             case 11:
  81.                 jobbrolbalra();
  82.                 jatek = 0;
  83.                 break;
  84.  
  85.             case 12:
  86.                 odavissza();
  87.                 jatek = 0;
  88.                 break;
  89.  
  90.             case 13:
  91.                 szerteszet();
  92.                 jatek = 0;
  93.                 break;
  94.  
  95.         }
  96.  
  97.  
  98.     }
  99. }
(#) oregharcos válasza don_peter hozzászólására (») Jan 23, 2023 /
 
Üdv. Don_Peter! Köszönöm a segítő választ és, hogy foglalkozol vele! Ha időm engedi kidolgozom részletesen úgy, hogy értető legyen és majd felrakom a programot átnézésre. Nagy-nagy köszönet!
(#) oregharcos válasza Bakman hozzászólására (») Jan 25, 2023 /
 
Üdv. Bakman! Nagyon köszönöm a segítséget, ez egy jól átlátható program! Majd beszámolok, hogyha sikerül megoldani.
A hozzászólás módosítva: Jan 25, 2023
(#) don_peter hozzászólása Jan 31, 2023 /
 
Srácok volt itt anno egy srác vagy több is nem tudom, aki tudott segíteni assembler programozásban. Akkor egy M68K-ra akartam írni egy delay rutint.

Most akadt egy problémám és sanszos itt előbb kapok rá választ mint más topikban.
Nagyon egyszerű lesz ígérem..
  1. move.l #$2410, a0
  2.     move.b (a0)+, d1

Kérdésem pedig az ami a csatolt képen is látszik, miért nem kerül bele a 10 D0 regiszterbe?
Előre is köszi.

md8.PNG
    
(#) icserny válasza don_peter hozzászólására (») Feb 1, 2023 / 1
 
Nem akarok hülyeséget mondani, de nem azért, mert nem az a0 regiszter tartalmát másolod, hanem az általa megcímzett memóriából veszel elő egy bájtot?
Bővebben: Link
A hozzászólás módosítva: Feb 1, 2023
(#) don_peter válasza icserny hozzászólására (») Feb 1, 2023 /
 
De igen, közben rájöttem a balgaságomra..
Köszi.
(#) Zsora válasza don_peter hozzászólására (») Feb 4, 2023 / 1
 
Ha esetleg nem lenne neked meg:
MOTOROLA M68000 FAMILY Programmer’s Reference Manual

M68000PRM.pdf
    
(#) don_peter válasza Zsora hozzászólására (») Feb 8, 2023 /
 
Köszi le is szedtem.
(#) don_peter hozzászólása Feb 9, 2023 /
 
Uraim!

Nincs véletlen valakinek egy mérése PIC18F452 vagy hasonló MCU esetében az SPI olvasásra?
Használom a PLL-t és 10MHz külső kvarccal összesen 40MHz-el pörög, az SPI 10MHz-en van hajtva.
Főként arra lennék kíváncsi, hogy ha assemblyben lenne írva a program, mennyivel lenne gyorsabb egy SPI és úgy ám-blokk az egész programom.

Tegnap este újra elővettem a VGM lejátszó projektem és méregettem mert pár napja egy ismerősöm elkészítette nekem Z80-ra - amely mindössze 3.8MHz-es - ugyan ezt a programot (kivéve, hogy ott ROM-ból olvas vagy is az SPI lassítása kimarad) assemblyben. Nem azt mondom, hogy tökéletesen lejátszik mindent, de klasszisokkal jobb mint az én C-ben írt P18F452-es változatom.

Tegnapi olvasási eredményeim:
Ebben az esetben a MemRead() egy függvényhívás, amelyben minden további fontos rész mint pl. a WaitForMem() memóriára várokoztatás és az SPI() 1 byte adat vétele is külön függvényben vannak. Mivel ez egy flash memória, így a következő adatok kellenek egy olvasáshoz:
SPI(CMD_READ), SPI(MemCim.low), SPI(MemCim.high), SPI(MemCim.hh) majd ezek után kapjuk meg az adatot: adat= SPI(0x00)
  1. Sample = MemRead(MemCim);                       // 64.4uS


A következő amit megnéztem, hogy egyetlen byte olvasása még is mennyi ideigtart:
  1. Sample = SPI(0x00);                     // 8.2uS


Aztán ugyan ez függvényhívás nélkül:
  1. // SPI(0x00) függvény hívás nélkül        // 4.2uS
  2.         SSPSTATbits.BF = 0;
  3.                 SSPCON1bits.WCOL = 0;
  4.                 Sample = SSPBUF;
  5.                 SSPBUF = 0x00;
  6.                 while(!SSPSTATbits.BF);
  7.                 Sample = SSPBUF;

Majd ezt követően készítettem egy sajtá MemReadFast() függvényt, amely ömlesztve tartalmazza az 1byte adat olvasását, vagy is nincs benne más függvény hívás önmagában le fut:
  1. Sample = MemReadFast(MemCim);   // 34.2uS


Látható, hogy hogy minden optimalizálással elértem valamennyi változást, de még ez is kevés ahhoz, hogy legalább a Z80-al megvalósított szintet hozza a programom.
A következő még ami eszembe jutott, mert nem tudok PIC-et assemblyben programozni, hogy az adatokat tömbösen olvasom ki, mert van lehetőségem egyszerre 64byte adatot olvasni illetve a teljes VGM lejátszó programot ömlesztve további függvényhívások nélkül belepakolom a megszakításba, úgy még talán nyerhetek némi időt, de véleményem szerint ezek sem lesznek elégek.
Minden mérésem oszcilloszkóppal történt, örök ciklus és egy led billegtetésével, amely picit emel az időközökön, de ez csak a javamra történik.
Előre is köszi, ha ezt végig olvasod.
(#) Bakman válasza don_peter hozzászólására (») Feb 9, 2023 /
 
Ha a programban tudod biztosítani, hogy ne okozz írási/olvasási torlódási hibát, akkor ennyi is elég lehet:
  1. SSPBUF = 0x00;
  2. while(!SSPSTATbits.BF);
  3. Sample = SSPBUF;

Ha ennyire ki vannak számítva az idők, könnyen előjöhetnek az XC8 fordító ingyenes változatának szemetelései. Ezt DMA-val ki lehet kerülni lévén tudsz egyszerre 64 bájtot olvasni, mert szerencsére a HW működését nem lassítja a gyenge programkód optimalizálás. Igaz, ehhez kontrollert kell váltani.

szerk.:
  1. SSPSTATbits.BF = 0;

sornak nincs értelme, mert adott bit csak olvasható.
A hozzászólás módosítva: Feb 9, 2023
(#) don_peter válasza Bakman hozzászólására (») Feb 9, 2023 /
 
MPLAB v8.91-et használok.
Nem kell a memóriára várni?
Egymást követően kell olvasni, nem jöhet közbe semmi tényező, ami felboríthatja a sorrendet.
(#) benjami válasza don_peter hozzászólására (») Feb 9, 2023 /
 
Nem a fejlesztőkörnyezet, hanem a C fordító határozza meg. Az ingyenes változatú C fordítók tragikus kódot csinálnak, ott semmin ne csodálkozz. Nem tudom most is van-e lehetőség 30 vagy 60 napig teljesértékűként használni a C fordítókat, ha igen akkor tedd fel 30 vagy 60 naponként virtuális gépre, és kapcsold be az optimalizálási lehetőségeket a fordításhoz.
(#) don_peter válasza benjami hozzászólására (») Feb 9, 2023 /
 
C18-at használok és PRO verziót.
Át írtam a teljes kódot és minden felesleges részt kivettem, de sajnos még így sem lett jó.
Arra rájöttem, hogy nem az SPI és az adatok olvasása lassítja be a dolgot, hanem maga a megszakítás és a VGM switch case kiértékelés. Teljesen szétcsúszik az egész.
Mértem a főprogramom ciklusidejét, összesen egy LED villogtatásával 2 ciklus közt 600nS telik el. Ez is úgy, hogy a LED villogtatását a következő utasítás állítja:
  1. LED1 = !LED1;

Ha a LED villogást if() feltételben adom meg, 1.3Us-ra ugrik a ciklusidő.
  1. if(LED1==1) LED1 = 0; else LED1 = 1;

Azon gondolkodtam, hogy assemblyben adom meg a LED világost, de nem tudtam illeszteni a C18 közegbe. Így próbáltam:
  1. _asm   
  2.                         BTFSS 0xf8d, 0x2, ACCESS        ; if(LED1==1)
  3.                         BRA 0x17a2
  4.                         BCF 0xf8d, 0x2, ACCESS          ; LED1 = 0;
  5.                         BRA 0x17a4
  6.                         BSF 0xf8d, 0x2, ACCESS          ; LED1 = 1;
  7.                 _endasm

Sajnos PIC esetében teljesen kimaradt az assembly, már bánom, de ez van.
(#) Hp41C válasza don_peter hozzászólására (») Feb 9, 2023 / 1
 
Használd a Disassembly ablakot.
A
  1. LED1 = !LED1;

utasítás a #define LED1 LATEbits.LATE2 kiértékelése után a
  1. btg LATE,2, ACCESS

utasításra fordul.

40MHz órajellel járó 18F452 100us utasítás végrehajtási idő jelent.
  1. Ide: btg LATE,2, ACCESS
  2.          bra  Ide

Program 300us alatt fut le (ugrás +1 ciklus), a villogás 600us periódusidejű.
Ennél gyorsabb csak nagyobb órajel frekvenciával járatható típussal érhető el:
48 ill 64 MHz -es típusok is kaphatók (pl. 18F4550 ill. 18F45Q43) .
(#) don_peter válasza Hp41C hozzászólására (») Feb 9, 2023 /
 
Használom, köszi.
Idézet:
„40MHz órajellel járó 18F452 100us utasítás végrehajtási idő jelent.”

Vagy is 100nS nem? Mert 1/40MHz = 25nS, egy utasítás pedig 4 órajel, így jön ki.

De a kérdés nem ez volt.
(#) don_peter hozzászólása Feb 9, 2023 /
 
Közben megnéztem a két megoldás közt van e különbség, de sajnos nincs. nS-re pontosan ugyan annyi a ciklus idő. Mind kettő esetében 600nS.
  1. while (1){LED1 = !LED1;}    // 600nS
Asm változat:
  1. _asm    // 600nS       
  2.     Ide: btg LATE,1, ACCESS
  3.     bra  Ide
  4. _endasm

Azt hittem lesz majd különbség, de semmi.
Lehet azért mert ez egy nagyon egyszerű példa, de komplexebb megoldásokat nem tudom tesztelni. Könnyes szemmel, de félre kell toljam ezt a PIC-et, legalább is ezen feladat kapcsán.
A hozzászólás módosítva: Feb 9, 2023
(#) Bakman válasza don_peter hozzászólására (») Feb 9, 2023 /
 
Nem teljesen értem a kérdést. Mit értesz az alatt, hogy a memóriára kell várni?

A DMA (már ha erre vonatkozik a kérdés) lényege az, hogy 'A'-ból 'B'-be rakja az adatokat a modul úgy, hogy közben CPU időt nem használ*. Megadod neki honnan, hova, mennyit, az6tán csak el kell indítani. Forrás lehet sok dolog, pl. RAM, SPI, I2C, EEPROM, programmemória, ADC eredménye stb. Célterület is lehet csomó hely, pl. PWM, RAM, SPI, PORT...

* A leírás szerint a DMA modul a CPU holtidőket használja, de lehet priorizálni a folyamatokat. Ha a DMA a legmagasabb prioritással rendelkezik, akkor működés közben a CPU csak azzal foglalkozik, a felhasználói program futása addig szünetel.

szerk.:
S: Siemens (vezetőképesség)
s: secundum (másodperc)
A hozzászólás módosítva: Feb 9, 2023
(#) don_peter válasza Bakman hozzászólására (») Feb 9, 2023 /
 
Az SPI memória kezelésénél apaesetben van egy WaitForMemory() függvény, vagy is várakozik, addig ameddig elfoglalt a memória. Ezeket most kiszedtem. Nincs DMA, sima SPI olvasás és írás van. A kínlódásom a sebesség növelése miatt van, de ha már egy ciklus egy LED villogásával 600nS időbe kerül, és egy egyszerű if() elágazás 1.3uS / ciklus, akkor itt több kérdés nem nagyon lehet. Akár hogy agyalok vagy próbálkozom mindig oda jutok, hogy kevés ez a PIC ehhez a feladathoz, csak nem akartam elengedni és vergődtem még pár kört.
Hiába 40MHz PLL-el, ha kapásból 1 utasítás 4 órajel vagy is rögtön vissza esünk 10MHz-re, majd ezt követően, ha egy ugrást nézünk az 8 órajel, akkor ott meg 5MHz-re csökken a sebesség és így tovább... Nem lesz ez így jó soha.
(#) asch válasza don_peter hozzászólására (») Feb 9, 2023 / 1
 
A periódusidő amit mérsz 600ns, de ez azt jelenti, hogy a két utasítás 300ns alatt fut le, ahogy Hp41C is írta. Csak ugye egyik körben megy fel, a másikban jön le a kimenet, tehát a program periódusidejének a kétszerese lesz a mért jel periódusideje.

Nem lehet, hogy a többi mérésnél is ezzel a kétszeres értékkel számoltál? Mindjárt jobban fognak kinézni a számok, ha meg lehet felezni őket!

A memória olvasást ha blokkokban csinálod, akkor 6 SPI művelet helyet átlagban alig több mint egy SPI művelet marad, tehát ez is majdnem hatszoros sebesség lehet. Ha az SPI egy program ciklus alatt (10MHz) szintén egy SPI clock ciklust csinál, akkor jön ki kb 1.25us alatt át kellene menni egy bájtnak az SPI-n. Én mindenképpen megmérném az SPI clockot szkópon és összevetném az adatlappal, hogy annyi-e, amennyinek lennie kell. Nem teljesen világos nekem, de elvileg nem 10MHz-nek kellene lennie?

Ha kimérted az SPI idejét, akkor elvileg azt is meg lehet csinálni, hogy az SPI-t átlapolod a program többi részével:

SPI indítás
logika futtatása
SPI indítás
logika futtatása
SPI indítás
logika futtatása

Ha pontosak az időzítések a programban(persze ehhez ASM szintre kell menni szinte biztosan), akkor nem is kell ellenőrizni, hogy az előző SPI befejeződött-e már, mivel determinisztikusan mindig adott órajel alatt be fog fejeződni, nem tud másképp történni, mivel masterről van szó.

Ha jól emlékszem hang lejátszás a téma, igaz? Az a megoldás, amit javasoltam, hogy bonyolult kódolás helyett csak PCM hangminták legyenek az SPI-vel elérhető RAM-ban, az nem volna lehetséges? 22us van egy mintára (44.1kHz mintavételt feltételezve), ha blokkosítod az SPI olvasást, akkor mintnánként két bájt is beleférhet ebbe az időbe simán.
A hozzászólás módosítva: Feb 9, 2023
(#) don_peter válasza asch hozzászólására (») Feb 9, 2023 /
 
Uhh basszus igazatok van, duplán érkezik jel, megfeledkeztem arról, hogy két állapotot van és azt mérem szkóppal. Osztani kell kettővel minden mérésemet. Hogy ezt nem vettem észre, azért nagyon gáz. Vagy annyira kerestem a hibát, hogy nem láttam az fától az erdőt.

Az SPI innentől már nem érdekes, mert nem az lesz a gyenge láncszem, talán ezt korábban te is említetted, akár hogy befolyásolom az SPI s adat olvasást se jobb sem rosszabb nem lesz, szerintem az hozza az elvártakat. Más gond van, talán a PCM vezérlést nem tudja olyan gyorsan végrehajtani mint kellene. A PCM jelek esetenként 8KHz-esek de vannak olyan VGM zenék, amelyekben 16KHz-esek a minták. A leggyakoribb azonban, hogy 11KHz-es PCM minták vannak. Ezeket már sikerült egyértelműen meghatározni.
Kicsit átnézem ebben az új kontextusban a programot, mert ha osztok kettővel, akkor igencsak benne vagyok a keretben. De legalább is közelebb mint eddig gondoltam.
A LED villogás periódusát tekintve én 2 ciklus idejével számoltam mindent, és ez tévedés volt a részemről. Durva hogy ezt ennyire benéztem.
(#) asch válasza don_peter hozzászólására (») Feb 9, 2023 /
 
A VGM dekódert ha ügyesen írod meg (HAL layert csinálsz ügyesen), akkor futtathatod PC-n is. Ugyanazt a C programot PC-n futtatod, de a zenét nem játszod le, hanem a mintákat csak kiírod egy fájlba binárisan. Utána le tudod játszani parancssori programmal is.

Innen: https://stackoverflow.com/questions/20314739/how-to-play-pcm-sound-...ubuntu
  1. ffplay -f s16le -ar 16k -ac 1 snake.raw
ez a parancs egy fájlból 16 bites előjeles mintákat játszik le. Az ffplay.exe program Windowsra is létezik, ha azon dolgozol.

Ezen a módon jócskán fel tudod gyorsaítani a fejlesztést.

Ha jól emlékszem azt mondtad, hogy a PCM kimenet I2C periférián keresztül működik? Erre ugyanúgy tudsz számításokat csinálni, hogy elvileg milyen gyors lesz. És ugyanúgy párhuzamosíthatod a program többi részével: csak párszor kell hozzányúlni, kiírni a címet és utána az adatot. De nem kell bevárni, csak ki kell írni a periféria regisztereibe a megfelelő pillanatban ezeket.

Én így csinálnám:
* Főprogram dekódolja a VGM-et és egy ringbufferbe írja a kimenet mintáit. (A ringbuffer miatt csak átlagban kell real time képesnek lennie!) Ha a kimenet tele van, akkor a főprogram vár.
* Időzítő interrupt indítja a PCM kiemenet írását a ringbufferből kivéve a mintákat. Az I2C kommunikációt interrupt vezérli. Így ennek a tempója meglehetősen egyenletes lesz a megfelelő mintavételi frekvencia szerint.
(#) don_peter válasza asch hozzászólására (») Feb 9, 2023 /
 
Ezeken nagyrészt túl vagyok és lehet túl is teljesítettem már..
Bővebben: Link
Írtam egy programot, amely a VGM zenékből exportálja a PCM adatokat kvázi importálható C állományként, ezt már tán 1 éve megírtam. A mostani programmal a PCM adatokat, hangmintákat (hangszereket) raw és wav formátumban is exportálom, így fel tudom használni ha szükséges. A linkelt blogom erről szól.

Ezt a VGM programot már megírtam a következőkre: PIC18F452, lassú most is ezt optimalizálom, jelenleg 51uS alatt dolgozza fel az adatokat de lassú mert a megszakítás 22.7uS lenne, így húzza a szalagot.. (körülbelül 2szer lassabb a kelleténél)

Megírtam PIC18F46K22-re, ott picit jobba a helyzet, de az optimalizált kódokat még nem vittem át, majd kipróbálom.

Megírtam STM32F103RF-re, ott egésze jól szól, de még ott is optimalizálnom kell, sokkal jobb egyébként, mondjuk gyorsabb is a maga 72MHz-ével.

Megírtam Motorola 68000-re, ott assembly nyelven, ott majdnem tökéletes a lejátszás, a komolyabb PCM adatoknál érezhető csak kissé a belassulás, de teljesen élvezhető.

Segédkeztem (nem én írtam) Z80-ra is megírni a programot. Teljesen rendben megy rajta, itt is csak a komolyabb PCM adatoknál érezhető egy kis belassulás.

Megírtam PC-re is, de ott csak a kiértékelés és exportálás miatt. Szóval van benne már munkám rendesen.

Az egész hardvert amit megépítettem azon van egy PIC, egy SPI flash, maga a YM2612, egy SN76489AN PSG aztán annyi. Ezzel kell dolgoznom a programban. Nincs I2C.
A PIC hozzáfér az SPI vonalhoz, teljes 8bit-es PORT-on pedig a YM és a PSG portjához párhuzamosan felváltva.

Ilyen a PSG változat:Bővebben: Link
Ez pl. tökéletesen működik.

És ilyen az amin most is kalapálok:Bővebben: Link
A hozzászólás módosítva: Feb 9, 2023
(#) tufatofu hozzászólása Feb 10, 2023 /
 
Sziasztok! Segítséget szeretnék kérni az alábbiakban.
A mellékelt 18F2455-re írt programot szeretném "belepaszírozni" egy 18F2550-be.
Ami még bonyodalmat okoz, hogy a 4x16 soros LCD helyett 2x16 sorost alkalmaznék, mert 2 sort használ fel a program a 4-ből. Találtam egy ilyenre lefordított hex verziót, ami működik is némi zavarokkal, de nem lett egészséges. Nagyon köszönök minden segítséget! A programozásban nem vagyok járatos, és fogalmam sincs, hogy kellene egy C programnak nekiesni, hogy hex-é váljon.

program.rar
    
(#) Hp41C válasza don_peter hozzászólására (») Feb 10, 2023 /
 
Valóban, us helzett ns -t kellett volna írnom.
A kérdés az, hogy elegendő-e a 18F452 teljesítménye a feladathoz. Nem.
(#) Hp41C válasza don_peter hozzászólására (») Feb 10, 2023 /
 
SPI adatblokk olvasása:
CS alacsony szintre - bcf PORTX,y -- 100ns
a parancs kiküldése - bcf SSPSTAT,BF; movlw 0x03; movwf SSPBUF -- 300ns
SPI kiküldi a parancsot -- 8 * 100 ns (ennyi idő várakozás vagy más feladat elvégzése)
cím felső byte kiküldése - movlw 0x03; movwf SSPBUF -- 200ns
SPI kiküldi az adatot -- 8 * 100 ns (ennyi idő várakozás vagy más feladat elvégzése)
cím alsó byte kiküldése - movlw 0x03; movwf SSPBUF -- 200ns
SPI kiküldi az adatot -- 8 * 100 ns (ennyi idő várakozás vagy más feladat elvégzése)

innentől lehet ismételni akárhány byte adatra
0 kiküldése - clrff SSPBUF -- 100ns
SPI kiküldi a parancsot -- 8 * 100 ns (ennyi idő várakozás vagy más feladat elvégzése)
adat elrakása - movf SSPBUF, w; movwf buffer -- 200us

befejezés
CS magas szintre - bsf PORTX,y -- 100ns

Megjegyzés: Lehet, hogy a Z80 lassabb, de a 8 adatbit egyszerre áll készen a beolvasásra.
(#) don_peter válasza Hp41C hozzászólására (») Feb 10, 2023 /
 
Köszi, hogy megnézted.
Én is arra jutottam, hogy tovább nem kalapálom a programot, szerintem kihoztam belőle amit lehetett.

Agyaltam azon, hogy főprogramban intézek mindent és megszakításban csak az adatokat írom ki a YM2612-nek, de a legjobb eredmény is, amit ki tudtam hozni a VGM feldolgozásából az 31uS. Esélytelen ezt már lejjebb vinni, mert ez az eredmény úgy született, hogy 0x00-ás parancsot dolgoz fel a VGM, vagy is azon kívül, hogy végig vizsgálja, hogy kell e valamit csinálnia nem tesz semmit és ez is 31uS időt visz el. Szóval erről ennyit. Köszi srácok.
(#) djadji hozzászólása Feb 11, 2023 /
 
Sziasztok! Segítséget kérnék. PIC, de nem szoftver.
Mindig problémám volt a mechanika kialakításával. Az oké, hogy megcsinálom a programot ami kapcsol egy relét, motorvezérlót, stb, de ez hogyan húz fel egy redőnyt? Hogyan nyit ki egy ablakot? Locsolja meg a virágot vagy fordítja el a napelem asztalt? stb... Szóval a mechanika kialakítását, hogyan lehet megoldani? Fogaskereket, ékszijtárcsát nincs lehetőségem esztergálni, venni meg nem tudok tárcsát egy 12V-os alblaktörlő motorra, vagy 5V-os játékmozgató motorra.
Van valakinek ötlete hogyan, miből lehet ezeket összeeszkábálni? 3D nyomtatás is jó lehet, de az anyaga lágyul már 40-50 fokon. Fából meg tudom csinálni, de azt se jó, ilyen kis fa fogaskerék nem megbízható.
Most pl szeretnék egy fóliasátor ablakot kinyitni a lehető legegyszerűbben, de nem tudok elkészíthető megoldást találni (tárcsák, ékszijjak, fogaskerekek legkevesebb alkalmazásával).
Van valakinek bevált megoldása ezekre a problémákra? Bolt, műhely, alapanyag?
(#) Bakman válasza djadji hozzászólására (») Feb 11, 2023 /
 
Konkrét kérdésre lehet konkrét választ adni.

Ablaknyitás:
A: Eszkábálsz magadnak valamit, ami vagy jó lesz vagy nem.
B: Megveszel egy kész nyitómotort amit csak be kell kötni és szerelni.

Ha kell, hétfőn pontos típust is tudok mondani. Ha a cégnél kibírnak 5-6 évet, akkor nálad örök élet lesz. Fóliasátor: pára, meleg, emiatt csak normális ipari kivitel jöhet szóba.
(#) djadji válasza Bakman hozzászólására (») Feb 11, 2023 /
 
Köszi szépen de ipari motor felesleges lenne. Ez egy 40x40 centis fóliázott ablak, ami akár lógva lengő is lehet. Így a nyitását egy 5voltos motor is el bírná végezni (csak kinyomja az alját). Némi áttétellel ha kell. De ez az áttétel és mozgatás megvalósítás okoz gondot. De ugyan ez volt a gondom a robot porszivónál. Megvan a motor és a vezérlés de hogy hajtsam meg a kereket vele? Nem tudok venni 3cm-es fogaskereket és hozzá tartozó 2cm-eset is az áttételhez. Vagy igen?
(#) KBal76 válasza djadji hozzászólására (») Feb 11, 2023 /
 
Messze ugyan a PIC téma innen, de fogaskereket, áttételt pl. itt tudsz venni, vagy akár itt is.
Következő: »»   1189 / 1203
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem