Ha vsprintf megboritja a rendszert, akkor az osszes tobbi tarsai is csinalhat ilyet, es ettol kezdve se printf, se sprintf, se semmi?

A vsprintf egy bizonyos karakterhossz felett bolondul meg, az alatt használható. Nem tudom hogy a többi gyári függvénynek van-e ilyesmi hibája. Amivel még találkoztam az a string.h-nak a strstr() függvénye, az tuti hogy hibásan van megírva. Néhány hónapja ezt be is írtam ide a topikba, hogy neki az a baja hogy csk akkor hajlandó megtalálni a karakterláncban a karakterláncot, ha az utóbbi az előbbinek a legelején van. Tehát például a "Mikrovezérlő" sztringben a "Mikro" szót megtalálja, de mondjuk a "rovez"-et nem.

Hat, ez eleg szomoru.

Ezt Melyik XC alatt tapasztaltad?
Nekem XC32-vel megy szerencsére.

XC16-al.

Akkor jó tudni, hogy az XC32-ben megy.

Sziasztok!

Ismét elővettem a PIC32MZ2048EFH100-as projekt ADC részét. Kinyomtattam az adatlapot, újra átolvastam, bejelölgettem dolgokat...
A következő kóddal inicializálom, melyben elvileg nem ártana a while-os részek, de a kikommentezettből nem lép ki:


A kiolvasásban ez a függvény segít:


A kiolvasott érték mindig 0. Van ötletetek, hogy miért? Mit hagytam ki az inicializálásból?

A fenti kifejezés sohasem lesz 0.

A while(ADCDSTAT1bits.ARDY15 == 0);-t is próbáltam.
Jóra várakozok itt? Ez tartozik az AN15-höz, ugye?

Na erre varrjatok gombbot!
Van egy ilyen sorom:

A három függvény benne így néz ki:

Visszatérési értékük típusa u8 és u16, ezek "unsigned char" és "unsigned int" típusokat takarnak.
A probléma az, hogy a sztringben az év stimmel, de a hónap és a nap hülyeség lesz. Például: "2017.19203.19223." Valamiért a hónap és a nap értékéhez hozzáadódik 19200, ami fogalmam sincs hogyan történhet.
Még érdekesebb, hogy ha a három függvény visszatérési értékét a sprintf() előtt külön kimentem egy-egy változóba és azt adom át a sprintf()-nek, akkor viszont működik:

Tulajdonképpen így szuperül működik, csak bosszant a dolog hogy amúgy meg miért nem, hiszen jónak kellene lennie. (A fenti struktúra hivatkozott három elemének típusa ugyan az mint a függvények visszatérési értékének típusa.)

Lehet, hogy rosszul teszi le a stack-re az u8 ertekeket, amikor a sprintf-et hivod. Elvileg at kellene konvertalnia int-re, de lehet, hogy ezt elrontja. A 19200 az 0x4b00, tehat az a gond, hogy a felso byteban 0x4b-van es nem 0, amikor az RTCC_honap() erteket beteszi a stack-be. Ez fordito hiba elso ranezesre. Ha u16-nak deklaralod oket, akkor valoszinuleg jo lesz. Esetleg erdemes megnezni, hogy mit forditott belole, abbol latszik, hogy hol rontja el.

sprintf(str,"Dátum: %04u.%02u.%02u.",RTCC_ev(),(u16)RTCC_honap(),(u16)RTCC_nap()); ?

Próbáltam kasztolni, de ugyan az a végeredmény.

Próbáld így :


A hiba,vagyis a sprintf végeredményén látszik,hogy ő a hó,nap-nál intet olvas be,de char a forrás,és így a mellette lévő címről is beolvas valamit.Legalábbis nekem úgy tűnik .

Ha explicit casting sem megy, az tuti fordító hiba.

Ez mindenkeppen fordito hiba. A C eleve minden char-t int-kent kell atadjon. Automatikusan benne van a cast. Es 16 bitet is ad at, csak a felso byte-ot nem torli.

Sziasztok!

Egy 32mx170f256b-vel próbálok SPI DMA-t csinálni, de nem akar úgy működni ahogyan szeretném.


