OK Mégsem
Fórum témák

» Több friss téma
Fórum » Arduino
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Lapozás: OK   625 / 854
(#) Rober_4 hozzászólása Máj 12, 2020 /
 
Sziasztok! Bocsánat az egyszerű kérdésért, de megakadtam. Szeretném a konkrét tömbjeim értékeit megváltoztatni egy eljárással, ami megkapja a konkrét tömböt, és annak értékeit tényleg meg is változtatja. (A nullázás itt csak fikció)
Ez így biztosan nem jó, valamilyen cím szerinti átadás kellene...
Segítségeteket köszönöm.

  1. uint16_t szamoktomb1[10];
  2. uint16_t szamoktomb2[10];
  3. uint16_t szamoktomb3[10];
  4. setup(){
  5. nullaz(szamoktomb1);
  6. nullaz(szamoktomb2);
  7. nullaz(szamoktomb3);
  8. }
  9. void nullaz(uint16_t szamoktomb[]){
  10. for(int i=0; i<10;i++)
  11. {
  12. szamoktomb[i]=0;
  13. }
  14. }
(#) GPeti1977 válasza sector99 hozzászólására (») Máj 12, 2020 /
 
Az nem jó, a bemenete nem rail to rail.
(#) Rober_4 válasza Rober_4 hozzászólására (») Máj 12, 2020 /
 
Lehet még is csak jó, viszont valamiért lassúnak tűnik...
(#) sector99 válasza GPeti1977 hozzászólására (») Máj 12, 2020 /
 
No erre nem figyeltem, illetve nem tudtam, hogy számít. Mert az MCP is úgy van hirdetve, de most néztem, hogy csak a kimenete az. Akkor pl. AD822, vagy LMV358 jó lesz ?
(#) Rober_4 válasza sector99 hozzászólására (») Máj 12, 2020 /
 
Kihozott egy hibát amit nem értek, de a tömbök átadása megtörténik...
Úgy néz ki annyira csúcsra van járatva az eszköz, hogy egyetlen plusz függvényhívás sem tud már behozni időben...
A hozzászólás módosítva: Máj 12, 2020
(#) sector99 válasza Rober_4 hozzászólására (») Máj 12, 2020 /
 
Bocs, mellékattintottam !... nem Neked szántam a választ...
Én más ügyben kérdeztem és sajna a programozáshoz sem értek..
A hozzászólás módosítva: Máj 12, 2020
(#) usane válasza Rober_4 hozzászólására (») Máj 12, 2020 /
 
Idézet:
„annyira csúcsra van járatva az eszköz, hogy egyetlen plusz függvényhívás sem tud már behozni időben”

Mit jelent az időben? Azért egy 10elemű tömb feltöltése nem olyan sok idő. Milyen eszköz?
(#) Rober_4 válasza usane hozzászólására (») Máj 12, 2020 /
 
Ilyenkor nem csak a címét adja át? Ha lemásolja, az nagyon sok idő...
Még azon is gondolkodtam még, hogy a for ciklusokban ha int-et használok, az a doksi szerint 32-bites szám Arduino Due-né. Esetleg kiváltható lehet uint16_t-vel, vagy byte-al, de lehet, hogy a fordító eleve optimalizálja?
(#) usane válasza Rober_4 hozzászólására (») Máj 12, 2020 /
 
Azt már tudom hogy Due-ról van szó, semmi mást. Mennyi idő alatt kell lefutni és minek?
Egy olyan rutinnak mint a nullaz? Az, hogy a for milyen változót használ sebesség szempontjából lényegtelen. Csak a memóriát viszi. Ha konkretizálnád, hogy mit kell elérni, mennyi a renselkezésre álló futásidő és minek kell alatta lefutni akkor jobban tudnánk segíteni, mert így csak általános dolgokkal dobálózunk.
(#) mateatek válasza sector99 hozzászólására (») Máj 12, 2020 /
 
A sima lm358 tökéletes oda. A bemeneteit teljesen le lehet húzni negatív tápig.
Hibakereséshez megpróbálnám azt, hogy az OPA kimenete helyére tennék egy potit, aminek a csúszkája van az ADC-n, a két végpontja pedig az 5 volton. Azzal tudod szimulálni az MCU felé a páka melegedését.
(#) sector99 válasza mateatek hozzászólására (») Máj 12, 2020 /
 
Ok, köszi az ötletet ! Akkor majd megpróbálom először potival.
(#) Rober_4 válasza usane hozzászólására (») Máj 12, 2020 / 1
 
Csúcsra van járatva a gép az audiobuffer számításai miatt. Minden centi számít. Mondjuk ha 32.bites a proci, akkor lehet nem leszek gyorsabb uint_16-tal, vagy bájttal...
Bocs nem terhelem vele a többieket, ez a projekt jár a vége felé
Link
Jelen esetben azt látom, hogy 3-4szer fel kell tölteni, hogy stabilan fusson. Jó lenne valahogy paraméterezni a fordítót...
(#) kapu48 válasza Rober_4 hozzászólására (») Máj 13, 2020 /
 
Van egy ötletem, de nem teszteltem. Próbáld ki.!
Legyen a tömb méreted 4-el osztható, és használd ki, hogy 32 bites procival egyszerre 2 * 16 bites értéket tudsz módosítani.
Így gondolom:
  1. #define TOMB_MERET  12
  2. uint16_t szamoktomb1[TOMB_MERET];
  3. uint16_t szamoktomb2[TOMB_MERET];
  4. uint16_t szamoktomb3[TOMB_MERET];
  5.  
  6. void setup() {
  7.   // put your setup code here, to run once:
  8.  
  9.   nullaz(szamoktomb1);
  10.   nullaz(szamoktomb2);
  11.   nullaz(szamoktomb3);
  12. }
  13.  
  14. void loop() {
  15.   // put your main code here, to run repeatedly:
  16.  
  17. }
  18.  
  19. void nullaz(uint16_t* szamoktomb){
  20.   uint32_t* pszamoktomb =  (uint32_t*)&szamoktomb[0];
  21.   for(uint16_t i=0; i<TOMB_MERET/2;i++)
  22.   {
  23.     *(pszamoktomb + i) = (uint32_t)0;
  24.   }
  25. }

Gondolom nagyobb méretű tömböket használsz, mert az egésznek csak akkor van értelme.
A hozzászólás módosítva: Máj 13, 2020
(#) kapu48 válasza kapu48 hozzászólására (») Máj 13, 2020 /
 
Lehet, hogy a for ciklus inkább így a jó:
  1. for(uint16_t i=0; i<TOMB_MERET/2; i += 4)
  2.   {
  3.     *(pszamoktomb + i) = (uint32_t)0;
  4.   }
(#) kapu48 válasza kapu48 hozzászólására (») Máj 13, 2020 / 1
 
Esetleg tovább fejlesztve, érték megadásával:
  1. #define TOMB_MERET  12
  2. uint16_t szamoktomb1[TOMB_MERET];
  3. uint16_t szamoktomb2[TOMB_MERET];
  4. uint16_t szamoktomb3[TOMB_MERET];
  5.  
  6. void setup() {
  7.   // put your setup code here, to run once:
  8.  
  9.   nullaz(szamoktomb1, 0);
  10.   nullaz(szamoktomb2, 0x12345678);
  11.   nullaz(szamoktomb3, 0xFFFFFFFF);
  12. }
  13.  
  14. void loop() {
  15.   // put your main code here, to run repeatedly:
  16.  
  17. }
  18.  
  19. void nullaz(uint16_t* szamoktomb, uint32_t ertek){
  20.   uint32_t* pszamoktomb =  (uint32_t*)&szamoktomb[0];
  21.   for(uint16_t i=0; i<TOMB_MERET/2; i++)
  22.   {
  23.     *(pszamoktomb + i) = (uint32_t)ertek;
  24.   }
  25. }
A hozzászólás módosítva: Máj 13, 2020
(#) kapu48 válasza Rober_4 hozzászólására (») Máj 13, 2020 / 1
 
Tömb kezelésnél csak cím átadás van a függvénynek.
Nem készül másolat mint a változók esetében.
(#) Rober_4 válasza kapu48 hozzászólására (») Máj 13, 2020 /
 
Köszi, ne menj bele jobban, még átrágom, hogy tudom e gyakorlatban használni!
(#) kapu48 válasza Rober_4 hozzászólására (») Máj 13, 2020 / 1
 
A Pointerek kezelését és a memória címzés aritmetikát, itt írjak le:
Bővebben: Mutatók és tömbök
(#) kapu48 válasza Rober_4 hozzászólására (») Máj 13, 2020 / 1
 
Érdeklődésből bele lestem a közölt programodba.
Mérete miatt több időt kellene rá szánni az egész folyamat megértéséhez.
És nem is tudom hól idő érzékeny, hol érdemes optimalizálni?

Csak egy ötlet 2 érték beolvasása és össze adása helyet, ha a művelet csak sor számlálás.
Gyorsabb lenne egyszerűen csak növelni az értéket.
Pl:
  1. void save() {
  2.   //saveprog
  3.   unsigned int kezdocim = saveprog * 128; // Cím számításkor legyen a mutató mindig unsigned int
  4.   dueFlashStorage.write(kezdocim++, op1waveform);
  5.   dueFlashStorage.write(kezdocim++, op2waveform);
  6.   dueFlashStorage.write(kezdocim++, op3waveform);
  7.   dueFlashStorage.write(kezdocim++, op4waveform);
  8. ...
  9. }
A hozzászólás módosítva: Máj 13, 2020
(#) Rober_4 válasza kapu48 hozzászólására (») Máj 13, 2020 /
 
Igen, köszönöm! Ne nézd a régi kódot, mert van új, ahol rengeteg rész át lett írva már!
Egy kicsit rendbe szedem, és elküldöm, és jelölöm a sebességérzékeny pontokat, mert nagyon sok hibát kiküszöböltem, rájöttem, hogy a burkológörbék nem lehetnek lineálisak, hanem valamilyen exponenciális görbét kell kreálnom, így sokkal finomabban szabályozhatóak, a modulátorok, illetve az effekt rész is új motort kapott! A memóriaírás egyszeri alkalom, nem árt ha gyors, de azt a részt még nem teszteltem, mert még változnak a hangszínparamétereim is, az kb a legvége mert ugye egy új feltöltésnél, minden régi adatnak kampec.
A pointeres cikket átrágom, hátha valahol tudom használni...
A hozzászólás módosítva: Máj 13, 2020
(#) icserny válasza GPeti1977 hozzászólására (») Máj 13, 2020 /
 
Ez így rendben van. Remélhetőleg a FET lábai sincsenek összekeverve.
Most akkor ebben az állapotban (amikor a Q1 tranzisztor lehúzza földre a GATE elektródát) kellene körbeméregetni, hogy mi van a TEMP_SENSE ponton, illetve a műveleti erősítő lábain.
(#) benjami válasza Rober_4 hozzászólására (») Máj 13, 2020 / 1
 
Memória feltöltésre és másolásra igénybe lehet venni a DMA-t is. Ha csak kivárod amíg elkészül a DMA tranzakció akkor nem lesz gyorsabb, de ha a művelet elkészültéig más tevékenységet csinálsz. akkor sok processzor időt lehet spórolni.
(#) kapu48 válasza Rober_4 hozzászólására (») Máj 13, 2020 / 1
 
Ha mernéd tömbökbe helyezni az összetartozó változókat, akkor lényegesen egyszerűbben kezelhetnéd őket.

Ezzel a példával viszont biztosan a lényeges részeket gyorsíthatnád:
(A // mögé rakott sorokat cseréltem ugyanazok tömbösített megoldásaira.)
  1. #define GORBE_SIZE  2048
  2. //uint16_t op1gorbe[GORBE_SIZE];
  3. //uint16_t op2gorbe[GORBE_SIZE];
  4. //uint16_t op3gorbe[GORBE_SIZE];
  5. //uint16_t op5gorbe[GORBE_SIZE];
  6. //uint16_t op4gorbe[GORBE_SIZE];
  7. //uint16_t op6gorbe[GORBE_SIZE];
  8. uint16_t opGorbe[6][GORBE_SIZE];
  9.  
  10. //uint16_t op1level[8];
  11. //uint16_t op2level[8];
  12. //uint16_t op3level[8];
  13. //uint16_t op4level[8];
  14. //uint16_t op5level[8];
  15. //uint16_t op6level[8];
  16. uint16_t opLevel[6][8];
  17.  
  18. //uint16_t op1veloc = 64;
  19. //uint16_t op2veloc = 64;
  20. //uint16_t op3veloc = 64;
  21. //uint16_t op4veloc = 64;
  22. //uint16_t op5veloc = 64;
  23. //uint16_t op6veloc = 64;
  24. uint16_t opVeloc[6] = {64, 64, 64, 64, 64, 64};
  25.  
  26.  
  27. //uint16_t  wave0veloc = 64;
  28. //uint16_t  wave1veloc = 64;
  29. //uint16_t  wave2veloc = 64;
  30. //uint16_t  wave3veloc = 64;
  31. //uint16_t  wave4veloc = 64;
  32. //uint16_t  wave5veloc = 64;
  33. //uint16_t  wave6veloc = 64;
  34. //uint16_t  wave7veloc = 64;
  35. uint16_t  waveVeloc[8] = {64, 64, 64, 64, 64, 64, 64, 64};
  36.  
  37. //byte  op1waveform = 1;
  38. //byte  op2waveform = 1;
  39. //byte  op3waveform = 1;
  40. //byte  op5waveform = 1;
  41. //byte  op4waveform = 1;
  42. //byte  op6waveform = 1;
  43. byte  opWaveform[6] = {1, 1, 1, 1, 1, 1};
  44.  
  45. //uint16_t op1volume;
  46. //uint16_t op2volume;
  47. //uint16_t op3volume;
  48. //uint16_t op5volume;
  49. //uint16_t op4volume;
  50. //uint16_t op6volume;
  51. uint16_t opVolume[6];
  52.  
  53. int gorbetime[8] = { -1, -1, -1, -1, -1, -1, -1, -1};
  54.  
  55.  
  56.  
  57. void setup() {
  58.   // put your setup code here, to run once:
  59. //         op1level[1] = op1gorbe[gorbetime[1]] * op1volume * (wave1veloc / op1veloc);
  60. //          op2level[1] = op2gorbe[gorbetime[1]] * op2volume * (wave1veloc / op2veloc);
  61. //          op3level[1] = op3gorbe[gorbetime[1]] * op3volume * (wave1veloc / op3veloc);
  62. //          op4level[1] = op4gorbe[gorbetime[1]] * op4volume * (wave1veloc / op4veloc);
  63. //          op5level[1] = op5gorbe[gorbetime[1]] * op5volume * (wave1veloc / op5veloc);
  64. //          op6level[1] = op6gorbe[gorbetime[1]] * op6volume * (wave1veloc / op6veloc);
  65.     for(uint8_t i = 0; i<6; i++){
  66.        opLevel[i][1] = opGorbe[i][gorbetime[1]] * opVolume[i] * (waveVeloc[1] / opVeloc[i]);    
  67.     }
  68.  
  69. }
  70.  
  71. void loop() {
  72.   // put your main code here, to run repeatedly:
  73.  
  74. }

Ez csak egy példa a sok számításaid közül.
(#) Rober_4 válasza kapu48 hozzászólására (») Máj 13, 2020 / 3
 
Igen ezzel heteket töltöttem el, hogy tömbökben legyenek már így is. De bizonyos esetekben, egyszerűen belaggolt tőlük, szerintem pont azért mert van benne egy for ciklus számlálóléptetéssel, és emiatt mindig visszakoztam. De ha jól tudom azt az opciót fogom használni, hogy tömbök lesznek, de egyenként kapnak értéket, akkor hátha gyorsabb futású lesz az összetartozó értékek miatt. Tehát teljesen igaz, nem merem, és tudom, hogy emiatt nagyon csúnya a kód. (De ne a régi kódot nézd, bár ebben teljesen igazad van, mert ez ebben sem változik)
Egyébként a sebességért a főprogram felel. Ami meg lényegtelen még, az a generátorinit, a program illetve az effect. Az effect részt nem is használom. A főprogiban(analogszintiharminchat) az 1387.sornál, az eqreverb rész, ahol páros és páratlan bufferindexenként keverem a kórus illetve reverb effectet az eredeti jelhez, ami rengeteg erőforrást elvisz.
Illetve a controller rész, potik és gombok beolvasása nem tudom lehet-e gyorsabb?
Illetve az lcd rész lcdreefresh eljárása is lefut minden buffer*frameperiódusban, (46.sor)így az is viszi az erőforrást... Ha nézegeted, akkor inkább ezeket

analogszinti...rar
minta.mp3		   
(#) Rober_4 válasza Rober_4 hozzászólására (») Máj 13, 2020 /
 
A csatolt hangminta a hangszer saját 12bites hangja, semmilyen külső effekt nincs rajta...
(#) kapu48 válasza Rober_4 hozzászólására (») Máj 13, 2020 /
 
Dobd ki az LCD-t vezérlő IIC modult és használj 8 bites adatvonalat.
És minden be lassulás csökkenni fog.
(#) Rober_4 válasza kapu48 hozzászólására (») Máj 13, 2020 /
 
Ezt kibeszéltük pár hete. Elvileg 1 karaktert léptetek vagy írok egy időpontban. Külön algoritmussal kezelem, hogy mikor hova kell írni, és lépni az lcd-nél. Bár lehet, hogy lehet még azon az algoritmuson javítani. Minden programbeli írás, csak egy tömbbe ír, az lcdreefrish vezérli, a kiírást. Mondjuk itt a léptetés folyamatosan megy állandóan, de így legalább kiszámítható és állandó az algoritmus gépigénye.
(#) kapu48 válasza Rober_4 hozzászólására (») Máj 13, 2020 / 1
 
Ok! Azt elismerem, hogy a for ciklusos érték adás több időbe kerül, mint a sor folyamatos.

De a tömbösítésnek hasznát vehetnéd máshol is.
Pl. a MIDI 10. sorától kezdődő switch (generatornumber) 6 szoros elágazás helyett lehetne csak egyszerűen:
  1. gorbetime[generatornumber] = 0;
  2.               waveFreq[generatornumber] = noteertek[noteByte];
  3.               waveVeloc[generatornumber]  = velocityByte;
  4.               oldnoteByte[generatornumber] = noteByte;

Csak egységesen kellene kezelni mindent 0-ával kezdeni.
A hozzászólás módosítva: Máj 13, 2020
(#) Rober_4 válasza kapu48 hozzászólására (») Máj 13, 2020 /
 
Ezt holnap megpróbálom! Ott nagyon sok időt veszítek! Köszönöm!
(#) Rober_4 válasza kapu48 hozzászólására (») Máj 13, 2020 /
 
Hát zseniális vagy! Nem hagyott nyugodni megcsináltam! Lassabb biztosan nem lett, mert működik!
És még lehet hány ilyen pont van... Holnap amit lehet átírok tömbbé, és aztán újra átnézem a kódot!!! Megyek valamivel, már eddig is tartoztam!
(annyi, hogy a generatornumber változó is 0-6-ig megy, de ez egyértelmű...)
A hozzászólás módosítva: Máj 13, 2020
Ezekre szükség lehet! - HESTORE.HU

LM358
LMV358CDRG
BC1602 KYPGEH BOLYMIN
MUR1620CTR
ALMD 037 100x100x80
Következő: »»   625 / 854
Bejelentkezés

Belépés
Hirdetés
XDT.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