Sziasztok!

Sikerült beszereznem egy RS232-TTL átalakítót (MAX3232 ic-vel). Ennek működési feszültsége ~3-5V. Viszont amihez kellene annak 21V (jel) működési feszültsége van.

A kérdésem az lenne, hogy esetleg valakinek van-e ötlete az alapesetben 3-5V-os jel 20-21V-os felerősítésére? (kapcsolási rajz, egyebek jól jönnének)

Előre is köszönöm. Üdv. Gábor

Ha csak feszültségerősítés kell, műveleti erősítővel meg tudod oldani. Sima fázist nem fordító áramkörrel. Hirtelen ez jutott eszembe, de ma elég fárad vagyok már :/

Igen az jó ötlet, Az RS232 nem kell, csak egy sima inverter, aztán egy OPA, +/-21V os tápról.
Illetve...a szinteltolást még meg kell oldani, hogy a nulla közeli helyett valami negativ feszt kapjon az OPA. (Az invertálást is rá lehet bízni a végén lévő OPA-ra)

Köszönöm szépen a segítségeteket!

Sziasztok.
Segítséget szeretnék kérni.Építenék egy max232 programozót, ugye ez rs232 porton kommunikál, de mivel laptopomon nincs ilyen port szeretném ha usb porton működne megfelelően. Gondolkoztam azon hogy megépítem ftdi chipel vagy egy PICel, de nem tudom melyik lenne a működőképesebb konstrukció!+ tervem sincs hozzá...
Ezt a programot szeretném használni: MOTOROLA CRACKER
Ezt kéne olvasnom/írnom : MCU Motorola mask 0F11N (MC68HC11L6)
Bármilyen ötletet meghallgatok.
Köszönöm a segítséget.

Az USB-s soros átalakítók nem minden esetben alkalmasak az egyszerű COM-os programozókhoz. Lehet mondani, hogy egyáltalán nem, kivétel az olyan, ami kommunikál a PC-vel és nem a COM vonalait használja API-n keresztül direktben. Nos ilyeneket nem nagyon láttam még.

Üdv.

egy projektemben szükségem lenne arra, hogy néhány változó értékét elküldjem soros porton keresztül PC-re PIC16f877-ről. Korábban már többször csináltam ilyet és működött is. van egy max232-re alapuló szint illesztő kapcsolásom, amit már korábban használtam. A PIC órajelét 20MHz kristály adja, erre a frekvenciára van egy usart librarym, ami mint már mondtam régebben jó volt adatok küldésére. ami változott az az rs232-usb adaper. ez egy Prolific adapter (a régi talán aten volt, de lehet, hogy az is prolific volt). A helyzet az, hogy nem jönnek át helyesen az adatok a PC-re. ha a PIC felől küldök számokat akkor a PC oldalon egy random karakter sorozat jelenik meg. Vagy ha elküldök egy "/" jelet átjön egy "b". kipróbáltam másik PIC-el is akkor más karakterek jöttek meg, de azok is hibásan. A kommunikácó sebessége mindkét oldalon 9600-ra van állítva. mi okozhat ilyen problémát? mégis csak az órajelnél csúszik el valami? vagy a szintillesztő IC kever be valamit, esetleg a kapcsolásom megsütötte a PIC usart lábait?

Kösd össze az adaptered 2-es és 3-as lábát és küld terminálról egy karaktert. Ha ugyanaz érkezik vissza, akkor az illesztőd jó.
Ellenőrizd le az adatlap szerint, hogy az USART regiszterei megfelelő értékre vannak-e beállítva. Ha a library más frekire volt beállítva, akkor most nem jó a baud sebesség.

Ha összekötöm a 2-3 lábat és küldök egy karaktert nem jön vissza semmi, ellenben abban a pillanatban amikor a két lábat összezárom jön egy rakat random karakter.
Az USART jól van beállítva 20MHz-re van a library én is annyiról járatom a PIC-et

Gondolom ezt úgy próbáltad, hogy az USB adapter 9 lábú COM csatijának 2-3 lábát kötötted csak össze és nem volt rádugva a PIC, ugye?
Ha így volt, akkor az adaptered kuka, vagy nem jól van feltéve a drivere.

