Is there a way to do a serial "pass through" ?

Don M · 2013-12-02 15:41

I have the Prop Plug USB connected to pins 30 & 31 and I have a bluetooth module connected to pins 6 & 7.

Lets say I wanted to utilize a setup program from the manufacturer made for the bluetooth module that communicates via the pins on the module that are connected to the Prop's pins 6 & 7 just for the purpose of making some changes to the module.

Is there a way using FDS to pass the data coming in on pin 31 to be passed on to pin 7 and data from pin 6 passed on to pin 30? It's @ 19.2K.

Any suggestions ?

I hope this makes sense the way I explained it here.

kwinn · 2013-12-02 15:51

A short PASM program loop that copies the state of pin 31 to 7 and pin 6 to 30.

Don M · 2013-12-02 15:53

Any example code?

PASM is out of my league.

Phil Pilgrim (PhiPi) · 2013-12-02 15:57

Connect P7 to P31 with a 4.7K resistor, and do the same with P6 and P30. As long as these pins are not being driven by a program, the pass-thru will happen automatically. Whenever a program drives the xmt pins, no pass-thru will take place.

-Phil

Duane Degn · 2013-12-02 16:03

How critical is the timing? Could you just transmit each byte as it's received?

I wrote a simple bridge program for the SayIt module to this sort of thing. If timing isn't critical, then a simple Spin loop would work. The PASM version should be pretty simple too but I don't have an example ready.

kuroneko · 2013-12-02 16:05

This thread may be of interest too: http://forums.parallax.com/showthread.php/127001-resolved-puzzle-pass-through.

Ariba · 2013-12-02 16:13

Don M wrote: »

Any example code?

PASM is out of my league.

This untested code should work:

PUB start
  cognew(@PassThru,0)

DAT
          org
          mov  dira,outmsk
PassThru  test pin31,ina  wc   'Pin31->Pin7
          muxc outa,pin7
          test pin6,ina   wc   'Pin6->Pin30
          muxc outa,pin30
          jmp  #PassThru       '5cy = 4MHz fs

pin6      long 1<<6
pin7      long 1<<7
pin30     long 1<<30
pin31     long 1<<31
outmsk    long 1<<30 + 1<<7

Andy

kwinn · 2013-12-02 16:16

Don M wrote: »

Any example code?

PASM is out of my league.

Phil's idea would work and Kuroneko's post shows how it's done in pasm. If you want I could write the pasm code for you.

Don M · 2013-12-02 18:00

Phil Pilgrim (PhiPi) wrote: »

Connect P7 to P31 with a 4.7K resistor, and do the same with P6 and P30. As long as these pins are not being driven by a program, the pass-thru will happen automatically. Whenever a program drives the xmt pins, no pass-thru will take place.

-Phil

So for instance when I want to communicate to the module via the external program I would just load a blank program to the Prop?

Or just stop the FDS methods for the serial terminal and the module?

Would the pins on the Prop just go to high impedence and then not interfere?

Don M · 2013-12-02 18:04

Ariba wrote: »

This untested code should work:

PUB start
  cognew(@PassThru,0)

DAT
          org
          mov  dira,outmsk
PassThru  test pin31,ina  wc   'Pin31->Pin7
          muxc outa,pin7
          test pin6,ina   wc   'Pin6->Pin30
          muxc outa,pin30
          jmp  #PassThru       '5cy = 4MHz fs

pin6      long 1<<6
pin7      long 1<<7
pin30     long 1<<30
pin31     long 1<<31
outmsk    long 1<<30 + 1<<7

Andy

Andy I tried your code and I don't get anything. I put the Saleae logic analyzer on the pins and there isn't any data at all.

Here is what I loaded onto the Prop:


CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

PUB start
  cognew(@PassThru,0)

DAT
          org
          mov  dira,outmsk
PassThru  test pin31,ina  wc   'Pin31->Pin7
          muxc outa,pin7
          test pin6,ina   wc   'Pin6->Pin30
          muxc outa,pin30
          jmp  #PassThru       '5cy = 4MHz fs

pin6      long 1<<6
pin7      long 1<<7
pin30     long 1<<30
pin31     long 1<<31
outmsk    long 1<<30 + 1<<7

Am I doing something wrong?

Don M · 2013-12-02 18:05

kwinn wrote: »

Phil's idea would work and Kuroneko's post shows how it's done in pasm. If you want I could write the pasm code for you.

kwinn- By all means I'd love to see your solution.

kuroneko · 2013-12-02 18:11

Don M wrote: »

Am I doing something wrong?

PassThru isn't a valid entry point for cognew. Either define a label for mov dira,outmsk and use this or pass @PassThru-4 to cognew.

Don M · 2013-12-02 18:15

kuroneko wrote: »

PassThru isn't a valid entry point for cognew. Either define a label for mov dira,outmsk and use this or pass @PassThru-4 to cognew.

