Szia!

Nem tudom milyen nyelven írtál, a felét (felét?) nem értem. A PIC18f26K22 és ASM-ben próbálkozom.

Ez lenne a kiinduló alap.

Hogy került oda az adat, és hova utazik tovább? Nem lehet ezt az átalakítást megúszni valahogy?
Elég komplex aritmetikákat kell csinálni (ahogy leírtam fenn), bevallom én nem esnék ennek neki ASM-ben. Csak ha muszáj lenne

A GPS modulból így jön le én tárolom át ide. Google linkbe szeretném beszúrni, de ott dd.mmmmm formátum kell. Néztem, sajnos a modul csak ezt a formátumot tudja adni.
Elég fontos lenne, a munkám függ tőle, úgy hogy valami megoldást kell találni.
Próbáltam visszaszámlálós megoldást, de ez, főleg ha magas al első szám, pár percbe telik. És még a visszatöltés nincs benne.

A Google link utána hogy megy át egy számítógépre? Azért kérdezem, mert talán meg lehetne úgy fogni, hogy ott amikor átmegy a gépre, akkor ott legyen átalakítva. Valahogy ez a PIC kommunikál valami PC-szerű programmal, mi van a másik oldalán?

Azt írtam fent le, hogy hogy valósítanám meg, ha 32 bites fixpontos aritmetikám lenne. Látszik, hogy elég sok lépés, még PC-n C-ben, vagy Java-ban is komplex lenne ez az átalakítás. Persze nyilván meg lehet csinálni, hiszen amit C-ben meg lehet írni, azt ASM-ben is meg lehet, csak adott esetben rendkívül komplex. Az kérdéseid alapján nem állsz úgy programozásban és ASM-ben, hogy meg tudd ezt csinálni. Én 30 év programozás tapasztalattal azt mondom, hogy nem szívesen állnék ennek neki. Nem lehetséges átállni C nyelvre a projekttel? Úgy sokkal egyszerűbb volna. És ami a legfőbb előnye: az algoritmusaidat ügyesen fájlokra szétválasztva a konverziót lefordíthatnád PC-re is, és ott tudnád tesztelni, hogy jól működik-e?

Nem megy át pc-re, SMS-ben kerül elküldésre. C-re átrakni még nagyobb munka lenne, Több ezer sor van már, ez a GPS rész csak apróság. Az a baj hogy a főnök lecserélte a modult. Az előző rendes GPS adatokat adott ki.

Kezdem kapisgálni, hogy mi ez. Valóban nem lehet áttolni sehogy a konverziót a PC oldalra .

Szerintem mindenképpen kelleni fog a sokjegyű összeadás, kivonás és szorzás művelet is, anélkül nem tudod megcsinálni. Az osztást meg lehet úszni, ha úgy csinálod, ahogy fent írtam. Ezzel kezdeném, hogy bányásznék, vagy írnék sokbites aritmetikai libet.

Még egy egyszerűsítés eszembe jutott: ha bájtonként egy 10-es számrendszerbeli számjegyre írod meg a számolós libedet (akár ASCII kódolásban, akár levonva DEC 48-at), akkor könnyebb debuggolni, és a decimális->bináris átalakításokat is meg tudod spórolni. Ez kicsit pazarlóan bánik a CPU-val, meg a RAM-mal, de a sebességgel nem lesz gondod úgy sem. A szorzás azért nem egyszerű még így sem...

Én még mindig meggondolnám a C használatát. Meg lehet kis lépésekben csinálni az átállást úgy, hogy hibrid programot csinálsz: van egy C main függvény, ami csak meghívja az ASM belépési pontot, majd amikor számolni kell, akkor visszahívsz C-be. Így a program nagyrésze marad ASM, de tudsz C-ben számolni.

Úgy látom kevés leszek hozzá. Nem vagyok ezen a szinten. Főnök biztosan nem járulna hozzá hogy C-ben áttegyük. Elvégre övé a program, én csak próbálom foltozgatni, kis átalakítások, stb. Inkább keres valakit helyettem...

Azért nem lehetetlen ASM-ben sem megcsinálni, ha minden kötél szakad. Ne add fel, csak azért akartalak eltántorítani az ASM-től, mert ez a komplexitás már nagyságrendileg egyszerűbb C-ben.

