RS232 -> Visual basic

Op 17 november 2012 15:31:05 schreef bramvr:
hoe moet je 0x30 gewoon hrsout variabele *30 klinkt misschien dom

Dat dacht ik al, je ontvangt hex. Je andere terminalprogramma zal je wel ingesteld hebben dat die hex moet omzetten en in de VB niet.

Twee optie
Of je los past het aan in picbasic
Of je past het aan in VB zodat die hex naar dec omzet.

Zoek hoe je hex omzet naar dec en je bent er. Is weer hele algemene informatie die echt voor het oprapen ligt.

PS
Kan je helaas niet helpen met picbasic, gebruik geen pic en ook geen basic.

Hex en decimaal zijn hetzelfde... (alleen een kwestie van notatie.)
Je bedoelt hex naar ascii.

ik heb ter straks nog een even getest en wat me opviel was dat de cijfers die in het getal zaten wel weergegeven worden maar niet correct. Ik zal een voorbeeltje geven om te verduidelijken. Ik meet om de 2 sec de temperatuur en ik zend deze door bv 18.63°C stuur ik door als 1863 deze komt zo binnen 86 --> 2 sec --> 863 --> 2sec --> 3 --> 2 sec --> 1 --> ....... de volgorde en de samenstelling is altijd anders ik heb 1 keer de juiste temperatuur in mijn vb programma gezien maar dit zo altijd moeten zijn :p In docklight is dit altijd correct dus het ligt niet aan de pic of communicatie maar aan het vb programma. Heeft dit iets te maken met die 0x01 en die 0x30?

lijkt erop of dat je je buffer verkeerd uitleest.

stuur je ook een regeleinde mee? (komt het in docklight netjes op een nieuwe regel?)

probeer eens serialport.readline ipv serialport.readexisting

kijk ook even hier... voor visualbasic...

http://www.vbib.be/index.php?/topic/9375-hoe-een-leddisplay-aansturen/

probeer eens serialport.readline ipv serialport.readexisting

Ik heb dit geprobeerd maar dan krijg ik helemaal niets meer.

Ik heb deze gewoon terug gezet en ik merk op dat de eerste keer dat ik een waarde door zend wel correct is maar de 2de waarde loopt het fout.

[Bericht gewijzigd door bramvr op (34%)]

Op 18 november 2012 19:26:15 schreef Progger:
lijkt erop of dat je je buffer verkeerd uitleest.

heb je al gecontroleerd of er regeleindes meekomen?

bij doclight gaan de waardes als volgt 178617861786... als de temperatuur 17.86 is.

geen regeleindes dus.

pas je codes eens aan: voeg een CRLF toe aan je bericht --> chr(13)+chr(10)

je hebt namelijk 2 opties:
-of de tijd tussen 2 berichten is zo lang dat er een time-out plaats vind.
-of er is een bericht scheiding (delimiter)

als je dat niet doet kan de pc niet weten hoeveel bytes er uit de buffer gelezen moeten worden. als je altijd 4 bytes leest kan het ook mis gaan als je ooit een byte verliest.
http://mc-computing.com/languages/CR_LF.htm

