A jelenlegi impulzus szélesség mérésed nagyon lassú, sok a várakozás a PIC semmi mást nem tud közben csinálni(pl. számolni, beavatkozni stb.), ezt jobb lenne megszakításban (PORTB INTCON CHANGE) lekezelni a Timer0 segítségével (20MHz esetén 32-es előosztással). Az RB4-7-ig minden változásra megszakítást okozhat, ha engedélyezed. Szinkronizálni szükséges ezért, de könnyű megkülönböztetni a 2 és a 18ms-et. De még jobb lenne olyan PIC, amiben van 4 CCP modul és akkor nem kell szenvedni...

Azt írod, megrendelés. Nos, akkor olyan vezérlőt illik készíteni, ami figyeli az akku merültét is és még jó pár lehetőség is emelné az értékét, pl. gyermek sebességi üzemmód stb. Ekkor jön elő majd, hogy semmire sincs idő az ilyen várakozások miatt...

A mérés sebessége még így is gyors, az átlagos rádiók 50Hz-es frissítéssel dolgoznak, a nagyon profik is csak 200Hz-el tudomásom szerint, meg ez eleve nem olyan jármű, ahol azon múlana a dolog, hogy a szabályzó mondjuk késik 10ms-et. A megrendelést illetően nem tudom, hogy lessz-e, csak azt tudom, hogy sok embertől hallom, hogy tankos szabályzóban nem nagyon van választék a piacon, és ami van, az is drága. Az akkufesz figyelés igazából 2db ellenállás, az nem nagy cucc, a gyermek sebességi módot kevés szabályzó tud, a bevett gyakorlat az, hogyha gyerkőc kezébe kerül a gépezet, akkor a távirányítón visszaveszünk a 2-es csatorna (gáz) endpointját olyan 30-40% körülire.

Ez az union működik 24 bites változóval is?
Pl:
typedef union unio24{
unsinged short long full;
struct{
unsinged char low;
unsinged char high;
unsinged char upper;
};
}unio24;

unio24 amplitude;
amplitude.full=tomb1[A]*tomb2[B]; //256-tal való osztás miatt nem kell az alsó 8 bit
PWM1L=amplitude.high;
PWM1H=amplitude.upper;

Ez így működőképes?
A másik kérdésem, hogy mindig struktúrába kell foglalni a 8 bites változókat? A harmadik pedig, hogy ez a typdef-es részt hol kell elhelyezni a programban? A változók deklarálásánál?

1 - Működik.
2 - Nem.
3 - A program elején, mielőtt hivatkoznál rá vagy egy .h állományban, amit #include sorban megadsz mielőtt hivatkoznál a típusra.

Oké, kösz.

A projekt bonyolultságától függően teheted külön fejléc (*.h) állományba, vagy a progam elejére. A lényeg, hogy a fordító ilyen sorrendben kapja:

1. Típusdefiníció
2. Változó deklarálás
3. Változóra hivatkozás

Kipróbáltam és van vele némi problémám.
typedef union unio24{
unsigned short long full;
struct{
unsigned char low;
unsigned char high;
unsigned char upper;
};
}unio24;

unio24 amp;

Ha nem teszem struktúrába az 1 bájtos változókat nem működik jól, ha így használom akkor kb ok amíg nem szorzom meg egy számmal:
amp.full=Sine_duty[counterA]*256;
PDC1L=amp.high;
PDC1H=amp.upper;
Ez pl így már nem jó, de ha nincs benne szorzás és simán a low és high-ra hivatkozok működik, olyan mintha nem látná az upper-t.
Így szintén nem működik:
amp.full=Sine_duty[counterA]<<8;
PDC1L=amp.high;
PDC1H=amp.upper;
Ha viszont egy számot írok az amp.full-ba és shiftelem 8-al balra akkor jó az high és upperrel is.
amp.full=2048;
amp.full=amp.full<<8;
PDC1L=amp.high;
PDC1H=amp.upper;
Így ugyan az mint a shift nélkül low-val és high-al. Szóval a szorzás körül van valami baja.

Közben félig rájöttem a hibára.
A szorzást külön sorba kell írni úgy megy sima számokkal is a high- és upper-rel, viszont nem megy ha nem számmal hanem egy táblázat értékével szorzom meg:
amp.full=Sine_duty[counterA];
amp.full=amp.full*Amplitude[POT];
Ha az Amplitude[POT] helyett egy szám van működik.
Ha ezt csinálom akkor sem jó:
AMPLI=Amplitude[POT];
amp.full=Sine_duty[counterA];
amp.full=amp.full*AMPLI;

Szerk:
Ha az AMPLI=255; akkor sem jó olyan mintha csak szimplán számmal lehetne csak megszorozni.

Mindegy egyébként ha a megszakítás alatt szorozgatok az túl sok időbe kerül nem lesz pontos a szinusz. Ha átteszem a megszakításon kívülre akkor valamivel jobb és akkor maradhat a shiftelgetés is.

Nézd meg a disassambly ablakban, mit fordított a kérdéses sorokhoz.

Szia!
A táblázat a gyors megoldás
Amit készítettem frekvenciaváltót, ott egyszerű táblázatban letároltam a színusz értékeket, és egy HW szorzással(frekvencia/feszültség arány) betettem a pwm regiszterbe 400Hz 3fázis sem volt probléma megszakításban.
üdv Foxi

