Én kérdeztem, hogy milyen átmenetet vár a RealTerm.
Mert az eszköz állandó magas jelet húz alacsonyra. A Salae-ben ezt lehet állítani, de a RealTermben ilyet nem találtam. Azért gondolom, hogy talán ez a hiba, mert 8 byte egy adatcsomag, aminek az első és utolsó byteja sosem változik, de ilyen formában stabil adatot 8 bytera állítva sosem kaptam.

Ha nem tévedek egy darab tranzisztorral át lehet fordítani a jelet szabványos TTL soros jelszintre.
Valószínűleg érdemes lenne.

Köszönöm.
Megpróbálom.

Esetleg próbáld meg a PUTTY vagy az RS232 Analyzer progikat. Én valamelyiket a kettő közül használtam már, amikor az volt a téma, hogy az indulás után a regiszterek milyen értéket vesznek fel maguktól.

Mivel a PC-s programok a szabványos PC-s kártyákat használják, így olyan szintet kezel, ami megfelel a kárytának. A legelterjedtebb az RS232 szabványú soros kártya. Ezekkel nem fogadható közvetlenül egy PIC soros 5V -os vagy 3.3V -os vonala. Kell közéjük egy TTL - RS232 konverter: MAX232, MAX3232 vagy egyszerű két tranzistoros.
Használható még USB - COM port. Ezekből van TTL szintekkel rendelkező felületű is.
Használható még a Hercules, TerraTerm program is.

Sziasztok!

Sajnos megakadtam a PICKIT3-mal való programfeltöltésben. Ezerszer leellenőriztem a kapcsolást, nem egy bonyolult, led villogtatóhoz hasonló kapcsolás. Megírtam a programot, le is futott rendesen, rádugtam a pickit3- at, a pickit3 programmert megnyitottam, ki is írta rendben, hogy "pickit3 connected, pic device found" majd mikor importálni szerettem volna a hex fájlt, akkor azt írja ki, hogy "device error, hex file not loaded", piros háttérrel.... Ha a write-ra kattintok, akkor meg sárga háttérrel a "no device detectede" című üzenetet írja ki.... Több gépről is megpróbáltam ugyanazt a hex filet feltölteni rá, mindenhol ugyanaz a probléma... Eddig tökéletesen működött. Szerintetek mi lehet a baj/mit lenne érdemes csinálnom, próbálnom, illetve az a kérdésem, hogy találkozott e valaki hasonlóval?

Minden választ előre is köszönök, tényleg nem tudom, hogy mi lehet a probléma!

Milyen típust szerettél volna programozni?
Töltsd fel a hex állományt és a hibaüzeneteket is tartalmazó képernyő mentéseket!

PIC16F628A a kontroller

Én csak nagyon a partszélről kérdeznék, hátha tudok segíteni...

Pontosan mit jelent az, hogy Tehát hol, milyen jeleket szeretnél figyelni? Van róla rajzod?

Milyen távirányító ez? Van valamilyen cél IC, annak a jelét szeretnéd vizsgálni? A PIC által kiadott jelet vizsgálod? (Az infra jel általában modulálva van, tehát nem mindegy, hogy hol és mit szeretnél mérni.)

- Keresd meg a "run self test" menüpontot (??debuggger/settings/run self test??) és futtasd.
- A processzor legyen áramkörben és tápfeszültség alatt programozáskor

Ha ez nem elegendő akkor közölj velünk több infót.
MPLab IDE vagy MPLAB-X IDE, driverek rendben vannak-e, gyári-e a programozód, vagy klón, más processzorokkal működik-e, mi a bekötésed, kapcsolási rajz, stb.

Szia!

A JJRC H 47-es drón mobilaplikációval is irányítható wifin keresztül.
Egy teljesen független egység küldi a telefonra a kamera képét és fogadja az irányítást.
Mindössze 3 vezetékkel kapcsolódik a drón vezérlőjéhez, és ebből kettő a táp.
Alap UART kommunikációt használ, egy 8 byteos adatfolyammal.
De legnagyobb sajnálatomra a program nem egyszerűen az irányítókarok pozíció adatait küldi, hanem egyből a motorok működésébe avatkozik be. Hogy értelmezni tudjam egy PIC-el a jeleit, és más eszközre szerelhessem, látnom kellene mikor mit küld.
A logikai analizátor ugyan elég hosszú ideig képes rögzíteni az adatokat, de több tízezer adatból nehéz kimazsolázni, mikor, mi jött.
Ezért kellene valami olyan megoldás, ami csak egy sor adatot jelenít meg, mert azon minden változás azonnal látszik.
Legvégső esetben összedobok egy áramkört, meg egy programot, hogy LCD-n megjelenítssem, de ha van más mód, akkor ezt szeretném megúszni.

Eléggé nehéz elképzelni, hogy direktben a motorokat vezérelné.
Egy drónnál ez nem olyan, mint egy távirányítós kisautónál.
Sok más paramétertől függ az egyes motorok értéke.
Szerintem alaposabban tanulmányozni kellene a protocolt, még az is lehet, hogy szabványos.

