Mega64 [bascom] rs232 . Źle wysyłane znaki .

Witam. Mam mege64 i chcę sobie wysłać za jej pomocą pewne paczki danych do kompa.
Jednak coś mi to za bardzo nie chciało chodzić . Więc wrzuciłem do procka taki program :


I włączyłem sobie na komputerze terminal rs232 w bascomie z ustawieniami COM3 ,
Baudrate 4800
parity none
databits 8
stopbits 1



I w oknie terminalu z otrzymanych danych otrzymałem coś takiego :


Zamiast samych liter 'z' otrzymywałem również ' ( w trakcie odbierania bajtów nie było nic wysyłane do procesora , po prostu leciała sobie pętla do ... loop .


fusy procesora to
hFuse D1
lFuse 54
eFuse FF

Nie mam hardwarowego rs-a więc pracuję na przejściówce rs232 - USB , bazującej na procesorze atmega8 . Zwierałem na niej rxd i txd i przez komputer wysyłałem z prędkością 4800 , 100 bajtów ('s') i zawsze wszystkie były odbierane poprawnie .
Linie xd i txd nie są podłączone pod żadne inne urządzenia. które mogły by zakłucać te dane . Długość kabla to około 1 m .

Prosiłbym o jakieś sugestie dlaczego mega wstawia te ' .
Pozdrawiam .

Dodałem znaczniki [code]
[zumek]

Witam,

ja się w ogóle nie dziwię, że masz taki efekt, ja gdybym był na miejscu procesora i gdybym otrzymał taki kod to też bym zwariował na maxa

Na prawdę jeszcze czegoś takiego to nie widziałem, żeby :

1. nie skorzystać ze sprzętowego UARTA - gotowca w bascomie
2. nie skorzystać z pięknych buforów cyklicznych - gotowca w bascomie

tylko w zamian za to napisać jakąś własną (sorki) tragiczną pseudo obsługę RS232 z wykorzystaniem przerwania a na dodatek w tym przerwaniu dokonywać wysyłania poleceniem PRINT !

toż to musi nie działać

czy tak na prawdę trudno znaleźć jakieś przykłady w necie, na elektrodzie - ba - po co szukać w necie - w samym helpie Bascoma są gotowe i piękne - działające przykłady jak skorzystać z wbudowanej sprzętowej obsługi RS232

nie wiem po raz już który - ale ok jeszcze raz przypomnę -

spójrz sobie do helpa Bascoma i zapoznaj się z poleceniem



to przestaniesz myśleć o pisaniu obsługi do tych przerwań w Bascomie.

Poza tym, weź się za jakąś normalną standardową prędkość czyli 9600 a nie jakieś 100, 600, 1200 itp

Po doczytaniu n/t Config Serialin dużo ci się rozjaśni i zobaczysz, że zrobienie tak prostej obsługi RS232 w Bascomie to totalny pikuś i do napisania w kilku linijkach kodu

powodzenia

Witam. Jak już pisałem , nie odbieram znaków na procesorze jedyne co ten program robi to ma wysłać 'z' z procesora do komputera co sekundę . Także serialin raczej nie ma nic wspólnego z tym , wiem że jest to źle napisane tylko już nie chciało mi się tego usuwać.
Z tego co wyczytałem w instrukcji bascoma to do wysyłania znaków przez uart wykorzystuje się właśnie print .
Co do prędkości to pracowałem na 9600 , ale jak zobaczyłem że coś nie halo ( na programie napisanym w delphi ) to nabazgrałem ten kod na szybko w 2 minutki żeby sprawdzić czy transmisja sama w sobie jest dobra .

mirekk36 wrote:

Na prawdę jeszcze czegoś takiego to nie widziałem, żeby :

1. nie skorzystać ze sprzętowego UARTA - gotowca w bascomie

COM1 to niestety sprzętowy port komunikacyjny.
Tak samo jak COM2. Choć z nim to już trzeba nieco pokombinować z OPEN i kanałami by coś przez niego przesłać.

mirekk36 wrote:

2. nie skorzystać z pięknych buforów cyklicznych - gotowca w bascomie

Przy wysyłaniu nie jest to tak istotne jak przy odbieraniu. Ponadto kolega ma polecenie Wait 1 które wykona się pomiędzy kolejnymi poleceniami PRINT, a ramka transmisyjna przy prędkości 4800 nie jest aż tak długa.

Trzeba przeanalizować, który bit (albo bity) jest zawsze gubiony.