Nem volt a PIC-re rákötve. Akkor ennyit érnek a e-bayes adapterek . Kérek majd kölcsön hétfőn egy másik adaptert, és megnézem azzal. Az ugye nem lehetséges, hogy ha szintillesztő is van a PIC és az adapter között akkor egy rossz adapter tönkretenné a PIC USART modulját? Esetleg nincs valami mezítlábas megoldás arra, hogy megnézzem mi jön ki a Tx lábon a PIC ből? gondolom ha debugger módban ránézek az USART kimeneti regiszterére, hogy mi van benne az nem mérvadó

A PICkit2 egy USB uart is TTL (MOS) szintekkel. De miért rendeltek sok pénzért USB soros átalakítót, amikor egy 16F1454 (~400 Ft+Áfa) és egy ellenállással és két kondenzátorral megoldható a feladat. Ha RS232 kimeneti szintek kellenek, akkor még egy MAX232 és 5 kondenzátor. Ld. itt.

Lehet ez egy hülye kérdés lesz, de ezek szerint akkor egy PICkit2-vel tudok USARTon keresztül adatokat küldeni PC terminal programba?

Nem egészen így. A PICkit2 kezelő programjában van egy lehetőség, hogy adatokat küldj és fogadj aszinkron soros formában: Tools / Uart tool. A fejlesztett panelt kell a PICkit2 -val összekötni (ld ábra az Uart tool ablakon), be kell állítani a sebességet és a tápellátást (formátum fix 8n1) azátn connect. Amit küldeni szeretnél, a 4 mező egyikébe kell beírni és a hozzá tartozó Send gombot megnyomni. A vett adat az ablak közepén látható.

köszi a tippet, ezt délután ki is próbálom

Sajnos az derült ki, hogy mégsem az adapterrel volt a probléma. Megnéztem a pickit program usart moduljával hogy mi jön ki a pic-ből és ugyan azt látta ez a progi is amit a terminál programom a gépen, vagyis, hogy az elküldött "n" betű helyett hexa B7 jön ki. Ránéztem a vonalra logikai analizátorral is, ennek a képernyő képét csatoltam. Ez is érdekes nekem ez úgy néz ki mintha jönne a start bit majd 11101101 (hexa ED) és a stop bit (ami itt nem látszik egyértelműen mert az is 1), na most ez se nem B7 se nem 6E ami az n betű hexa kódja, szóval mostmár egyáltalán nem értem az egészet. Ezt most egy 16F877 produkálta de korábban próbáltam egy 874-essel is az meg b betűket küldött elvileg. Az egészhez még hozzá tartozik az a történek is, hogy egy fordulatszám szabályzós projekten dolgozok ahol a fordulatszám mérést CCP capture móddal oldom meg, korábban csináltam már ilyet és működött, most viszont mérem vele egy motor fordulatszámát ami kb 3600 rpm, helyette 1300 körüli értékeket mér, ha növelem a fordulatot először lecsökken ez az érték 1100 körülire, hapedig csökkentem a fordulatot egyszer csak ugrás szerűen 900 körüli értékre csökken, majd ha tovább csökkentem 700 körülire. (ilyenkor foroghat a motor kb 1000-es fordulaton).
Szóval valami itt nagyon fura, próbáltam a pic-et kicserélni, próbáltam a kvarcot is, de semmi változás, a kódot már szétbombáztam, a számítások jók, az értékek jól adódnak át változók között, debugger módban nézve minden úgy működik ahogy kell aztán a valóságban meg mégsem

Az UART a legalacsonyabb helyiértékkel kezdi az adást. Startbit, bit0, bit1, .. bit6, bit7, Stopbit.
9600 Baud sebesség mellett egy karakter (10 bit) adása lezajlik 1.0417 ms alatt. Ezt nem szabad 250us -vel mintavételezni. Végez el a mérést nagyobb mintavételi frekvenciával. Az UART Baud Rate beállításánál lesz a probléma. A szimulátor csak regiszter szinten mutatja a működését, az időzítéseket nem kezeli.

csatoltam az usartos forrás fájlt amit használok. Én adatlapban megnéztem a baud rate beállításhoz a dolgokat az alapján ez jó kéne legyen. A main függvényemben van egy USARTInit(9600); hívás utána meg USARTWriteChar("n");

Le kellene ellenőrizni, hogy a oszci megfelelő frekin fut-e. LED-el is lehet indikálni megközelítően...
Az "n"-t nem úgy kell megadni, hogy 'n' ? C18-ban így kell... Ellenőrizd le, hogy a megfelelő érték kerül-e be a TXREG-be elküldés előtt (SIM)!