Én is táblázattal dolgozok van egy ami a szinusz értékeit tárolja és van egy amiben a feszültség-amplitúdó van. A kettőt szorozgatom össze, de ha a megszakításban teszem a szinusz jel periódusideje kb 5%-kal nő.
Milyen kapcsolási frekvenciát használtál?

Egyébként megszakításnál miket kell menteni?
C18-ban automatikusan menti PC, WREG, STATUS, BRS, FSR0, FSR1, FSR2. Ezeken kívül mit érdemes még?

Menteni mindig azt kell, ami a megszakításkor, vagy a megszakítás kiszolgálása során megváltozik, s ezzel megakadályozza, hogy a megszakított program zavartalanul folytatódhasson. A mentés önmagában nem elég, természetesen visszaállítás is kell.

Jó, de mik ezek vagy miket alap dolog menteni? Gondolom ha a C18 automatikusan menti az adott regiszter értékét akkor vissza is állítja a megszakítás végén.

A C fordító hivatalból sok mindent megcsinál (PIC24, PIC32, ARM Cortex M4F esetén néha pont arra kell rábeszélni, hogy ne vigye túlzásba a mentéseket, ne pazarolja az erőforrásokat).

PIC18 esetén a hardveres szorzó (eredmény) regisztereit vagy a 16-bites Timer kiolvasáshoz és beíráshoz használt kisegítő regiszterét pl. nem tudom, hogy menti-e a fordító automatikusan.

Én sem tudom.

Miért nem olvastok utána a User's Guide -ban?

Már rég volt, de azt hiszem 10kHz.volt. A PWM nem érzékeny a felbontásra, mindig a HW es szozat 0-255 között volt, ezután még HW -es szorzás volt 8-al ezért volt gyors. A pwm periódus ideje pedig nem nőhet, hiszen a megszakítás mindig pontos időközönként jön, a számolási idő nem számít, mert nem éri el a következő megszakítást. Ebből következik ,hogy valami más probléma lehet.(Felesleges nagyon pontos színusz felépíteni motornál az enyém feleslegesen 120 elemű .)

Attól függ, hogy a fordító HW szorzásnak fordítja e, de ha nagyon sok számítást végzek akkor "szélesebb" a szinusz. Jelenleg 19,5kHz-en megy a PWM (nyilván feleslegesen magas később biztos lejjebb megyek vele), szóval kb 51usec van a következő megszakításig, de valamiért jelenleg is van benne kb 2,5-3% hiba (ami még nem is lenne vészes) csak nem tudom az okát.
Esetleg valamely regiszter értéke mentésének elmulasztására gyanakszok, bár maga a megszakítást ugyan nem befolyásolja, de lehet a fordító valamit kavar. A disassembly-n már nem tudok elmenni 1000 sor felett van. Na meg a megszakítások között is kellene pár dolgot csinálni pl a potit beolvasni, nyomógombok stb.
Az én szinuszom 360 elemű alapból, de úgy csináltam meg hogy bizonyos érték felett mindig csökken felosztottam kb 6 részre 1-64Hz-ig és magasabb frekin átugor pár értéket, viszont alacsony frekin belefér a 360 simán. (Szóval ez a sok funkcióhoz kezd kevés lenni a 40MHz, de normál DIL tokozással 100MHz-est hasonló paraméterekkel nem nagyon találtam.)

Sziasztok!
Találtam a neten egy 16*16 képpontos karaktertáblát:
Bővebben: Link
A probléma az, hogy char tömbben van és nekem int-ben kellene. Nem ismertek esetleg valami programot ami összefűzné kettesével a bájtokat?

Irjal ra egy 10 soros programot, ami osszefuzi. mingw, gcc, stb. Nem csak a mikrokontrollert lehet programozni, hanem a PC-t is.

Szia!

Összedobtam neked gyorsan egyet!

Biztosan sokan használnák, főleg akkor, ha lenne benne egy felső byte / alsó byte csere lehetőség is.

Arra gondoltál, hogy konvertálás közben cserélje fel a két bájtot?
0x0A,0x0B --> 0x0B0A?

Igen:
0x0A,0x0B lehet 0x0A0B illetve 0x0B0A is.

Szuper! Köszönöm!

Refernce Manual.
Mikroe font generator ugyan az mint a microchipes csak kapott egy "szókenő barát" GUI-t.
Az MLA-ban van egy font generator nekem nem akar elindulni leírás: MLA font
Valamint a Graphic Resource Converter ez nem tudom, hol van a microchip-nél én az MMB32 Examples-ből szedtem ki.

Ezekkel tudsz bármilyen fontot generálni gondolom Taki33 CharToInt.zip-jében a progi van amivel konvertálni tudsz, bármelyikre ráküldesz egy konverziót és van olyan font-od amilyet akarsz. Csak az elején lévő font header-t szerintem nem kell konvertálni, de lehet nem okoz problémát az se.
Én régen míg nálam volt az MMB -s próbapanel olyan kacifántos fontkészletet használtam amilyet csak találtam .


Szerk.:
Azt persze elfelejtettem írni, hogy ez csak egy segítség, hogyha esetleg szükség van rá.

Egy észrevétel: Az elválasztó karakter meglétét a sorok végi komment részben is értelmezi, így a "vessző" karaktert leíró sortól szétesik a többi. Amúgy szuper!

Attila86: Igen az elválasztó karakter szerint darabolja fel a szöveget, elvileg javítottam!

Hp41c: Kívánságodra belekerült a bájt csere lehetőség is!

Használjátok egészséggel!