Illene megtanulni az union használatát. Alapvető C ismeret.

És még valami. Ha 32 bites cpu-n vagy, jó sok gondot lehet azzal áthidalni, hogy nem 8 meg 16 bitezel, ha csak nem helyszűke miatt kényszer az adatok szoros csomagolása. Van azon az mx795-ön bőven erőforrás 32 biten kezelni a 8 bites értéket is. Persze szívathatod magadat, ha az a szórakozásod, de azon túl nem kell félni a 32 bit egyikétől sem, nem harapnak

Használok Union-okat, de jelenleg csak a címzéshez van rá szükség.
Változókba mindig olyat próbálok használni ami feltétlen szükséges.
Szívatni mindig tudom magam, nem szükséges, hozzá még PIC-sem.

Most sem a pic-el szivattad magad, hanem az adat konvertálással. Csak be kellett volna tölteni az adatot byte-onként (unsigned char, semmi előjelezés), és kivenni integerként, vagy ahogy akarod.

A 12f / 16f szériákon elég kevés ram van, ott tényleg vigyázni kell minden byte-ra alkalmasint, de a 32-esek tömve vannak erőforrással. A 32-eseken nem kell vigyázni a változók számával. Ha csak nem az idegeidet akarod roncsolni cél és értelem nélkül, szerintem válaszd a kényelmet ott, ahol nyugodtan megteheted. Aztán ahogy érzed

Szerintem 32-biten nyugodtan használhatsz 32-bites változókat (X32-ben az int alapé. 32 bit), nem hinném, hogy az elején mikor még a program prototípusánál tartasz azzal kéne foglalkozni, hogy mekkora.
Meg szerintem az XC32, ha 2 db 16 bites változót használsz csak nem rakja egy memória terület felső és alsó felére vagy ebben én tévedek?

Idézet:
„Szerintem 32-biten nyugodtan használhatsz 32-bites változókat...”

Szerintem az USB kezelését nem Ő írta, így az USB_In_Buffer[] -t a meglevő programhoz kellett igazítani.

A 32 bites stack-ben (2013 febr 15-ös) én összesen egy BYTE INPacket[64] és BYTE OUTPacket[64]-t találtam. Az ugyan nem sok előjelezést kényszerít, unsigned char kompatibilis.

pajti2: Microchipék már megírták az USB stack-et amit használok, jól mondja Hp41C.
Mivel ezt ők megírták, ezért ezt a részt én nem bántom, csak a nagyon szükséges részeknél írtam át.
A gond egyébként ott volt, hogy Microchipék az USB_In_Buffer[] tömböt, sima char ként deklarálták, ezért felvehetett előjeles értéket is.
Meg is tette és keresztbe is verte az adatátvitelemet.
Ezt módosítottam unsigned-re és már is gyönyörködhettem a valós adatokban..

cross51: mire beszereztem az Mplab X-et PRO verzióba, addigra rá is jöttem, hogy nem lesz nekem jó, így nyomban hanyagoltam is. (nem töröltem..., még)
Mivel nincs rá USB stack és a régi nem kompatibilis, így számomra most még nem opció..

Melyik stack verziót használtad arra a project-re?

Bővebben: Link
Ez frankón működik..

Hali,
Adott egy 18F26K80, 3.3V-ról járatva. Az adatlap szerint logikai 0 a bemenet (RB0-t próbáltam csak), ha 0.2Vdd alatt van. Ez esetben tehát akkor 0.66V. Ehhez képest, a valóságban azt tapasztalom, hogy ha 1.27V alá kerül a láb, akkor már logikai 0 lesz.
Vélemények/tapasztalatok?
Vagy lehet már csak nekem van este..

Logikai bemenetet határozott H vagy L szinttel kell vezérelni.

Azon a pic-en az rb0-ád digitális üzemben st bemenet. Ha kap egy feszültség tüskét 0.2vdd alatt (bármi elég egyetlen pillanatra is), behúz a trigger, és utána tartja az alacsony állapotot, amíg felül nem lövöd a 0.8vdd-t.

Mármint 0.8V-ot.
Egyébként ez sem igaz. Ugyanis csak 1.6V-nál kapcsol vissza 1-be, mármint itt most, nálam.
De nem akarom elhinni, hogy ennyire nem tartja az adatlap értékét a PIC, valahol biztos valami gubanc van, csak nem tudom hol. Megnézek másik lábat, meg ha találok potit, azzal is játszok...
Szerk.: egyébként köszi a válaszokat.

Ezzel egyébként most mi a célod?
Ha digitális bemenetként akarod használni, ne játssz a jelszintekkel. Az csak zavart szül. Ha meg feszültség szintet akarsz érzékelni, tedd komparátorral, vagy A/D-vel.
Ezt írod:

Ezek szerint lebeg a bemeneted. Ennél már csak akkor tehetnél rosszabbat, ha erre a lebegő bemenetre még egy antennát is raknál.