Biztosan nem lehetetlen, de tudásilag még nem tartok ott hogy egyáltalán értsem miről van szó.
Matematika meg nem az erősségem, számoktól megfájdul a fejem.

Te esetleg nem tudsz segíteni benne? Nem kérném ingyen. Már 3 napja, napi 14 órákat csak ezzel kínlódok, olvasgatok, kutatom a netet hátha van rutin, komolyan már a szememen érzem...

Az én órabéremet tuti nem köhögné ki a főnököd . Az, hogy okoskodok, az ingyen van, de megcsinálni nem fogok semmit. Ráadásul valójában inkább AVR-es vagyok, sosem PIC-eztem, csak azért mertem belevau, mert ez valójában általános programozós kérdés, nem PIC-es. Szóval nekem is azzal kezdődne, hogy meg kellene tanulnom a PIC ASM-et.

Tippet tudok adni: küldtél ilyen RAM dump képet, hogy ott csücsülnek a számok ASCII decimális kódolásban. Ebből kiindulva meg kell csinálni a műveleteket. Összeadás: a fenti két sorban van két szám, az alatta lévőbe kell beírni az összegüket. Ahogy isiben kellett írásban összeadni, ugyanúgy kell csinálni.

Utána a szorzás: szintén isis módon. Ez már komplexebb, mert egy nXk táblázatot kell kitölteni számokkal, és utána még a sorokat össze is kell adni. Vigyázva az átvitelekre, és arra hogy azok se csorduljanak sosem túl!

Ez két szubrutin lesz, aminek paramétere, hogy honnantól hány számjegyen van a két bemeneti szám, és hova kérjük a végeredményt. Ha ez megvan, akkor lehet továbbmenni.

Ha C-ben dolgozol, akkor ezeket kapod a fordítótól, illetve a gyári library-kből. ASM-ben meg össze kell vadászni, vagy meg kell írni ezeket.

Ha ezek megvannak, akkor lépésenként el lehet végezni a számolást.

De nekem nem összeadnom kell. A felső sorbol: 16578941 számot kell 60-al osztani. Utána a végeredményt a 47 után beilleszteni.
Az alsó sorral ugyan ezt.

Sokféle osztó rutin van itt: PIC Microcontoller Basic Math Division Methods
pl: ez.

Igen ezeket megtaláltam, de nem tudom hogy kell alkalmazni. Probáltam. RLF parancsot hibának hozta a fordító.

A C18 nevű régebbi C fordítóban ott vannak asm forrásban a matematikai rutinok (src/extended/math). Az osztó rutinok pl. div08s.asm, div08u.asm, div16s.asm ... div32s.asm stb. De van lebegőpontos és fixpontos aritmetika is.

És ezekkel hogy tudok ilyen nagy számot egyben osztani?

Abban a formátumban ahogy van szerintem sehogy, csak ha átalakítod. De a jelenlegi BCD-re hasonlító számokra magad is megírhatod a számoló rutinokat. Mindössze azt kell gépre vinni, mint ahogy papíron számolnál.

Milyen GPS modulról van szó? NMEA protokollt használ? Át szabad állítani valamilyen más üzemmódra?

SIM7600 nincs más üzemmód.

Az ott közölt rutinok többsége valamilyen 16-os PIC-re íródott. A 16-os széria RLF parancsa a 18-as szériánál RLCF.

Ezen kívül arra is figyelni kell, hogy a PIC18 néhány utasítása másképp állítja a jelzőbiteket.

Lehet, hogy elsőre félreértettem az NMEA és a KML formátumot, és kicsit bonyolultabb valamit írtam le, mint ami valójában kell. Meg kicsit zavarosan is írtam, megpróbálom újra összeszedettebben.

De azt tartom, hogy amikor fix értékkel osztünk, akkor osztás helyett a reciprokkal való szorzással lehet helyettesíteni. Ez azért jó, mert a szorzás egyszerűbb algoritmus, és a végrehajtása gyorsabb is.

A reciprokot pedig egyszer kiszámolod előre a PC-den, vagy papíron az 1/60 értéket, és ezt mint konstanst beírod a programkódba, és ezzel szorzod be amit kell osztás helyett.

