Hali

A kiolvasassal meg nem torlod a RBIF-et. Az az SW dolga. Azert kell kiolvasni, mert a portban van egy D flip-flop, ami valtozaskor bebillen es a port kiolvasakor nullazodik. Amennyiben az IT alatt nem olvasod a portot a RETFIE utan ujra IT lesz, hiaba torolted a RBIF-et.
Udv Vili

Az alábbit
"set_tris_b (00110000);"
javítsd a következőre
"set_tris_b (48);"

Hali
Ez miert jo? Nem lathato a byte allapota. Mint elobb leirtam a helyes utasitas "set_tris_b (0b00110000);" (#680180 hsz). Ha binaris szamot irsz akkor siman olvashato a bitek allapota. Decimalis szamokban eleg nehez ertelmezni a bitek allapotat (lehet Te ropteben szamolod at). Persze mashol alkalmas a decimalis vagy a hex abrazolas is. Mindig fugg a kivant helyzettol.
Udv Vili

Bocsi, nem frissítettem
A te ajánlásodat kell használni!

A 0b00000000 jeloles nem kompatibilis a C standard-dal, ezert javasolt inkabb hexaban vagy oktalisan megadni a szamokat. Hexat pedig igazan konnyu atszamolni fejben...

Hali
Lehet hogy nem szabvanyos, de a CCS C igy is elfogadja (vannak benne erdekes dolgok es nem teljesen ANSIC). Viszont sokkal attekinthetobb egyes esetekben..
Udv Vili

Az nyilvan valo, a C nyelvet amugy sem mikrokontrolleres kornyezetre terveztek, emiatt sok poblema van veluk es tulajdonkepp egyik C fordito sem teljesen ANSI. Pl nincsenek felkeszitve a kulonbozo memoria tipusokra, a memoria lapokra, bit manipulalasokra -- ahogy az egyes forditok megvalositjak tulajdonkepp eroltetesek es nem veletlen egyik PIC C compiler sem kompatibilis a masikkal.

Na mindegy, vegulis csak annyit javasoltam, hogy nem kellene minden egyes kiterjesztest es nyelvi valtoztatast kihasznalni amit csak kinalnak, hiszen igy inkompatibilisek leszunk a tobbi forditoval, azaz eletunk vegeig hozza leszunk lancolva egyetlen forditohoz

Azon gondolkodom, hogy lehetne-e erre a 0bxxxxxxxx formára valami makrót húzni, amivel minden C nyelvvel el lehetne fogadtatni ezt a formát? Van valami ötleted rá?

Szerintem nem lehet, mert 0-val (szammal) nem kezdodhet makro nev. De pl. B01010101 lehetne, es akkor azt lehetne mindenhol alkalmazni. Vagy B(010101) is akar, ahogy jobban tetszik

A b elég, mert ha a nulla ott marad a szám előtt, az épp jó a hexadecimális ábrázoláshoz. Pl. b01010101 le lesz cserélve x55-re, akkor az a fordítónak 0x55 lesz. Namost nemtudom, a 0x55 formát mennyire szeretik a fordítók, de eddig még talán mindegyik elfogadta, amivel dolgom volt.

Ha még valakinek nem lenne meg a CCS 4.106 upgrade, akkor innen letöltheti:

Bővebben: CCS 4.106

Köszi, Király vagy!

Csatlakozom az elöttem szólóhoz!

Sziasztok!
Elképzelhető, hogy nagyon triviális a kérdésem, de én megakadtam a problémában. Arról van szó, hogy lebegőpontos (float) számot kell 4 db 8 bites byte-ban tárolnom, mert szinkron kommunikációban így tudom átvinni, a másik oldalon persze vissza kell alakítanom float számmá. CCS C-ben a következőképpen oldom meg, szépen működik:

Float -> 4 x int8:


int8 out_data[4];
int8 in_data[4];
float temperature;

for (j=0; j<4; j++) {
out_data[j] = *((int8*)&temperature+j);
}


4 x int8 -> float:


for (j=0; j<4; j++) {
*((int8*)&temperature+j)=in_data[j];
}


Lenne-e ötletetek arra, hogy hogyan lehet ugyanezt a metódust leírni más megoldással, amelyben nincsen indirekt címzés és pointer? Az a helyzet ugyanis, hogy a kommunikáció másik - PC - oldalán NET3.5 vc#2008-ban kell megírnom a metódusokat és abban nem javasolt a pointer használat, egyébként mindenféle bit szintű művelet támogatott. Nyilván nagyon fontos, hogy a metódus eredménye ugyanez legyen. A C#-ban van BitConverter osztály, meg is lehet ezeket az átalakításokat csinálni, de másképpen számol, nem ugyanazokat a byte-okat adja, mint a fenti metódus. Ez nekem gond, mert az egyik feladat az, hogy a PIC oldalon floatból átalakított, betárolt és átküldött byte-okat a PC oldalon vissza kell alakítanom és meg kell jelenítenem float számként, és persze vica-versa.
Lenne valakinek jó ötlete?

Nem tudom Neked mennyire jó ötlet, én így oldottam meg:
A változód nevéből ítélve hőmérőről van szó, aminek a méréstartománya adott (jellemzően +125...-55), a pontossága - analóg érzékelők esetén a pontosság igénye - szintén jól behatárolható, jellemzően nem több 2 tizedesnél, azaz ,0..,99.
Ha mindez igaz, ez az érték elküldhető két byte-on, (egész és tizedes), úgy, hogy az egész rész legfelső bitje lehet az előjel bit.
Nálam valami hasonló működik a PC-s kommunikációhoz és az epromba íráshoz is (kicsit megvariálva, mert az epromba mást is teszek, a hőmérséklet értéket 11 biten tárolom 1 tizedes pontossággal)

Végül is a megoldásod jó, nyilván bizonyos határok között. Nekem (a hőmérséklet csak egy példa volt) azonban olyan adatokat is konvertálnom kell, mint pl.: -0.000385, vagy éppen 123.0234 pluszban és minuszban. Ezért nekem mindenképpen a valós lebegőpontos számok tárolását és konverzióját kellett megoldanom. Nos hát kutattam kissé és számoltam, teszteltem sokat, ezért nem is válaszoltam eddig. Megvan a megoldás, az alábbiakban közzéteszem, hátha még jól jön valakinek :


Én a teljes konverziót a PC oldalon oldottam meg, mert így nem veszem el az időt a PIC oldalon a vezérléstől. NET3.5 VC#2008-ban írtam, remélem érthető mindenkinek. A kiírásra kiválasztottam egy éppen üres listboxot, tehát az bármi lehet. A beérkező byte-okat beírtam a programba és utána oda-vissza elvégeztem a konverziót, amint látszik alább. Sok pozitív és negatív számmal kipróbáltam, nálam jól működött, remélem, nincs benne hiba, íme:



Ha kérdés van, ne habozzatok

Miert nem hasznalsz union-t?

Őszinte leszek, eszembe sem jutott. Talán, mert a probléma megoldásra koncentráltam, nem a programozás szépségére és a tömörségre. Viszont, ha már ilyen ötleted van, közzé is tehetnéd mindannyiunk épülésére.

Bocs, azt hiszem félreértettél. Azzal, hogy eszembe sem jutott, nem azt akartam mondani, hogy nem tudom, mi az az union. Azzal pedig, hogy ha ötleted van, tedd már közzé, nem egy akármilyen union-t használó példára gondoltam, hanem a konkrét feladatra union-nal megírva. Végül is így tanulnak a kollégák (tehát mi mindannyian), a konkrét feladatok kifejtéséből, nem így gondolod?

Ez amit az elobb irtam elkuldi a float-od mind a negy byte-jat a PC fele, ennel konkreatabb nem tudom mi kell

A PC-n meg en mar nem is tudom mit hasznalsz? Mert VB-t nem ismerem, C#-t is csak feluletesen, de abban valahogy igy kell a uniont megvalositani:

Azért ehhez a megoldáshoz kell az is, hogy mindkét oldalon ugyanúgy ábrázolják a float-ot. Mivel ezt nem biztos, hogy feltételezhetjük (pl. lehet, hogy most jó, de a következő verziójú c már máshogy fogja), én inkább valami más megoldásra gondolnék. Ilyen megoldás lehet pl. a float mantisszájának és exponensének explicit formában történő átküldése, és a vételi oldalon újra float-tá összerakása. Ez mehet pl. BCD-ben is, akkor 4 byte-ba 6 digit mantissza +2 digit exponens fér bele.

Ha megfigyeled az oldal tetején levő táblázatot, ill. az alatta levő programocskát, én pontosan ezt tettem, igaz, nem BCD-ben. Megnéztem, hogy a ccs c hogyan ábrázolja a float számokat, majd megkerestem, hogy a C# hogyan is teszi azt. A PC oldalon ez egy MS WIN szabvány, (amelyet átvett a DOT NET is) tehát nagy valószínűséggel minden olyan nyelv így használja, amelyet az MS fejleszt, ill. forgalmaz.(VB, C++, VC#, Java, stb.) Nyilván, ha más nyelvet használsz, akár PIC, akár PC oldalon, akkor ezt le kell ellenőrizni, de ez alól vszinűleg akkor sem mentesülsz, ha más pontos módszert használsz, ugyanis a nyelvek még a nagyobb "felbontású" integer, long, UInt, stb. számokat is másképpen ábrázolják a megfigyelésem szerint. Amúgy csupán az érdekesség kedvéért: a DOT NET által használt tárolási mód programozása pl. C#-ban (tehát itt pl. a BitConverter.GetBytes és a BitConverter.ToSingle függvényre gondolok a BitConverter osztályban) ugyanazt a ciklus alapú memória pointeres módszert használja, mit amelyet PIC-ben (a példámban is) használunk. Csak éppen a háttérben maga a C# másképpen ábrázolja a számot.

Igen, csak ettől még mindig nem lesz eszköz/fordítófüggetlen. Persze vannak pl. IEEE szabványok is a float ábrázolására, de ettől ki így, ki úgy tér el...

Én arra gondoltam, hogy matematikai vagy stringműveletekkel adásoldalon előállítható a mantissza és az exponens is, pl. úgy, hogy mindkettő egész. Ezeket lehet közlekedtetni az átviteli csatornán, majd a vételi oldalon szintén matematikai és/vagy stringműveletekkel összerakható az eredeti szám. A lényeg, hogy sehol nem használnám ki azt, hogy az adás- vagy a vételodalon dolgozó program belsőleg hogyan ábrázolja a float-ot.

Ize... Java-t a Sun Microsystems fejleszti, C++ pedig, hat jo, Microsoftnak is van C++ forditoja, fogalmazzunk igy

Amugy ezek a dolgok nem a Microsofttol mulnak, hanem az adott platformtol. Az Intel LSB-s, mig a PowerPC MSB-s (es sok mas processzor is). Az LSB szerencsesebb abrazolas sok szempontbol, de most nem ez a lenyeg.

Amugy ez nem C# programozoi oldal, de ha mar itt tartunk, C#-ban eleg keveset kell ilyen gep kozeli dolgokat leprogramoznunk. Amit mar nem oldottak meg azt vagy nem lehet vagy nem erdemes. Pl. az endian koverziora itt vannak a:

System.Net.IPAddress.HostToNetworkOrder()
System.Net.IPAddress.NetworkToHostOrder()
BitConverter.IsLittleEndian

Ezeket kellene atnezned, ill. vagy a PIC kuldesnel vagy a .NET fogadasnal a peldaban amiket leirtam csak megforditod a sorrendet es kesz is vagy...

SD kártyára szerettem volna adatokat menteni.
Az EX_FAT mintaprogit kicsit móositottam , mert nekem 18f46J50 volt itthon amibe bele is fért a program, valamint a SD kártya csatlakozást írtam át D4-D7 lábakra.
A prgram fut, sorosporton kommunikál de
ERROR INITIALIZING FAT hibát ír ki és semmilyen parancsot nem hajt végre.
Vagyis ha MMC kártyát teszek be akkor nem írja ki ezt a hibát, de akkor sem hajtja végre a parancsokat.
Próbáltam még a FAT driverben átírni a FAT16 FAT32 filrendszert, de nem segített.
Valaki prbálkozott már a CCS ben SD kártya kezeléssel ?
Esetleg a FAT filerendszerben ?

Hali
Nezz szet a CCS forumon.. Nagyon sok jo megoldast talatam ott.
Udv Vili

Sikerült annyit elérnem hogy elindult a dolog MMC kártyával. De azzal is csak akkor, ha fényképezőgépben formáztam meg.
És még a probléma, az hogy nem mindig működik, többször kell újraindítani az áramkört és egyszer csak sikerül, na meg persze nem tudom lezárni a filokat sem, úgyhogy van min gondolkozni még.

Közben tanakodtam hogy az SD kártyának mi a helyes bekötése, nehogy azzal legyen gond, most a biztonság kedvért minden lábát 100K val felhúztam VDD-re. Így most az ex_mmcsd.c programmal tudok írni SD-re is és MMC re is . Igaz ugyan hogy inicializálásáskor mindig hibát ír ki , párszor resetelenem kell az áramkört mire használható állapotba kerül de utána működik.

Az, ex_fat.c program most már működik SD vel is, ugyanúgy, mint MMC-vel, inicializálás sokadik próbálkozás után sikerül utána file létrehozás mappa létrehozás megy , de ha kiveszem PC ben nem látszik.

Aztán megpróbáltam az általad linkelt kódot átírni, hogy a D7-D4 lábakon működjön. Valahogy ez nem lett sikeres, úgyhogy majd építenem kell erre a célra egy másik áramkört, amiben C portra tudom kötni a kártyát.

Hát valahogy nekem ez az SD kártya dolog nem akar sikerülni sehogy sem.
Már egy jó pár minta programot és kapcsolást megpróbáltam, de eddig semmi eredmény.

Mindenhol irják hogy ez tuti jó kód, de nálam valahogy mégsem jó semelyik.

Valakinek sikerült egyáltalán CCS alatt ezt az SD problémát megoldania ?

Nagyon hálás lennék a segitségért....