PDA

View Full Version : MIKROBASIC Soft_Uart to PICBASIC SEIRIN2?



Corbet
- 18th September 2011, 03:30
I am trying to use Mikrobasic and PicBasic to communicate between chips. My receiver is using SERIN2 porta.1,84,10,comfail,[wait ("@"),STR t1pulse\6] but my sender is using MIKROBASIC SOFT_UART and I can't seem to get them to communicate properly. If anyone has any experience with this let me know how to fix it. The receiver is receiving values but they aren't right at all. How do I get these to communicate properly. I need to send an array of 6 values between 0 and 180. Any help is appreciated.

HenrikOlsson
- 18th September 2011, 10:39
Hi,

Are you sure the sender and reciever are using the same polarity? Mode 84 in PBP means 9600baud, true. Are you sure that sender is sending the data true and not inverted? 16468 is the mode for 9600baud, inverted - if in doubt, give that a try.

/Henrik.

Corbet
- 18th September 2011, 14:28
Yup, first thing I made sure of. 9600 Baud, 8N1 true. I think it's just not sending the data the same because of the type. When I send a number to the SERIN2 statement like I outlined in the first post, how does the statement expect the data to come? what I mean is does it expect 3 ascii values for each digit individually to come like if i send 128 will it expect to get, 1 in ascii followed by 2 in ascii followed by 8 in ascii? or does it receive the binary value of 128 and convert to STR?

HenrikOlsson
- 18th September 2011, 15:04
Hi,
The line

SERIN2 porta.1,84,10,comfail,[wait ("@"),STR t1pulse\6]

Will recieve up to 6 bytes and store each byte in the t1pulse array. In this case it expects each value as one byte, not the ASCII representation of the value (for that you use the DEC modifier). If the sending device sends the "raw" value 128 you'll get 128 in t1pulse[0]. If it sends the value in ASCII you'll get 49 in t1pulse[0] because 49 is the ASCII code for '1'.

I hope that makes sense.

/Henrik.

Corbet
- 18th September 2011, 18:49
I wrote the received values to to eeprom and read them and with 110,110,110,110,110,110 sent, it received 6E,AE,6E,EE,6E,EE. These are 110,174,110,238,110,238.

The similarity is in the binary,
Hex DEC bin
6E 110 0110 1110
AE 174 1010 1110
EE 238 1110 1110

the last 4 bits are all the same and the first 4 arent too different. I will try changing the sender type to unsigned instead of integer and see what changes.

mister_e
- 18th September 2011, 19:21
I may miss the point but... why having a Sender code written in MikroBasic and a receiver in PicBasic?

Corbet
- 18th September 2011, 19:32
Because Mikrobasic has inverse trig functions that I need but doesn't have a good way to do a pulsout that I need so I'm using puslout in PICbasic to run servos and using mikrobasic on another chip to do calculations and sending them via serial to the servo controllers written in picbasic to do the puslout.

cncmachineguy
- 19th September 2011, 01:32
Hi Corbet, What are you controlling if I may ask? Reading accel's and gyro's? adjusting servo's based on the sensors?

Corbet
- 19th September 2011, 03:04
I have 18 servoes on a 3DOF hexapod robot. I have 3 pic16f84's running 6 servos each and a pic16f684 doing the calculations and sending the servo angles to the 84's The 84s are using PICBasic and the 684 is using Mikrobasic. My reasons are outlined in the above posts so I'm not gonna go into detail.
I built the whole thing for under $200 servos (cheap servos) and all and I don't want to take the easy way out by buying all the electronics so I have a radioshack board all soldered up and before you start picking my board apart I'll tell you it worked just fine using SEROUT2 to SERIN2 so its not the board :)

Its just the 2 compilers are not handling the information the same.

cncmachineguy
- 19th September 2011, 04:34
Oh that sounds awesome!! Sorry if I came off like I was gonna make any hardware suggestions. I was fishing hoping you were working on a balance project and wanted to pick your brain about what to do with the raw data.

