Sliter sedan några veckor och försöker förstå och bygga rs232 interface mellan pic och dator.
Jag får numera ut data från datorn men får inte in data i datorn.
Andvänder en operationsförstärkare:
http://www.elfa.se/elfa-bin/dyndok.pl?l ... 218511.htm
För att göra signalen från picen till 9V istället för 5V (ska det verkligen vara 9V eller är min dator trasig?)
Hursomhelst, när jag skickar data till datorn så kommer den i retur på andra kabeln men liksom shiftad till mellan gnd och runt 20V, ser undeligt ut.
Vad gör jag för förmodligen uppenbart fel?
Skulle det vara bättre att köpa en sådan här trots att picen ska kunna prata rs232?
http://www.elfa.se/pdf/73/737/07375389.pdf
RS232 kommunikation med en PIC18F442
> Andvänder en operationsförstärkare... för att göra signalen...
Sluta direkt med det innan du har sönder något.
> Vad gör jag för förmodligen uppenbart fel?
Se ovan. Och Ivarssons svar...
> trots att picen ska kunna prata rs232?
Jag vet inte var du har sett det, men det är hur som
helst ett missförstått. Det finns *ingen* PIC som klarar
av att köra RS232 direkt.
Jag kan skicka över 2 st MAX232 inkl 8 st 1uF kondingar för 50:-
jämt inkl frakt och allt. Maila vid intresse...
(Och det ska vara RS232, med stort "RS"
)
Sluta direkt med det innan du har sönder något.
> Vad gör jag för förmodligen uppenbart fel?
Se ovan. Och Ivarssons svar...
> trots att picen ska kunna prata rs232?
Jag vet inte var du har sett det, men det är hur som
helst ett missförstått. Det finns *ingen* PIC som klarar
av att köra RS232 direkt.
Jag kan skicka över 2 st MAX232 inkl 8 st 1uF kondingar för 50:-
jämt inkl frakt och allt. Maila vid intresse...
(Och det ska vara RS232, med stort "RS"
)
I nödfall kan du köra med denna, kolla i vänstra nedre hörnet.
http://www.olimex.com/dev/images/avr-mt128-sch.gif
5 resistorer, 2 dioder, 2 transistorer och en kondensator.
http://www.olimex.com/dev/images/avr-mt128-sch.gif
5 resistorer, 2 dioder, 2 transistorer och en kondensator.
Tack för erbjudandet men jag har ELFA i kurvan 30 minters promenad bort eller så tar jag bussen och är där på 10 minuter, dessutom har de flera till synes lämpliga chip i lager.
Uppskattar omtanken
Det står inte att man kan driva direkt, jag har fel igen för jag antog att den skulle kunna driva direkt faktiskt.
Däremot står det "this mode would typically be used in RS-232 systems." på sidan 174 (på plats 16.2.2) i:
http://ww1.microchip.com/downloads/en/D ... 39564c.pdf
Kapitel 16 är om USART, någon skillnad jämfört med UART?
Blir lite fundersam när man ser att MAX232 andvänder operationsförstärkare de med eller betyder symbolen något annat?
http://www.elfa.se/elfa-bin/dyndok.pl?dok=2013395.htm
Uppskattar omtanken
Det står inte att man kan driva direkt, jag har fel igen för jag antog att den skulle kunna driva direkt faktiskt.
Däremot står det "this mode would typically be used in RS-232 systems." på sidan 174 (på plats 16.2.2) i:
http://ww1.microchip.com/downloads/en/D ... 39564c.pdf
Kapitel 16 är om USART, någon skillnad jämfört med UART?
Blir lite fundersam när man ser att MAX232 andvänder operationsförstärkare de med eller betyder symbolen något annat?
http://www.elfa.se/elfa-bin/dyndok.pl?dok=2013395.htm
> eller betyder symbolen något annat?
Ja. En "driver" eller "buffer" eller vad man vill kalla det.
> "this mode would typically be used in RS-232 systems."
"This mode" syftar på "Asynchronous Reception". USART modulen kan ju
även köra synkront, vilket är något annat.
RS232 är en *elektriskt* standard, inget annat. D.v.s hur en "etta"
respektive en "nolla" ska representeras rent elektriskt. Sedan kan kan
köra olika kommunikationsprotokoll över RS232, som t.ex de vanliga
U(S)ART baserade varianterna, 8/7 bitar O/E/N paritet, 1/2 stoppbitar
o.s.v, men det är ingenting som RS232 standarden i sig bryr sig om.
Om du t.ex skulle koppla ihop två st PICs över ett kort avstånd så
går bra med vanliga TTL/CMOS nivåer. Då kör du alltså inte alls RS232,
även om din programvara till PIC'arna ser *exakt* likadan ut...
> Tack för erbjudandet men jag har ELFA i kurvan 30 minters promenad bort...
OK, måste du ha dom *idag* så är det väl OK att betala lite extra.
Ja. En "driver" eller "buffer" eller vad man vill kalla det.
> "this mode would typically be used in RS-232 systems."
"This mode" syftar på "Asynchronous Reception". USART modulen kan ju
även köra synkront, vilket är något annat.
RS232 är en *elektriskt* standard, inget annat. D.v.s hur en "etta"
respektive en "nolla" ska representeras rent elektriskt. Sedan kan kan
köra olika kommunikationsprotokoll över RS232, som t.ex de vanliga
U(S)ART baserade varianterna, 8/7 bitar O/E/N paritet, 1/2 stoppbitar
o.s.v, men det är ingenting som RS232 standarden i sig bryr sig om.
Om du t.ex skulle koppla ihop två st PICs över ett kort avstånd så
går bra med vanliga TTL/CMOS nivåer. Då kör du alltså inte alls RS232,
även om din programvara till PIC'arna ser *exakt* likadan ut...
> Tack för erbjudandet men jag har ELFA i kurvan 30 minters promenad bort...
OK, måste du ha dom *idag* så är det väl OK att betala lite extra.
> Vet inte hur många det skulle bli i så fall, antar att du har ett minilager hemma?
Kollade just, och det är just nu ca 80 st satspackade två och två tillsammans
med 8 st 1uF kondingar...
> Du råkar inte ha pic:ar också?
http://www.jescab.se/Prod_PIC.html
Kollade just, och det är just nu ca 80 st satspackade två och två tillsammans
med 8 st 1uF kondingar...
> Du råkar inte ha pic:ar också?
http://www.jescab.se/Prod_PIC.html
80 räcker gott och väl
MAX232 inköpt och fungerar, får skämmas för att jag spegelvände kopplingarna till kontakten till serieporten, därav div mysko mätvärden häromdagen, någon som vill se?
Sparade mätningarna från oscilloskopet.
Nu har jag fått kommunikationen att fungera när det gäller att skicka enstaka byte fram och tillbaka
Det är dock något som är märkligt, jag bara läser av mottagarbufferten utan att kolla några flaggor.
Bara:
movff RCREG, PortB
Det är allt och det fungerar men då lär man väl få felaktiga värden medans värdet mottages och inte är klart.
Min egentliga kod såg ut såhär:
btfsc PIR1, 5 ; RCIF ; See if a whole byte is recieved
movff RCREG, PortB
btfsc PIR1, 5 ; RCIF ; See if a whole byte is recieved
bcf PIR1, 5 ; RCIF ; Reset bit for the next byte.
Men det gör bara att inget läggs på PortB
Så det fungerar men ändå inte.
Kollar jag fel flagga eller så?
Tycker det verkar vara lämplig info på sid 175 tabell 16-5 i databladet:
http://ww1.microchip.com/downloads/en/D ... 39564c.pdf
Till en annan sak, när man skickar en fil med hyperterminal så kommer först en serie tecken som jag inte vet vad de betyder och inte kan svara på, ska man göra något för att hyperterminal ska skicka såsom när man kör över en nollmodemskabel?
MAX232 inköpt och fungerar, får skämmas för att jag spegelvände kopplingarna till kontakten till serieporten, därav div mysko mätvärden häromdagen, någon som vill se?
Sparade mätningarna från oscilloskopet.
Nu har jag fått kommunikationen att fungera när det gäller att skicka enstaka byte fram och tillbaka
Det är dock något som är märkligt, jag bara läser av mottagarbufferten utan att kolla några flaggor.
Bara:
movff RCREG, PortB
Det är allt och det fungerar men då lär man väl få felaktiga värden medans värdet mottages och inte är klart.
Min egentliga kod såg ut såhär:
btfsc PIR1, 5 ; RCIF ; See if a whole byte is recieved
movff RCREG, PortB
btfsc PIR1, 5 ; RCIF ; See if a whole byte is recieved
bcf PIR1, 5 ; RCIF ; Reset bit for the next byte.
Men det gör bara att inget läggs på PortB
Så det fungerar men ändå inte.
Kollar jag fel flagga eller så?
Tycker det verkar vara lämplig info på sid 175 tabell 16-5 i databladet:
http://ww1.microchip.com/downloads/en/D ... 39564c.pdf
Till en annan sak, när man skickar en fil med hyperterminal så kommer först en serie tecken som jag inte vet vad de betyder och inte kan svara på, ska man göra något för att hyperterminal ska skicka såsom när man kör över en nollmodemskabel?
Hyperterminal är rent allmänt ett trassligt verktyg.
Vad är du ska göra ? Skicka "en fil" ??
Och vad är det för fil ? Hur många tecken kommer
det före dina egna data ? Det skulle kunna vara
vara UTF-headern som många MS program lägger till
till textfiler, 2-4 tecken ca brukar det vara. T.ex "EF BB BF"
för UTF-8.
Normalt så skriver man väl något enkelt i t.ex
VB som läser filen och ser till att allt skickas på rätt sätt.
RCREG bör/ska du läsa när de andra flaggorna
visar att USART'en har mottagit ett komplett tecken.
Enklast gör man detta genom att låta RCIF trigga ett
interrupt där du sedan gör vad som behöver göras.
Pollning fungerar också, men koden blir inte lika "snygg".
Vad är du ska göra ? Skicka "en fil" ??
Och vad är det för fil ? Hur många tecken kommer
det före dina egna data ? Det skulle kunna vara
vara UTF-headern som många MS program lägger till
till textfiler, 2-4 tecken ca brukar det vara. T.ex "EF BB BF"
för UTF-8.
Normalt så skriver man väl något enkelt i t.ex
VB som läser filen och ser till att allt skickas på rätt sätt.
RCREG bör/ska du läsa när de andra flaggorna
visar att USART'en har mottagit ett komplett tecken.
Enklast gör man detta genom att låta RCIF trigga ett
interrupt där du sedan gör vad som behöver göras.
Pollning fungerar också, men koden blir inte lika "snygg".
-
JimmyAndersson
- Inlägg: 26586
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Tack för RealTerm
Behöver skicka filer med data in i picen, det är styrdata som sedan ska ut på pinnarna.
Storlekarna varierar men minst något tusental bytes vanligen och flera MB ibland, ska inte spara utan bara andvända datan o sedan kasta bort den.
Värsta är att datan inte "går åt" i jämn takt så någon form av flödesreglering antar jag blir nödvändig.
Tyvärr ser jag bara att det kommer en massa data i oscilloskopet och efter ett tag är det stopp, inget mer kommer, antar att det betyder att den väntar på något.
Sitter just nu och försöker lista ut vad som gör att mottagningen låser sig i picen när man skickar mer än 2 tecken i taget.
Tror det är OERR som blir satt pga overrun men är inte säker.
Helst slipper jag interrupts.
VB har jag tyvärr inte men TurboC har jag.
Kanske kan bli att skriva något där i fast det är ju bra om man kan köra med något vanligt program som redan finns för jag är inte särskilt bra på C och vet inte hur man lägger något på sereporten i C
Behöver skicka filer med data in i picen, det är styrdata som sedan ska ut på pinnarna.
Storlekarna varierar men minst något tusental bytes vanligen och flera MB ibland, ska inte spara utan bara andvända datan o sedan kasta bort den.
Värsta är att datan inte "går åt" i jämn takt så någon form av flödesreglering antar jag blir nödvändig.
Tyvärr ser jag bara att det kommer en massa data i oscilloskopet och efter ett tag är det stopp, inget mer kommer, antar att det betyder att den väntar på något.
Sitter just nu och försöker lista ut vad som gör att mottagningen låser sig i picen när man skickar mer än 2 tecken i taget.
Tror det är OERR som blir satt pga overrun men är inte säker.
Helst slipper jag interrupts.
VB har jag tyvärr inte men TurboC har jag.
Kanske kan bli att skriva något där i fast det är ju bra om man kan köra med något vanligt program som redan finns för jag är inte särskilt bra på C och vet inte hur man lägger något på sereporten i C
