Can PicBasic support 56700 serial baud?

[dw_picbasic]

Hi gang,
I have a project to talk to a device at 56700,N,8,1,CTS,RTS

I do not have PB-Pro and don't have the money for the upgrade as of yet.

All I need to do for sending data into the device is to send a bit stream of 3Fh, followed by 41h.
This initiates a query to the device which responds with 4 hex bytes.

I think I can simulate the 3Fh + 41h bit-stream using a 4Mhz crystal/resonator.
But then how do I capture the returned data?
I'm not sure if a pic running at 4Meg is going to be processing fast enough to decode 4 bytes at 56700 baud.

I only have to query the device every few seconds.

Perhaps I could use a chip that which would capture and store the 4 bytes and then have the PIC pull them off and reset the chip for the next send?

Perhaps you already have a sample "PicBasic" code that can work at 56700 baud?

Yes, I know, I should bite the bullet and get upgrade to Pro, but for now the piggy bank is empty.

Your suggestions greatly appreciated!!
Thanks,
dw_picbasic

[skimask]

Hi gang,
I have a project to talk to a device at 56700,N,8,1,CTS,RTS

I do not have PB-Pro and don't have the money for the upgrade as of yet.

All I need to do for sending data into the device is to send a bit stream of 3Fh, followed by 41h.
This initiates a query to the device which responds with 4 hex bytes.

I think I can simulate the 3Fh + 41h bit-stream using a 4Mhz crystal/resonator.
But then how do I capture the returned data?
I'm not sure if a pic running at 4Meg is going to be processing fast enough to decode 4 bytes at 56700 baud.

I only have to query the device every few seconds.

Perhaps I could use a chip that which would capture and store the 4 bytes and then have the PIC pull them off and reset the chip for the next send?

Perhaps you already have a sample "PicBasic" code that can work at 56700 baud?

Yes, I know, I should bite the bullet and get upgrade to Pro, but for now the piggy bank is empty.

Your suggestions greatly appreciated!!
Thanks,
dw_picbasic

Think about this:
In your program, you define the osc for 4 mhz and write the program for 9600 baud in your serial routines. BUT...
In reality, you clock the PIC at 24mhz. The compiler think it's running at 4mhz and sets all of it's delay loops according to that, BUT...you're running 6 times faster. 9600 baud @ 4mhz = 57600 baud @ 24mhz.

I don't have the PBC manual on hand at the moment, I don't remember which commands PBP supports which PBC doesn't support.
In the end, you could always use the hardware UART and peek/poke commands.

And it would help to know which PIC you're using...

[dw_picbasic]

Hi Skimask,

It sounds probable.
I guess I could at least try it.
Perhaps with a PIC18F1220 which has an internal clock and can run up to 40Mhz.

Maybe I could monitor a 56700 signal out of my PC with a scope and try to adjust the clock offset parameter.

Or I guess it would be more reliable if I used a resonator.

[mister_e]

If your PIC have an internal USART, sure it can work. I suggest you to download the PicMultiCalc and look what happen with the error % with different crystal speed
http://www.mister-e.org/pages/utilitiespag.html

@ 4MHz it's not going to be really accurate...

[dw_picbasic]

Thanks Steve,

I will check that out.
I spent some time this weekend monitoring the bit streams between my pc and the device with a scope to both confirm the bit width is ~ 17uS, which it should be for 56.7k, and also to get a look at the bit patterns of returned info.

Then I did a simple....

Main:
bo = 1
high 5
bo = 1
low 5
goto main

To see what bit width I would see from a 4Mhz clock.
And this came out to around 50uS.
Perhaps if I removed the 'bo = 1's It would speed up a little, but no where near the speed needed. In order to read 56.7
Looking in PBC.INC, it looks to me like 9600 baud is right at the timing limit with a 4Mhz clock. And since 56.7 is such a large jump, I think now a 40Meg chip slowed down to around 24Mhz might be the easiest way to do it using the built in SERIN / SEROUT commands.

Anyway, I also checked out maxim's MAX3110E SPI/rs232 chip, and requested a couple of samples. I built up a schematic for it, and when they come in, I should be right on it.
If I get this working I'll post the schematic and code.

However, the reallity of my project is that I am only sending 2 bytes to the device, and these always the same. And the device is sending 4 bites back.
I think with a little work, I can replicate the command bit stream with a 20Meg crystal. Decoding the incoming bytes will be the hard part.
After sweating over that approach, I'll be eager to play with the Max chip.

[skimask]

Thanks Steve,

I will check that out.
I spent some time this weekend monitoring the bit streams between my pc and the device with a scope to both confirm the bit width is ~ 17uS, which it should be for 56.7k, and also to get a look at the bit patterns of returned info.

Then I did a simple....

Main:
bo = 1
high 5
bo = 1
low 5
goto main

To see what bit width I would see from a 4Mhz clock.
And this came out to around 50uS.
Perhaps if I removed the 'bo = 1's It would speed up a little, but no where near the speed needed. In order to read 56.7
Looking in PBC.INC, it looks to me like 9600 baud is right at the timing limit with a 4Mhz clock. And since 56.7 is such a large jump, I think now a 40Meg chip slowed down to around 24Mhz might be the easiest way to do it using the built in SERIN / SEROUT commands.

Anyway, I also checked out maxim's MAX3110E SPI/rs232 chip, and requested a couple of samples. I built up a schematic for it, and when they come in, I should be right on it.
If I get this working I'll post the schematic and code.

However, the reallity of my project is that I am only sending 2 bytes to the device, and these always the same. And the device is sending 4 bites back.
I think with a little work, I can replicate the command bit stream with a 20Meg crystal. Decoding the incoming bytes will be the hard part.
After sweating over that approach, I'll be eager to play with the Max chip.

The 18F1220 already has a built-in UART that can easily be read using peeks and pokes. You don't need to 'bit-bang' serial with this PIC. At 57,600 baud, with continuous data streaming, each complete byte will arrive at about once every 173us. Just configure the onchip baud rate generator to set that up for you. With 173us per byte, that's plenty of time to check the RX port for a byte, get the byte, put it away somewhere, and do a bunch of other stuff, even at 4mhz, although you do have to use the high speed BRG in the 16 bit mode and even then you'll be about 2% high. Go to an 8mhz oscillator and you're less than 1% off the target rate.
I guess what I'm saying is that either I don't get what you're doing (and I think I get it), or you're making this WAY harder on yourself than you have to.