Btw, anyone could plug ready made stuff together, the true pride comes from building it yourself- as you are doing. Just my humble opinion.

Love to see some pics if you care to share :)

c_moore
- 19th September 2011, 11:01
Hi Corbet,

Do you hve the 2 pics physically connected together? Or are they communication over RF?

Bruce
- 19th September 2011, 12:07
I will try changing the sender type to unsigned instead of integer
If the sender PIC array is type int, it's probably 16-bit or word sized. Try setting it to unsigned byte or char type.

dhouston
- 19th September 2011, 12:28
IIRC, Mikrobasic has 8 bit signed & unsigned short integers as well as longs. Unsigned should work.

Corbet
- 19th September 2011, 16:01
I've had a couple people on here tell me I should write an article about my project and I will once I get some of the major issues worked out and I will include pictures and I'll be sure to put a link on here to it.
I switched the type to byte but it just seems like they aren't syncing properly. In picbasic does the SERIN2 expect a start and stop bit after every 8 bits or does it expect a start bit then the 48 data bits and then a stop bit? Because MIKROBASIC sends a byte at a time so it sends start and stop bits after every bit.

Corbet
- 19th September 2011, 16:02
Oops I meant after every byte in the last sentence.

Bruce
- 19th September 2011, 16:12
All packets will include a start bit, 8 data bits, and the stop bit. You might have better luck if you increase (or get rid of) the timeout period.

cncmachineguy
- 19th September 2011, 16:42
Prolly just adding noise here, But how does the "sender" know the "receiver" is ready and able to receive?

dhouston
- 19th September 2011, 17:12
If mikrobasic allows, you might try increasing the time between bytes.

Corbet
- 19th September 2011, 20:13
Ok we made some progress. I added a 500us pause between bytes and its getting the values now.
But now only the first chip is getting the serial. The 3 slave chips are on seperate lines. The first chip is getting values but the second 2 aren't getting any. My transmit code is below


sub procedure Send()
porta.0 = 1

portc.2 = 1
error1 = Soft_UART_Init(PORTC,1, 5, 9600, 0)
delay_ms(3)
soft_uart_write("@")
for i = 0 to 5
soft_uart_write(Coxa[i])
delay_us(500)
next i
portc.2 = 0

portc.1 = 1
error1 = Soft_UART_Init(PORTC,2, 4, 9600, 0)
delay_ms(3)
soft_uart_write("@")
for i = 0 to 5
soft_uart_write(Thigh[i])
delay_us(500)
next i
portc.1 = 0
portc.0 = 1
error1 = Soft_UART_Init(PORTC,0, 3, 9600, 0)
delay_ms(3)
soft_uart_write("@")
for i = 0 to 5
soft_uart_write(Tibia[i])
delay_us(500)
next i
portc.0 = 0

porta.0 = 0
return
end sub



my receiver waits for the @ symbol so that is why its sent first.

Corbet
- 19th September 2011, 20:58
Ok I found several errors in the last one I posted so here is the newest code revision


sub procedure Send()
porta.0 = 1

portc.2 = 1
error1 = Soft_UART_Init(PORTC,0, 5, 9600, 0)
delay_ms(3)
soft_uart_write("@")
for i = 0 to 5
delay_us(300)
soft_uart_write(Coxa[i])
next i
portc.2 = 0

portc.1 = 1
error1 = Soft_UART_Init(PORTC,2, 4, 9600, 0)
delay_ms(3)
soft_uart_write("@")
for i = 0 to 5
delay_us(300)
soft_uart_write(Thigh[i])
next i
portc.1 = 0
portc.0 = 1
error1 = Soft_UART_Init(PORTC,1, 3, 9600, 0)
delay_ms(3)
soft_uart_write("@")
for i = 0 to 5
delay_us(300)
soft_uart_write(Tibia[i])
next i
portc.0 = 0

porta.0 = 0
return
end sub