XC8-al PIC18LF45K50 -ra használtam saját printf-et:

Ez nem teljesen az amire én gondolok, én külön függvényt akarok használni azt ismerem hogy a ptuch a kimenete is mert a vprintf az stdout(putch)-ba ír ki formázott adatot csak nekem nem tetszik, hogy az lcd-re úgy írok ki mondjuk egy változót, hogy printf("szam: %u", valtozo).

Szia! Kézzel? Van erre egy pár program. Én ezt használon:
LCD Image Converter
Bármilyen bittérképet elkészít, képet is, ékezetes karaktereket is, képes beolvasni a PC készleteit majd lehet azon módosítani stb. Egy kis gyakorlással minden megoldható. Nekem túl bonyolult az a tömbrendszer, amit létrehoz, ezért át szoktam gyúrni egyszerűbbé, de elvileg az is használható, amit felajánl, ha meg tudod etetni a fordítóval.

Hasonlót szerettem volna, de nem jött össze nekem sem. Ezért maradtam az egyszerűbbnél.
Ha megoldódik, érdekelne és gondolom másokat is.

Én ezt írtam rá: Bővebben: Link
A karakter generálás nem gond

Most a DS18B20-al kínlódom, az istenért nem akar működni

Erről egy vicc jut eszembe a vadászról a medvéről és a "szívásról". Remélem te is viccesen fogod fel!

Ennél mi lehet jobb?

A legegyszerűbb megoldást sikerült kitalálni amire nem is gondoltam


Igazság szerint ugyanúgy a printf-et akarom használni, csak nem azon a néven(mert nem tetszik ), hogy printf, de ezt a #define vel sikerült megoldani.

Ezt az eléggé el nem ítélhető módszert használja előszeretettel a microchip programozói csapata a példa programjaiban is. Eléggé tudom őket útálni, mikor meg kell érteni, mit hogyan oldottak meg. Ők ezt ráadásul példának szánják...
Csak mellékes, hogy nem szoktam használni gyári függvényeket, kivéve a matekosakat. Még az Open és társait is mellőzöm (még C32-nél is). Eredmény, kevesebb meglepetés, végeredményben, gyorsabb haladás...

Egy újabb kérdésem adódott, hogy megoldódott a printf probléma(végül nem a define lett a _doprnt.c fájlt bemásoltam, módosítottam és beka... a microchip). Az újabb dolog az lenne, hogy egy "class"-t indirekt struktúrát létrehozni az lcd-re író függvényeknek, ez sikerült is, csak az lenne a kérdés hogy a struktúrában lévő függvényeket lehet-e egy alapcímmel indítani, hogy ne kelljen a programba megadni a függvénycímeket
szóval, hogy ne ilyen legyen:
Az lcd-re vonatkozó kód


és a main függvény


szóval a lényeg az lenne, hogy a fő programban már semmilyen módon ne kelljen inicializálni a függvényeket.
Erre van lehetőség?