A kódnak így sok értelme nincs, csak a teszt miatt van benne a while a végén.
A problémák amiket észre vettem:
bárhogy állítom a STXISELT az IFS1 SPI2TXIF-et nem tudom törölni a DMA transzfer előtt.
Ha az SSIZ 16 byte méretű akkor szépen megy, de az ENHBUF be van kapcsolva ami pont 16 byte-os.
Ha 16 byte-nál nagyobb az SPI2EIF mindig 1 lesz.
Ebből gondolom azt, hogy valamiért a DMA "rosszul informálódik az SPI transzfer OK-ról" és küldi folyamatosan az adatot és gondolom az error if abból van, hogy a fifo teli van és úgy akarok bele írni.

Próbáltam az RX IRQ-ra is rakni, de ott is csak 16 byte-ig ment mi lehet a baj?

Új PIC32 család a láthatáron: PIC32MK a szinte szokásos (lassan más elvárt) jó hosszú errataval és kavarodásokkal (az errata linken megnyitott pdf dokumentum címe a PIC32DA családot említi). Az adat EEProm memória leírása
Section 58. “Data EEPROM” (DS60001341) még nem is létezik....

Az errata tényleg hosszú, sajnálatosnak tartom, hogy még ennek az A1-es verziójában is probléma van az oszcillátorral, bár ahogy láttam ez kapott már trace-t is bár nem is tudom, hogy a microchipnek van e trace-es debuggere (talán a real ice..).

Sajnos nem tűnik olyan nagy előrelépésnek az M-től.
Meg kerül egy két újdonság a doksiba az pl.: az ajánlott bekötés kicsit részletesebb lett az tetszett mondjuk.

Köszi a híreket!

Szóval az mz családhoz képest lefelezték a maximum sram-ot, a hs usb helyett újra csak fs usb van, és kihagyták az eredeti da tervből a beépített dram-ot, ami kb az egyetlen valódi újdonság lehetett volna. Az egyetlen újítás, hogy van dupla usb port egy tokon. Valami olyasmit érzek az mc teljesítményéről, mint a bank reklámok végén a "Köszönjük Emese!".

Nem értem ezt a vonalat. Inkább az MZ-t fejlesztenék tovább, DRAM és SD protokollos támodatással. Föl nem fogom, hogyan lehet ennyi hibát beletenni azután, hogy egy másik sorozatot már kikupáltak (MZ EFx). Még szerencse, hogy nem tud olyan dolgokat, amikre szükség is lenne, mert akkor most nagyon dühös lennék. Így, hogy lassú, fs usb, és sok hiba, szerintem ki se kéne hozniuk. Még az MM kis fogyasztását és kevés lábszámát, kis tokozását se hozza...
Szerinted elvi hiba van a "fólián", vagy a gyártás során sikerül félre valami?

Sok gyártónál már régóta van motor control sorozat. Az NXP-nél például LPC15xx és Kinetis KV néven.

Szerintem az MK nem a MZ__DA család helyett készül, hanem úgy mellette választékbővítésként.
Engem inkább az zavar, hogy két-három évvel az első MZ megjelenése után is ilyen hibákat tartalmaz az első errata. (Biztosak lehetünk, hogy lesz még több bejegyzés benne...)

Akkor továbbra sem értjük Mi lenne az a "motor control" funkció? Ha szinkron motor vezérlésre célzol, az egy mezei állapotgép, amit bármilyen pic megcsinál.

Sziasztok!

Nem tudom jó helyre írók-e. Tud valaki segíteni nekem? szükségem lenne egy 3V3-1V8 adapter
kapcsolási rajzra.
valaki tud linkelni egyet?

Nem egészen jó helyen, de gondolom PIC-hez kell.
Kapcsoló üzemű vagy lineáris?

25q64fw chip
tl866 programozo

3v3 -> 1v8 zéró probléma. Tennivaló: bemégy bármelyik elektrotechnikai boltba, kérsz 1.8v-os stabilizátor ic-t (megkérdezik majd milyen tokozással, mekkora árammal szeretnéd, választasz a kínálatból, ami tetszik), utólag megnézed a típusjelét, és bármit adtak, az adatlapját felkotrod google-el. Lesz az adatlapban példa kapcsolási rajz is.

Köszi,

Ez a chip nem tolerálja az 1.8v feletti szinteket egyetlen kivezetésén sem. Nem lesz feltétlen elég csak a tápegység feszültségét csökkenteni. Nem ismerem a programozót, de az interneten mindenhol szintillesztő áramkört ajánlanak hozzá.