Én részemről zárom a felvetést, ennek így semmi értelme. Azért köszönöm a hozzászólásokat.

Szerintem nem 0.2Vdd, hanem maximum 0.2Vdd. Tehát ha biztosan logikai 0-t akarsz beolvasni, akkor legalább 0,2Vdd -ig kell csökkenteni a feszültséget a lábon -> maximum 0,2Vdd lehet. Fölötte nem garantált a logikai 0, azt a tartomány bizonytalan, függ sok mindentől.
Ugyan így, ha biztosan logikai 1 -et akarsz, minimum 0.8Vdd kell hozzá a lábon. Ezért van a "min" oszlopban a 0,8.
A 0,2 és 0,8 közötti tartomány nem egészséges, ahogy azt már többen írták.

Igen, valami ilyesmi lehet, köszönöm!

@AZoli, @zenetom:

A Schmitt trigger, vagy szakzsargon nevén simán csak "ST" működése egy jól dokumentált valami, a találgatás felesleges.

Gyors összefoglalóban a kapunak hiszterézise van, és bemeneti 1 bites memóriája. Az ST bemenet nem csak egy sima bemenet, az komplett logika. A kapcsolási szintjei ott vannak a jelzett pic adatlapjában, nincs azon mit félre érteni. A korlátok 0.2 Vdd és 0.8 Vdd (3.3V tápfesz esetén 0.66V és 2.64V). Ahhoz, hogy a bemeneti állapot érzékelés lekapcsoljon logikai 0-ra, a feszültség szintnek felülről lefelé menet el kell kasszantania az 0.2 Vdd feszültség szintet (3.3V táp esetén 0.66V), és akkor a trigger "billen", átkapcsolja a következő jelszint váltási korlátot 0.8 Vdd-re. "Megjegyzi" az aktuális állapotot a saját 1 bites memóriájában, és tartja a logikai 0-t egészen addig, míg a feszültség szint alulról fölfelé el nem kasszantja a 0.8 Vdd (3.3V táp esetén 2.64V), amikor is újra billen a trigger logikai 1-be, és vissza kapcsolja a kövekező billenési feszültséget 0.2 Vdd-re.

Ha a feszültség szint "lebeg", az a TTL esetében lehet, hogy veszélyes, de az ST-nél kicsit sem. Az ST direkt arra lett kitalálva, hogy az a probléma a múlt jótékony homályába vesszen, és többé ne létezzen. _Zéró_ problémát jelent az ST bemenetnek akár a folyamatos analóg jelszint is, lebegjen bárhol. Nem lesz miatta semmi féle extra fogyasztás, meg elektronika-veszélyeztetés, meg semmi olyasmi.

Jelezzétek, ha még mindig nyitott kérdés van az ST működéséről.

Először is, köszönöm a részletes leírást, bár én ennek teljesen a tudatában voltam, csak nem akartam, és nem is akarom tovább firtatni a témát.

Sziasztok!
Újra kellett telepítenem a gépem.
Feltettem az mplab 8.9.et és az mplabc30-v3_31-et.
Minden projekt fordításakor ez a hiba jön elő:pic30-lm.exe működése leállt.
Ez a párosítás azelőtt működött. A telepítőt a microchip oldalról töltöttem le.
Van teljes verzióm c30,v3.0-bol amivel működne is, csak az nem ismeri a 33EP PIC-et.
Valami ötlet honnan tölthetnék le működő verziót, vagy hogyan frissíthetnék 3.0- ról 3.31-re?
Sos- ben kéne, köszi Szabolcs

Talán lépésenként. Download Archive
Nálam az MpLab 8.92 és C30 V3.31 működik.

Sziasztok!
Valaki tudna ötletett adni hogy eepromba hogy lehetne animációkat tárolni??
Segítséget Előre köszönöm.

Az animációt felbontod számokra és elmented. Milyen kontrolleren gondolod ezt végrehajtani?

Pic18f46k22 ha erre gondoltál.

Van benne 1 kByte EEPROM, de hogy ez mire lesz elég, azt csak te tudod. Pláne, hogy nem lehet tudni semmit az animációról, sem a megjelenítőről.

Vu meter szeretnék bele animálni időmultiplex


Kb igynézki a dolog.

Mivel a kontrollernek nem kis programmemóriája (ROM) van, azzal kcisit jobban jársz.

Csak az a baj hogy egy animáció kb 6% az nem sok??(forgó animáció)

A programmemóriából annyit vesz el? 6 %-nyi programmemória kb. 3.8 kByte, az EEPROM pedig összesen 1 kByte. Ha leredukálod a dolgokat, valószínűleg akkor is nagyon kevés lépés fér az EEPROM-ba. Ha nem elég a hely, használj külső tárhelyet (külső EEPROM, SD kártya stb.).

SD kártya?????? Ez érdekel. Micro s-d???
Van rá valami kapcsolás vay sematika hogy kell bekötni???
Milyen formátumba olvasná stb.


Igen sajnos egy forgo animáció multiplexel.