kuroneko- Thanks! That works.

CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

PUB start
  cognew(@PassThru-4,0)

DAT
          org
          mov  dira,outmsk
PassThru  test pin31,ina  wc   'Pin31->Pin7
          muxc outa,pin7
          test pin6,ina   wc   'Pin6->Pin30
          muxc outa,pin30
          jmp  #PassThru       '5cy = 4MHz fs

pin6      long 1<<6
pin7      long 1<<7
pin30     long 1<<30
pin31     long 1<<31
outmsk    long 1<<30 + 1<<7

Ariba · 2013-12-02 18:35

Yes, sorry I have it first posted without setting DIRA. When I added the dira setting later, I forget to adjust the cognew pointer.

Don M · 2013-12-03 09:15

Duane Degn wrote: »

How critical is the timing? Could you just transmit each byte as it's received?

I wrote a simple bridge program for the SayIt module to this sort of thing. If timing isn't critical, then a simple Spin loop would work. The PASM version should be pretty simple too but I don't have an example ready.

Duane- I tried your method but couldn't get it to work. Maybe 19.2K is too fast for Spin trying to keep up with?

Duane Degn · 2013-12-03 09:29

Don M wrote: »

Duane- I tried your method but couldn't get it to work. Maybe 19.2K is too fast for Spin trying to keep up with?

I just looked at the program again and I see it doesn't pass on nul characters. The SayIt GUI never transmits a nul and I was having trouble with the FDS treating an inactive line as if it were receiving nul characters since FDS doesn't check for framing errors.

It's also possible the buffers weren't large enough.

If I were to write the program again, I'd use two copies of Tracy Allen's four port serial driver. If you try this, make sure and make a small change to the object and save as another name. It wouldn't work correctly if you just use two instances.

If you want to go this route and need assistance let me know and I'll be glad to help.

Peter Jakacki · 2013-12-03 09:34

Phil Pilgrim (PhiPi) wrote: »

Connect P7 to P31 with a 4.7K resistor, and do the same with P6 and P30. As long as these pins are not being driven by a program, the pass-thru will happen automatically. Whenever a program drives the xmt pins, no pass-thru will take place.

-Phil

Well Phil, it looks like your idea is wrong, it is too simple and as we know on this forum many seem to offer or look for a complicated solution. This is a solution I have used for pass-through on some designs and it just works, but once again, it's too simple.

Phil Pilgrim (PhiPi) · 2013-12-03 10:00

Peter Jakacki wrote:

Well Phil, it looks like your idea is wrong, it is too simple ...

LOL! 'Reminds me of the time a local timber-frame-home company called. They were using a CNC mill to notch the ends of their timbers and needed a way to support the other end of the beam as it was being milled. What they asked for was a powered platform that would track the motions of the milling machine bed. What I suggested instead was a rope running through an overhead pulley and tied to the timber on one end, with a counterweight on the other. I never heard back from them.

-Phil

cavelamb · 2013-12-03 18:27

Ariba wrote: »

This untested code should work:

Andy

Always!

kwinn · 2013-12-03 18:54

Don M wrote: »

kwinn- By all means I'd love to see your solution.

I was thinking of something similar to what Andy posted although I doubt mine would have been quite that good. The only addition I was thinking of was a way to stop and start it from spin.

Don M · 2013-12-03 20:08

kwinn wrote: »

The only addition I was thinking of was a way to stop and start it from spin.

You read my mind. I was thinking last night how that might be done.

kwinn · 2013-12-03 21:19

Have the pasm program check a byte in hub ram and stop/start based on the contents. Could even get fancy and have it control multiple pass thrus based on the value.

Ariba · 2013-12-04 01:08

Or the easy way:

VAR
  long  ThruCog

PUB Main
  ThruCog := cognew(@PassThru-4,0)   'start PassThru
  ...
  cogstop(ThruCog)                 'stop PassThru

Andy

Don M · 2013-12-04 03:51

Can FDS share the same pins (30, 31) with the PassThru cog?

Thinking out loud here- if I have a main method that is working with FDS in a "menu" type setup and let's say it is running in a loop and I defined a particular character to start the PassThru. When it sees that character the PassThru starts in another cog while still in the main method FDS is watching for a "cogstop" character that I also defined.

When the PassThru starts I'd disable PST and run the external program to communicate with the module. When done with that I'd enable PST to send the "PassThru cogstop" command.

Sounds confusing I know.....

kwinn · 2013-12-04 15:15

Ariba wrote: »

Or the easy way:

VAR
  long  ThruCog

PUB Main
  ThruCog := cognew(@PassThru-4,0)   'start PassThru
  ...
  cogstop(ThruCog)                 'stop PassThru

Andy

Definitely easier but it takes time to restart it. I was thinking of something that could be stopped and restarted quickly.

Is there a way to do a serial "pass through" ?

Comments