Ik heb dit ingevoegd bij mijn µC maar helaas nog niet juist :-( . Soms krijg ik nu zelfs geen waarde te zien. In het begin is het altijd juist maar dan niet meer. Ik heb ook al geprobeerd om alleen de temperatuur te verzenden + $0A en ook één keer met temperatuur + $0D maar dit helpt ook niet :-( .

HRSOut Dec Temp, $0D0A

tja, $0D0A is natuurlijk ook niet hetzelfde als $0D en $0A.

probeer eens de volgende code in je pic zonder iets anders:


For SPBRG=1 To 255
pause 1
HSerOut ["SPBRG=",Dec SPBRG,13,10] ' message
Next

als je dat in docklight binnen krijgt, dan kun je naar VB door gaan.

als dat werkt dan ga je iets nuttigs verzenden.

Wat moet ik dan binnen krijgen?

Moet de bautrate etc. bij in het programma of enkel dat van jou?

sorry, dat van de baurate moet je natuurlijk niet weghalen, dat was onduidelijk van mij.

er moet dan komen:

SPBRG=1
SPBRG=2
SPBRG=3
...
SPBRG=255

met telkens een seconde tussen de berichten

Moet dat van die 1 seconde niet delayms 1000 zijn in plaats van pause 1?

Op 17 november 2012 17:07:14 schreef Arco:
Hex en decimaal zijn hetzelfde... (alleen een kwestie van notatie.)
Je bedoelt hex naar ascii.

Nee hoor, en ze zijn niet hetzelfde rekenstelsel.

Hex(hexdecimaal) = 0 t/m f (0 t/m 15 in dec)
Dec(decimaal) = 0 t/m 9

Hexadecimaal betekend letterlijk 16, decimaal betekend letterlijk 10. Op die manier kan je niet vergissen.

Ik heb dit programma en ik krijg dit in docklight. (ik kijk bij ascii) ik werk met een r232 --> usb converter ik weet niet of dit er iets mee te maken heeft.

Device = 16F887
@CONFIG_REQ
@__CONFIG _CONFIG1, DEBUG_OFF & LVP_OFF & FCMEN_OFF & IESO_OFF & BOR_on & CPD_OFF & CP_OFF & MCLRE_OFF & PWRTE_ON & WDT_OFF & HS_OSC
@__CONFIG _CONFIG2, WRT_OFF & BOR21V 
 
XTAL 20
ALL_DIGITAL TRUE 
HSERIAL_BAUD = 19200       ' baud rate is 19200
HSERIAL_RCSTA = %10010000  ' laat de USART voortdurend ontvangen
HSERIAL_TXSTA = %00100000  ' zorgt dat de USART kan verzenden 
HSERIAL_CLEAR = On 

For SPBRG=1 To 255
DelayMS 1000
HSerOut ["SPBRG=",Dec SPBRG,13,10] ' message
Next

http://www.uploadarchief.net/files/download/docklight2111.ajpg.jpg

Moet je niet inverterend verzenden naar je MAX232?

Uit de help van proton:

You should remember that when using a line transceiver such as the MAX232, the serial mode (polarity) is inverted in the process of converting the signal levels, however, if using the direct connection, the mode is untouched. This is the single most common cause of errors when connecting serial devices, therefore you must make allowances for this within your software.

raar, ik zie netjes:

..rotzooi..<CR><LF>
SPBRG=15<CR><LF>
SPBRG=16..rotzooi...

dus soms komt het door, en daarna komt het niet door.

dus de polariteit zal wel goed zitten, maar toon eens een plaatje van je print. ziet er naar uit dat je erg veel storing oppikt.

Maar hoe komt het dan dat als ik een waarde naar docklight stuur deze wel mooi aankomt (zonder storingen). Kan het zijn dat ik mijn configates van mijn µC met dat programma van jou een beetje moet aanpassen? Of zit de bautrate niet goed ik heb deze maar willekeurig gekozen.

Op 21 november 2012 20:08:46 schreef bramvr:
http://www.uploadarchief.net/files/download/docklight2111.ajpg.jpg

vind je dit zonder storingen? van de ~300 karakters zijn er 15 goed.

baudrate maakt niet enorm uit, als ze maar op pc en PIC hetzelfde zijn.

ze moeten wel uit het onderstaande lijstje komen, veel hardware kan geen andere snelheden aan die hieronder staan.

lager is beter. dat heeft te maken met het delen van de klok. je hebt altijd een afwijking, en hoe lager de snelheid hoe hoger de afwijking mag zijn voordat het misgaat.

wat voor kristal heb je? hoe ziet je print eruit?

300 <- héél vroeger gingen ze nog langzamer
600
1200
2400
4800 <- minimum wat tegenwoordig gebruikt word (NMEA houd dit aan)
9600 <- meeste gebruikt, veel GPS ondersteunen dit ook wel
19200 <- veel microcontrollers kunnen dit zonder veel problemen.
38400

Ik bedoel als ik gewoon de temperatuur naar docklight stuur is deze altijd goed. Enkel met dat programmaatje van jou gaat het mis. Ik gebruik een kristal van 20MHz en ik heb nu als bautrate 19200. En foto van de print nemen is nu momenteel niet mogelijk mijn excuses.

hmm, das apart..

dus bij jouw eigen programma staat er altijd 178617861786 zonder rare tekens? ook niet als je hem een tijdje laat lopen?

en dan gebruik je deze code?

Op 11 november 2012 16:25:25 schreef bramvr:

HRSOUT Dec Temp, Dec Ingangen, Dec Uitgangen

De variabelen zijn wel word variabelen

het kan zijn omdat mijn voorbeeld HSerOut ipv HRSOUT gebruikte.
wat gebeurt er als je alleen in jouw code dit aanpast:

HRSOUT Dec Temp, Dec Ingangen, Dec Uitgangen
wordt:

HRSOUT Dec Temp, Dec Ingangen, Dec Uitgangen,13,10

Ik krijg nu dit met dit stukje code. Maar helaas in vb blijft het probleem aanhouden. Ik heb ook dat stukje code van jou aangepast naar HRSOUT maar de rare dingen blijven.

HRSOut Dec Temp,13,10

http://www.uploadarchief.net/files/download/docklight2611.jpg

Het is precies dat de buffer nog niet leeg is na de eerste keer.

Heeft niemand hier een oplossing voor?