1. MAX3232 szintillesztő -> PC. A TERM95 program képes szöveges és bináris adatok megjelenítésére. Mit jelent a sor? Van valami végjel vagy adott mennyiségű adat átvitelét jelenti?
2. Mekkora a sebesség? A PICki2 -ben van egy UART tool is. Ehhez nem kell a szintillesztő.

Ezek az adatok honnan vannak? Van valamilyen leírás erre vonatkozóan? (Gondolom nincs, azért akarod megmonitorozni, hogy visszafejtsd... de valahonnan csak lehet tudni amiket leírtál.)

Először szkóppal vizsgáltam a jeleket, majd logikai analizátorra raktam.
Az analizátor mutatta meg, hogy 8 byteos csomagokban jön a jel, 10 msec-es frissítéssel, és hogy az első és utolsó byte sosem váltotik.

Egy drónnál nem lehet csak úgy direktbe motorokat vezérelni, az nem úgy megy. Normális drónban van gyorsulás mérő, billenés detektor, azok a motorok "gondolkodnak". Fújni kezdené a szél a drónt, elkezd ellent tartani dőlésszög változtatással. A motorok teljesítménye sem mind egyforma, a vezérlő felszálláskor "profilozza" a motorokat. Mindazt nem lehet egy soros porton keresztül. Egy soros porton keresztül logikai szintű parancsokat tudsz adni maximum "előre", "oldalra", "emelkedj", "tartsd ott", "kamera rögzítés indul" - ilyesmik

Mivel te már a második vagy, akit ez a mondat félrevezet, így egész biztos, hogy hibásan fogalmaztam. Nem azt akartam ezzel mondani, hogy a távirányító vezérli a motorokat, hanem azt, hogy a kiadott parancsnak megfelelő motorok számára küld adott mértékű beavatkozásra utasítást.
Most csak emlékezetből, hogy nagyjából mit mazsoláztam eddig ki.
Lebeg egyhelyben:
0x66 0x80 0x80 0x00 0x80 0x00 0x80 0x99
Indul előre közepes sebességgel:
0x66 0xE3 0x65 0x00 0xE3 0x00 0x65 0x99
Oldalaz:
0x66 0xE3 0xE3 0x00 0x65 0x00 0x65 0x99
Azaz mindíg 4 byte változik, és 2-2 párban. De összetetteb karállásra, már 2-7 ig van változás, és a kezdeti szabályosság odalesz.
Ezért kellene pontosan lejegyezzem, milyen karállás, vagy épp gombnyomás hatására milyen kód jön, hogy rájöjjek a logikájára. Nem drónt akarok vele vezérelni.

Aha. Így már világos.
Na de honnan jött az, hogy ez USART kommunikáció?
Segíteni sajnos nem tudok. De szerintem attól, hogy szkóppal/jelanalizátorral megnézted, még nem következik egyenesen, hogy ez USART kommunikáció. (Hacsak az ott látott jelekből egyértelműen ki nem derül, hogy valóban USART. De akkor onnan kell meghatároznod azt is, hogy milyen sebességgel, hány adatbittel, hány stopbittel stb. folyik a kommunikáció.)

Az USART-nak, mint minden más kommunikációs protokollnak, megvannak a szabályai. Ha aszinkron átvitelről beszélünk (esetünkben ez jöhet szóba, mivel egyetlen kommunikációs vonal van), akkor egy byte átvitele úgy néz ki, hogy start bittel indul, utána jönnek az adatok, amik lehetnek 7,8 vagy 9 bitesek, majd lehet utána paritásbit, illetve 1, 1.5 vagy 2 stopbit. De annyira én sem értek hozzá... Oda akartam kilyukadni, hogy a szkóp illetve az analizátor jeléből ezt sikerült biztosan megállapítanod, hogy itt USART kommunikációról van szó? Mert ha nem az, akkor hiába próbálod "USART-ként értelmezni", nem valószínű, hogy értelmes, konzekvens adatokat fogsz kapni.
(Azt hittem, hogy a gépkönyv esetleg említi konkrétan, hogy USART kommunikácóról van szó. Ez így lehet akármilyen egyedi protokoll is akár.)

ICD3-al mik a tapasztalataitok? Mindenkinek tetű lassú?
Korábban ICD2-t használtam MPLAB alatt. Kattintottam, csinálta amit kell.
Vettem egy ICD3-at az MPLAB-X-hez. Rányomok a 'hold in reset' ikonra, kb. 10 másodperc mire megcsinálja. Próbáltam 32 és 64 bites oprendszeren is, ugyanaz.

A régi MpLab 8.xx alatt is ilyen lassú volt vagy csak az MpLab X alatt?

Sosem használtam az ICD 3-at a régi 8.xx MPLAB-IDE alatt.
MPLAB v8-al ICD2-t, MPLAB-X-el ICD3-at használtam.

Igen, nálam is tetű lassú. Nem mértem, de majdnem egy perc mire feltölt egy P24-et.
Nem oly` rég tértem át MPLABX+ICD3-ra MikroE termékekről - a feltöltés sebessége szempontjából az utóbbi a nyerő.