Tegyél fel egy PICkit2 Logikai analizátor regisztrátumot legalább 1MHz mintavételi frekvenciával.

valóban ha 'n'-ként írom akkor tényleg egy n betű jön át. így már sikerült átküldenek 1 karaktert, olyan stringet amiben 1 karakter volt, illetve 1 jegyű számot, de ha már kettőt akartam küldeni akkor rosszul jöttek át az adatok. Megpróbáltam usart_pic16.c ben a karakter kiírós függvénynél betenni egy 10ms-es delayt (kisebb is elég lesz) a TXREG-be írás után és így már átjönnek a stringek és az intek. Valószínűleg hamarabb rakott a program új értéket a TXREG-be mint hogy áttolta volna a teljes üzenetet, és ígyvagy felülírta az előző értéket és onnantól már azokat a biteket küldte vagy pedig újrakezdte a küldést az új értékkel így egybecsúsztak a csomagok és a PC oldal rosszul dolgozta fel. Az egészben a fura az, hogy korábban nekem működött ez az USART library időzítés nélkül.

Csak az az érdekes a dologban, hogy pollingolással figyelve van, hogy a TXREG értéke fel lett-e használva így nem is lehetne felülírni az új értékkel a TXREG-ben várakozót, de mégis megtörténik


ha ki van kommentelve a delay akkor nem jól mennek át az adatok, ha nincs akkor minden fasza. Csak ez a delayezés marhára nem elegáns

Igen, ennek elvileg jónak kéne lennie, legalább is ami a karakterek jóságát illeti. Az más kérdés, hogy milyen sokat várakozik itt a program, ennyit a lib-ekről...
Esetleg próbáld a TXIF-et kicserélni TRMT-re!

Ha még jól emlékszem a Microchip C fordítóinak agyamentségére:
A C ugyan a tömb nevét és 0. elemének kezdőcímét egyenrangúként engedi kezelni, de ezek a fordítók jobban szeretik az &tömb[0] alakot.

próbáltam a TRMT-t is már de ugyan az volt mint a TXIF-el. szerintem ez nem a lib hibája, ha megírnám magam akkor is ez lenne szerintem

Nem a TRMT a lib hibája, hanem a módszer...
Ilyen hibával még nem találkoztam, valami nagyon nem jól van ott, mert ennek működnie kéne, ez egy pofon egyszerű folyamat. Másrészt az USB konverterre gondolnék, meg kéne már nézned 1M mintavételezéssel mi jön ki a PIC-ből, mert így csak egyhelyben toporogsz...!

Sziasztok!

Kísérletezgetek most egy GSM modullal ami USB-RS232 kábellel terminálból vezérelve működik is kiválóan. Azonban a cél az, hogy μcu-val használjam. A gond az, hogy ha arról hajtom meg akkor nem reagál semmire pedig megnéztem és bájtra ugyanaz megy ki UART-on mint ami terminálból. Lehet gond, hogy gagyi sipex márkájú RS232 meghajtót használok? Eredeti MAX232-vel gyári ajánlás szerinti kapcsolásban megoldódna a probléma szerintetek? A PC-vel egyébként hibátlanul kommunikál a board-om csak a modullal nem akar valamiért. Baud rate beállítások is rendben vannak.

Az USB <-> RS-232 átalakitó 0...5V <-> +12...-12V logikai szintáttevést végez (lásd MAX232 adatlap).
Szerinted ebben az esetben melyik félnek (GSM modul vagy uC) van szüksége 12V-ra?

Szerintem ebben az esetben a Maestro 20-as GSM modulnak (vagy nevezzük modemnek, de lényegében ugyanaz).

Köszönöm hogy mondtál tipust, én meg magamtól nem tudom kitalálni hogy mi van előtted az asztalon...
A mellékelt adatlap szerint vagy nem használod a gyárilag mellé adott "Y" kábelt és 15 pólusú csatlakozónak elegé specifikus bekötése van, vagy csak egyszerűen a 9 pólusú Sub-D csatlakozót használod ahol viszont a GSM modem DCE-ként viselkedik és nem DTE-ként. Azaz kell egy null modem (vagy meg kell cseréni a Rx és Tx pontokat). Ezeket leszámitva szerint Flow control nem kell, azaz valószinűleg mást nem is kellene bekötni a kommunikációhoz.