Witam. Jak kolega poradził , przerobiłem mój terminal aby wyświetlał w postaci binarnej i pojawia się coś takiego :


01111010 - z - poprawne
11111010 - ' - błąd

Czego używasz jako konwertera TTL-RS232 po stronie ATMegi? Jeśli MAX232 to jakie ma pojemności w przetwornicy?

Istnieje jeszcze jedna możliwość - przypuszczalnie. Błędne taktowanie w przejściówce USB-RS232! Loopback (czyli połączenie RXD i TXD) będzie działał poprawnie, bo oba zegary taktujące transmisję (część nadawcza i odbiorcza) są te same - pochodzą przecież z jednego generatora.
Przy połączeniu z innym urządzeniem zegary taktujące mogą być już bardziej rozsynchronizowane. W sumie widać to na załączonym obrazku, gdzie po 7 bitach - z czego ostatnie to jedynki - następuje przekłamanie. Tak jakby bit stopu wchodził na 8 bit danych.
Proponuję jeszcze dwa testy. Najpierw nadawaj CHR(85) i zrzut ekranu. Potem nadawaj CHR(170) i znów zrzut ekranu.

Czy w przejściówce USB jest rezonator kwarcowy? Jaką ma częstotliwość?

Używam tej przejściówki .
https://www.elektroda.pl/rtvforum/topic827115.html
I wychodzi na to że to jednak wina przejściówki .
Char 170


Char 85



Tak jest rezonator w przejściówce , 12 Mhz , fusy zaprogramowane , inaczej by nie ruszył w ogóle z obsługą USB i przesyłem informacji (rxd i txd zwarte ) .

Z jednej strony w przejściówce jest błąd 0,15% (rezonator 12MHz), a po stronie ATMegi też 0,2% (8MHz) co niestety skumuluje się.

Możesz spróbować w Twoim programie zwiększyć nieco baud rate ponad standardowe 4800 - na przykład 4815 - by próbować się wstrzelić w przejściówkę. Problemu to nie rozwiąże, ale będzie wiadomo czy to właśnie jest kumulacja obu błędów.

Rozwiązanie będzie chyba tylko jedno: przejściówka na układach FTDI.

Raczej skołuję jakąś inną przejściówkę :/ bo to nie jest rozwiązanie . Sprawdziłem na podanym 4815 i rzeczywiście jest trochę lepiej .

ta przejściówka do której podałeś link - powinna być zrobiona na procku zasilanym z 3,3V - czy tak masz?

jeśli tak? to jak masz zasilany procek, który nadawał te literki z ??? czy przypadkiem nie +5V ??? i przy okazji jakieś po drodze niedopasowanie sygnałów?

czy może jednak procek przejściówki zasilany jest z +5V i z tego powodu zakłócenia pojawiają się przez USB ? może ?

ja już dawno i wiele razy pisałem w temacie tej przejściówki, że generalnie jednak już ją od dawna odradzam ..... i teraz wszystko robię na FT232RL . Dzięki temu wiem zawsze na 100000%, że transmisja od strony sprzętowej jest wolna od jakichkolwiek wad.

a dzięki temu każde moje urządzonko które wykorzystuje FT232RL oraz po stronie PC'ta także mój program w Delphi - zawsze idealnie się komunikuje.

Posprawdzaj więc to co mówiłem na początku - te zasilania i dopasowania poziomów - albo jak sam piszesz - zrób porządną przejścióweczkę

układ FT232RL jest o tyle wdzięczny, że nie potrzebuje ŻADNYCH elementów zewnętrznych (no poza kondkami filtrującymi ale to oczywiste). Dzięki temu zrobienie na nim przejściówki to mega PIKUŚ ..... no może poza tym, że trza polutować SMD.

Witam . Co ciekawe przy większych prędkościach (115200) błąd jest rzadszy .
Przejściówka zasilana z 5 V USB przez 2 diody o spadku 1,5 V na każdej .
Nie pomyślałem jednak o stronie megi 64 i z stamtąd idzie prosto 5 V na przejściówkę.

Takie SMD to nie problem ;p . Atmega64 jest na wyższym poziomie trudności , ale też nie mam z nią problemów , jak na razie nie udało mi się dobrać do nec-a (nie pamiętam jakiego ) ale to już jest większy problem bo mamy po ~40 nóżek na każdej stronie i to w minimalnych odstępach . Załamałem się przy nim lekko i zrezygnowałem po wcześniejszym brutalnym lutowaniu . (był to szrot do poćwiczenia bez większej wartości więc pomyślałem czemu by nie spróbować ).