Bővebben: Link
Egy motorkerékpár ECUjábol olvassa ki az adatot egy vezetéken. Egy 7segmens kijelzőn mutatja, hogy a motor hanyasba van. Van benne egy nagy vezérlő IC, és egy SO8as. Egyikről sem tudom milyen az.

Az X-ek, meg a V-k micsodák a rajzon?

X, nem kihasznált láb, a V meg valójában pipa, amik azt jelentik hogy oké, az csak a kijelzőre megy.
Van egy TL866os programozóm. Ha esetlegesen Code protect van az IC-n, akkor a programozó mit irna ki? Próbálom leolvasni, mint 628A, de meg se kottyan. Azért mert code protect, vagy mert nem is az az IC?

Gyanítom, hogy az 1k-s ellenállás bekötését kicsit félrerajzoltad. Ahogy most van, nem igazán jó bármire is az áramkör számára.

A kisebbik áramkör valami analóg cucc lehet 12v-os környezethez, és nem igazán látok utána ellenállás osztót. Lehetséges, hogy a nagyobbik áramkör nyersen kap 12v-ot a bemeneteire a kisebbik felől? Ha igen, a nagyobbik tok valószínűleg nem pic.

Bővebben: Link
Igen, az 1K, kicsit elnéztem.
Az egész elektronika tanítható.
(ki-be kapcsolás a kulcs elfordításával párszor, ilyenkor tanuló üzemmódban van. És ilyenkor kell lassan rakni a sebességet felfelé, kicsit meghajtani a mocit. Majd megint fel. Egy mezei IC nemigen tanítható így szerintem.

Ha sikerülne kideríteni milyen IC, akkor mihez kezdenél az infóval?

Ha kell egy ilyen visszajelző, hogy hányadikban van a váltó, és tudsz PIC-et programozni, nem lenne egyszerűbb építeni egy ilyen kütyüt?

Nem kell annak mezei ic-nek lennie, de mikrovezérlőket vagy 30 gyártó dobál piacra, és azok még csak az ismertebbek (még ha nem is itt, Magyarországon). A Microchip PIC-je azok közül csak az egyik.

És akkor még mindig ott vannak a célirányosan gyártott vezérlők is. Az autóipart illetően el tudom képzelni, hogy volt annyi pénz azt megfinanszírozni. A vezérlő elektronika üzletbiztonsági kérdés is.

Az autó iparban bizony sok pénzt raknak bele. Én ugyan nem elektronikát fejlesztek, de egy műszerfalban is pár száz ember egy éves munkája van benne. De így is meglepődnétek milyen dolgokon spórolnak. És most nem a Suzuki gyárra gondolok...

Ehhez képest nem egy autóban látni józan logikával szembemenő dolgot.

Azok üzletpolitika miatt vannak úgy. Mikroelektronikai cuccot gyártani viszont csak pénz kell, és ha az megvan, legyártanak neked bármit. Logikátlan dolgokat is

Épp az, hogy ez nem egy gyári tartozék. Ezeket a kijelzőket egy külön cég gyártja, kijelzőként 100€.
Namost én vettem az ebay-en egy ugyanolyan kinézetűt, Noname, 35dollárért. Ez gondolom csak koppintás, nem feltétlen levédve a PICet. (vagy ami van benne)
Még szám is volt rajta, egy darab 6ost láttam rajta,a többit véletlen levitte a köszörű.

Egy PIC-et ha termekbe programozol, akkor eleve illik letiltanod a kodkiolvasasi funkciot, vagyis copy-paste nem igazan lehetseges. Nem feltetlen PIC ami benne van. lehet FPGA is.

Esetleg tudnal linket kuldeni az eredeti kijelzohoz?

Nekem pl van egy Suzuki DL650-em ... ahhoz gondolkodtam fokozatkijelzőn ...
Kicsit utánanézve nem egy bonyolult dolog. A váltóból kijön egy jel, különböző sebességi fokozatokban különböző feszültség, egy egyszerű AD átalakítással már meg is van a fokozat.

üresben: 5.02V
1.fokozat: 1.42V
2.fokozat: 1.79V
3.fokozat: 2.50V
4.fokozat: 3.26V
5.fokozat: 4.12V
6.fokozat: 4.56V

Állítólag az injektoros motorok többségében ilyen "jeladó" van, ez vezérli az injektortérképet.
Karburátoros mociknál ( ahol nincs ilyen jeladó) ott a sebesség és fordulatszám adatokból számolják a fokozatot.

Az eredeti kijelző GiPro DS.
Lamprologus:

Ja, suzukinál találtam én is leírást, hogy feszültség növekedik.
Hondánál nem így van sajna..

Ezek szerint ezeken a motorokon is van OBD csatlakozo? (Diagnostic system connector)

Esetleg hasznalhato amit talaltam? Bővebben: Link

Egy erdekes project, szerintem hasznosithato infok vannak benneBővebben: Link

Epp most talaltam egy arduino projectet, pont a Te motorodra: Bővebben: Link

Diagnosztika csatlakozó, igen.
Hondánál, legalábbis a motoron ez DLC, Data Link connector.
Elsővel aza gond, hogy ez mágneses. Az simán tévedhet, tehát smemi köze az ECUhoz. (Nemigen plug and play)

Sziasztok!

A ki mit épített-ben Bővebben: Link, Bővebben: Link ben említett panel-al lenne egy kérdésem.
A TFT-t PMP-vel hajtom 16 biten PMWR/PMRD-vel na most a PMD-nél van a busy (foglaltság) bit amit eddig úgy használtam PMDIN = adat; while (PMMODEbits.BUSY); de gondoltam egyet és kivettem a busy-t természetesen még gyorsabb lett, de ami meglepett, nem okoz problémát a képek megjelenítése hibátlanul megjelennek.

Ha nem figyelem a busy bitet okozhat problémát/adat vesztést?

Talán meg is tudom válaszolni a kérdésem.

Átírtam úgy a kódot, hogy while (PMMODEbits.BUSY); PMDIN = adat; és az optimalizációt 3-masra állítottam és nagyjából ugyanazt a sebességet kaptam mint 0 opt-on busy nélkül, kivettem a busy-t 3-as opt-on és már hibásan jelenített meg a kijelző.

Szerintem pont elérted azt a sebességet,aminél már kell a busy .Optimalizáld busy-val,és teszt

Tapasztalt már valaki hasonlót?
MPLABX-ben programozok egy dsPIC33EP512GP806-ot XC16 fordítóval. Elég bonyolult egy projekt, vagy 8-10db c fájl tartozik hozzá. A programmemória 30%-ig, az adatmemória 50%-ig van tele, bár nem hiszem hogy ez a hiba szempontjából releváns lenne. A jelenség a következő:
Teljesen jól működik a program beégetve és PICkit3-mal debuggolva is. De folytatnám a szoftver fejlesztését és ehhez szükségem lenne egy új globális struktúra-tömbbre. A main.c tetejébe bele is írom, hogy:

A struktúra egyébként így néz ki de szerintem ez is irreleváns:

Semmi mást nem írok bele a programba, csak és kizárólag ezt. Lefordítom majd beégetem a PIC-be a programot és tökélesen működik ugyan úgy mint ezelőtt. Aztán elindítom a debuggert (a PICkit3-mal) és a program elindul. Megy pár másodpercig majd az MPLABX a PICkit3 ablakában azt írja hogy "Target Halted" és a program futása tényleg megáll. Ezt onnan tudom hogy látom a kijelzőn, ugyanis a PIC a bekapcsolás után egy képet rajzol ki a TFT-re és kb a kép negyedénél megáll. Az MPLABX-ben pedig nem látom hogy hol állt meg a program mert nem mutatja. Próbálom a "Focus Cursor at PC", a "Step Over" és a "Continue" gombbokat de nem reagál semmire.
Kikommentezem a struktúratömb definiálásának sorát és újraindítom a debuggert, erre tökéletesen elindul a programom mindenféle leállás nélkül. A "Pause" gombbal meg tudom állítani és mutatja is hogy hol állt meg, tudom léptetni meg minden... Visszakommentezem a sort és ismét meghal a program!

Próbáltam azt hogy másik c fájlban deklarálom a tömbbömet de akkor is ezt csinálja. Többször nekifutottam de teljesen reprodukálható a hiba. Egyszerűen nem hiszem el, hát ilyen meg hogy lehet?!

Kicseréltem erre:

Így rendesen megy a program. Pedig ez a tömb elméletileg ugyan akkora méretű mint a kikommentezett struktúra.

Tipp1:
Gyaníthatóan valami el van keffentve a fordító alsó rétegeiben, és nem pont az fordul, mint amit hiszel róla. Hogy mi fordul valójában? A roseb tudja. De leállni a pic sokféleképpen tud. Például a paraméter átadásnál egy függvényben rosszul teszi rendbe a vermet kilépéskor, és máris ráfut egy nem létező program részletre. Persze találgatással nem oldódik meg a probléma. Amit tehetsz, hogy másik részlettel helyettesíted. Ha forráskódilag ragaszkodsz a struktúrához, leírható sima struc-al is, a typedef-et hagyd ki belőle:

A toolchain hibái miatt talán így nem téved el.

Tipp2:
Egész biztos csak annyit írsz át a programban ami a működés / nem működés közötti különbség? Nincs ott valami más is, ami "á, az biztosan jó úgy"?

Ha a struktúra nem tömör (packed), akkor kétsze akkora helyet is foglalhat.

Ket u8-at tartalmazo struktura nagyobb lenne, mint 2 byte? Nem hiszem. 8 bites valtozokon nincs mit align-olni, mitol lenne nagyobb?

Nincs. A működő és a nem működő program közt csak az a különbség hogy kikommentezem vagy nem kommentezem ki azt az egyetlen sort. Semmi mást nem változtatok a programban.

Nehéz a környezet ismerete nélkül bármit is javasolni.

A megvalósított RAM terület 0x0000 ... 0xDFFF. A hoszza 0xE000, ennek fele 0x7000. Ha ide még felveszel 20 byte -ot, a program fut nyomkövetés nélkül. Ha a foglalással kiegészített programot nyomközeted, lefagy a PICkit3.
Meglehet nem marad elég hely a stack -nek és a PICkit3 debuggoláshoz szükséges területének. Ugyan furcsának hangzik hogy nem marad hely, de a 0x8000 .. 0xFFFF terület helyére a program memória "belapozható", így a változók elérhetetlenekké válhatnak. Honann írod ki az a képet?

Az SD-kártyáról olvasok be és rajzolok ki a képernyőre egy BMP fájlt.

Előfordulhat olyan is, hogy a programban valahol van egy félrecímzés (pl. tömbindex rossz számolása), ami eddig nem okozott problémát, de az új struktúra bevezetésével máshová kerülnek a változók, és így a félrecímzés kritikussá válhatott.