A fixpontos ábrázolás pedig úgy működik, hogy egész számokkal számolsz, de te - a programozó - tudod, hogy hányadik számjegyhez kell odaképzelni a pontot. Tehát:

* Az mm.mmmmm formátumból kitörlöd a pontot, marad ez: mmmmmmm (és tudod, hogy 2 egészed és 5 tizedesjegyed van)
* Az 1/60-at is fixpontosan ábrázolod akárhány tizedesre: 0.1666666666666... -> 1666666667
* Összeszorzod a kettőt sima egész szorzással, az eredmény valami ilyen lesz: cccccccccccccc
* Tudod, hogy hány egész jegyed és hány tizedesjegyed van az eredményben (ebben a konkrét esetben 0 egészed lesz, az összes jegyed eleve tizedesjegy az eredményben), az egész jegyeket levágod az elejéről. Ezzel megkaptad amit a KML formátumban a tizedespont utánra kell írni.

Amit még hozzá lehet tenni:

* a fixpontos ábrázolásból adódó hibát lehet - kell - becsülni. Annyi számjegyet kell használni, hogy ez kellően kicsi legyen
* a számolás végén ha levágsz a tizedesjegyek végéből, akkor hozzá lehet adni az utolsó maradó tizedesjegy felét, és akkor a levágás helyett kerekítés lesz a művelet.
* Számolhatnál binárisan is, akkor a számjegyek bináris jegyek, bináris fixpontosban kell gondolkodni. Általában ezt szoktuk csinálni, mivel általában az alap bináris aritmetika rendelkezésre áll - ugye a fordító és az alaplibek adják. De ebben az esetben egyszerűbb lehet inkább tizedesjegyeknél maradni a számolással, mert akkor a tizedes->bináris->tizedes átalakításokat megspórolod. Ezek pedig önmagukban vannak annyira bonyolultak, mint az egész feladat. Amit veszítesz a tizedes ábrázolással, hogy decimális szorzás libet kell bányásznod vagy írnod, és erre sejtésem szerint kevesebb példa lesz készen a neten. Viszont könnyebb nyomonkövetni a debugger RAMdump ablakában a folyamatot

Köszönöm, megoldottam. Sokat segítettél. Végül szoroztam 6-al, és a helyi értékek eltolásával hozzáadtam az eredeti számhoz.

Üdv
MPLAB bal kapcsolatba lenne kérdésem.
Teljesen kezdő vagyok így elnézést ha nemjól kérdezek.
Van egy programom ami egy asm és 4 inc fájlbol áll ebböl kellene előállítani a hex fájlt amit beégetek a PIC be.Ezt hogyan kell csinálni?

A régi mplab vagy az x-es?
A régiben tudok segíteni:
Project wizard, pic tipusát megadod, a file-ok helyét megadod. Linker, assembler helyét megadod.
Utána a source file-hoz megy majd az asm (odahúzod vagy add)
Az other files-ben az inc-eket tedd.
Ha ez megvan, már le kell tudnia fordulni a build opcióval, fent van egy ikonban.
Az output képernyőt teleköpi üzenetekkel, ha a vége fekete build successful, akkor jó.
Ha piros failes, akkor nem csinált hex-et, valami baja van, általában ki is írja a gondot.
Ha a hex megvan, akkor a programmer-ben kiválasztod a pickit2 vagy 3-at, amid van.
Ha a programozó inicializált és kiirta a reviziót, akkor jó. Utána a fenti kis ikonok közül az első a write program. Kész is.
Sajnos a legtöbbször azt írja ki,hogy nem kapcsolódott a PIC-hez, nem talált mikrovezérlőt.
Ilyenkor megpróbálkozhatsz a saját tápjával adni neki a feszültséget (beállítható a fesz a programmer menüjében, alapból ki van kapcsolva). Értelemszerűen az áramköröd belső tápját ilyenkor nem szabad működtetni.
Ha máshogy értelmezem a kérdésedet, akkor csak a hex-et akarod létrehozni. Ez megy egy dos-os mpasm progival is. Az asm progiban legyenek benne az inc file-ok include-olva a megfelelő helyen.
Ha csak egyszer kell, küldd el nekem és lefordítom...

A 8.1 van nekem azzal próbálkoztam és végül sikerült.
Köszönöm szépen a segítségedet.