Wezuv és se szeretem a michrochipes alapkönyvtárakat mikor arról van szó én is megírom őket, de most távolodok a hardvertől és arra törekszem, hogy a C kód legyen szebb és nem érdekel mekkora a program.(kicsit hátrányos az ha az ember egyszerre gépre is és PIC-re is ír programot mert állandóan C#-ot akarok megvalósítani a 8 bites PIC-el)

Nekem azzal van a bajom, hogy egy meglévő függvényt, vagy lejárást átdefiniálnak, aztán azt még belegyúrják még egy pár definícióba és a végén teljesen követhetetlen, hogy mit akarnak.
A másik, hogy nem biztos, hogy az elsődleges megközelítés egy PIC esetében, hogy a forrás legyen szép, mert az nagy valószínűséggel lassú lesz. Persze nem zárja ki a kettő egymást, de ha nagyon sok függvényhívást ágyazol egymásba, az a 8 biteseknél még verem túlcsordulást is okozhat, és-vagy lassúságot.
A kérdésedet nem pontosan értem, lehet, hogy a library készítés körül kéne keresgélned, de a környezetet mindenképpen be kell csatolni (#include) a forrásba, akkor is ha gyári, ha nem...

A C nyelv támogatja a legmerészebb elképzeléseket is, de ez akkor praktikus, ha ismerjük a megoldás hatásait az erőforrásokra.

Igen, elkezdtem nézegetni a az XC32++-t tetszik is meg nem is, nagyjából egy "pillanat lenne" PIC-et váltani, de kicsit félek a 32 bittől, hogy beletörhet a bicskám kicsit régebben 16 bitesekkel foglalkoztam egy kicsit, de bőven meghaladta a teljesítménye a nekem szükségeset.
A stack-re azóta figyelek mióta tudom, hogy van egyszer csináltam egy futófényt és a megszakításból nem tértem vissza és úgy váltottam üzemmódot, azóta nem volt bajom a stack-el.
Meg remélem a C fordító 8 biten egy 31 mély stack-et nem fog túlírni.

Kényelmes csak pár típust programozgatni, amíg az ember ismerkedik a hardver lehetőségeivel és korlátaival.
Ahhoz viszont, hogy a megfelelő eszközt az adott feladathoz ki tudjuk választani, több családdal is meg kell ismerkedni. Asm-ben ez lényegesen több időt, erőfeszítést venne igénybe.
Előfordul, hogy sokat molyolunk valamivel, amiről aztán kiderül, hogy egy másik eszközzel már rég készen lennénk. Szóval a futási idő, memóriahasználat, szépség és egyebek fontosak, de gyakran inkább az a követelmény, hogy stabilan fusson és holnapra legyen meg.

Köszönöm a sok információt, tanácsot a struktúrával egyebekkel kapcsolatban elkészült most egy egyszerű hőmérő majd még lesz tovább is csak ma ennyit csináltam, a végeredmény szerintem nagyon szép:


Egy hátránya van 12000 sor lett és ezt már megírtam assembly-be nem volt 300 sor, itt jön elő, hogy hobbi vagy munka és, hogy mi számít a szépség méret vagy sebesség, jelenleg számomra a szépség volt a cél szempont és nem érdekelt mi kerül a PIC-be.

Uraim, 128bit-es változóra lenne szükségem, de nem tudom mi lenne a legjobb megoldás egy ilyen változó létrehozására.
Struktúra?
De hogyan, milyen felépítésben?

Struktura, esetleg uint16_t vagy uint32_t tömb. Meg persze milyen processzoron? 8/16/32 bit? De attól is függ, hogy mit akarsz vele csinálni, milyen műveleteket akarsz vele végezni. És mi a fontosabb, sebesség vagy kódméret?

Uhh bocsánat.
8bit-es MCU, konkrétan egy 18F46K22 -vel szórakozom, C18-ban
A 128bit, egy szélességben kellene mert biteket akarok tologatni benne, balra.
Egy GLCD kijelző pixeleit szeretném ezzel a módszerrel manipulálni.
32bit sajna kevés, de persze ha nem lehet másként, akkor kénytelen leszek darabonként megoldani.

Hat, azt nem tudom, hogy ez C18-cal hogyan lesz jobb. Egy 16 elemu uint8_t (unsigned char) tombot csinalnek.

Most jelenleg ilyennel próbálkozom:

Hátha jó lesz, nincs jobb ötletem.
4 részre bontom mert ennél jobbat most nem tudok.

Miért kell ebbe struct meg union? Ha egy unionban csak egyetlen elem van, annak nincs semmi értelme. Meg annak se sok, ha egy struktúrában csak egy sima tömb van.

Így oldottam meg, és működik is, majd egyszerűsítem sima struktúrára vagy csak egyszerű változóra, mert ehhez persze nem kell, sem union, sem struktúra, csak a próbálkozások során ez marad meg.

A GLCD-re kikerült adatokat kellett tologatnom, de úgy fest ez a része már jó lesz, majd pici finomítások még lesznek, de már működik úgy ahogyan kigondoltam.

Sziasztok!
Egy rövid kérdésem lenne hozzátok. A változokat a .c file-ban kell deklarálni vagy a .h-ban?
Ha a .h-ban delarálom, akkor "multiple definition of" hibát ad, mivel a main-ben is includolva van az adott header file és a .c file-ban is.

c ben szokás. Külön erre a célra nyitott h-ban esetleg a globálisakat szokták extendizálni , hogy ne kelljen mindenhol, ahol használni akarod.

Szia!
a header fájl-t több helyen is csatolhatod, csak meg kell akadályozni a többszörös dekralációt.
legyen a fájl proba,h
az elején beírod : #ifndef __proba__ (itt egyébként itt mindegy milyen szöveg van)
#define __proba__
innentől a dekralációk
......
.........
a végén : #endif
Igy akárhova berakhatod a header fájlt. A változókat pedig használhatod más fájlokban, csak extern szót kell elétenni.

Uraim, egy hasonló rutint kellene írnom mint a printf(), de sajnos nem jövök rá miért nem azt csinálja amit akarok.
Létre hoztam egy globális változót, ebben lesz majd a végleges adat ami ki kell íratnom LCD-re.

Ez maga a rutin:

A típusát ezer fele képen lepróbáltam, most az utolsó módosítást látható.
A meghívás:

A lényege az lenne, hogy a text_to_array tartama átkerüljön a TextBuffer tömbbe.
Erre azért van szükségem mert az ST7920-as LCD-re csak nagyon körülményesen tudok írni és nem tudom keverni a típusokat.
Ezért az int típusú adatokat átkonvertálom char típusúra majd azokat beteszem a tömb megfelelő helyére és így küldöm majd ki a kijelzőre.
Elsőre, sőt másodikra is körülményesen hangzik, de ez van most.
Előre is köszi.

Közben megtaláltam a hibát:

Ez van amikor az ember a bagatell dolgokra nem figyel és már zavar van a fejben

Persze '\0', de ez biztos csak elgépelés.
A fenti függvény kicsit egyszerübben: (egy példa a for és a pointerek használatára)


Hogy érted azt, hogy nem tudod keverni a tipusokat? A fenti függvény char-t másol char tömbbe.

Nos közben a sprintf() volt a segítségemre mert nem jutottam egyről a kettőre, de ez meg zabálja a memóriát.

A lényeg még egyszer:
Azt szeretném elérni, hogy mint amit a printf("ABCD") rutin is csinál.
Nem az átalakításokra gondolok, hanem arra, hogy a macskakörmös részeket kiemeli egy tömbbe.
Az én esetembe a text_to_array("ABCD") rutin lenne erre a feladatra.

A baj pedig itt kezdődik.
A text_to_array() rutinnak nem mindegy milyen típusú a bemenete.
Ha sima unsigned char vagy bármi, akkor nem másol semmit a TextBuffer tömbbe.
De ha rom unsigned char, akkor bemásolja.
Igen ám, de ezzel meg az a baj, hogy a 3. meghívásnál már nem csinál semmit.
Megtelik a stack memória vagy nem tudom, de egyszerűen nem másolja át az adatokat..
Ezzel kínlódtam tegnap szinte egész nap, de nem jöttem rá miért van ez, majd az sprintf()-re rátaláltam, és az működik, de eszméletlen módon zabálja a memóriát nem beszélve arról, hogy baromi lassú.

A tömbök tartalmát cserélgetnem kell, mert vannak int típusú változók amiket átalakítás után be kell helyezzek a tömb megfelelő helyéra a kiíratás előtt.
ST7920-as GLCD-vel kínlódom és valami borzalom minden egyes keservesen történő előre lépés.

Szia!
talán az stdio.h-ban van sztringmásoló függvény strcpy(... ....)
rég használtam már.
Sajnos az "abcdef" szöveg futásidőben movlw movwf utasításokkal először feltölt egy buffert, majd azt másolja a másikba. Ez lehet a lassúság oka. A ROM-ból olvasás is lassú relatíve...

Aztán ott van a típuskényszerítés más típusú pointerek elfogadására ez -> ( )
üdv.: Foxi