transferring word array to another pic

[Melanie]

If you're playing with interrupts or have any other timing critical functions on the receiver then lose the Serial Comms. Pipe the async into your USART pin and poll the Receive Register Flag when you have free time. Sitting in a SERIN loop waiting for Data is the equivallent of watching paint dry.

If you need to generate a background Pulse for whatever purpose, you could always get that from your PICs Harware PWM Port (if it has one). If the PIC is refreshing or multiplexing an LED array, then the byte-by-byte Hardware receive method is the best way to go, otherwise there will be a momentary flicker on the display as the data is received.

[Dwayne]

Your picture is hot enough...

Melanie>>I'm told I look better in real-life than in the photo...<<

If that is so....I am moving to your country...:}

Dwayne

[garret]

yup...i need the interrupt to multiplex the array. the whole array serin's at more than the interrupt interval and yes...there's a small flicker

building my own usart code feels like an oncoming nightmare...unless you tell me otherwise....

what do think about using serin2 and implementing the flowpin. Will that walk me through the array input even if it is broken by an interrupt? it also allows for a higher baud.... Does the flowpin go down between items?....

...garret

[Melanie]

Your picture is hot enough...

...and there I was deliberating over that piccy or the one in the tight-leather catsuit with thigh-high boots and chromed spikey heels (work tax-deductable as they have low ESD)...

You're caught between a rock and a hard-place... if your interrupt has priority over PICBasic then you WILL lose bit synchronisation and your incomming Data stream will corrupt. If PICBasic has priority over your interrupts then your display will flicker. Take your choice.

The professional option is Hardware USART. It's quite simple really... poll for an incomming byte... if it's there, go grab and store into a buffer, if not, go to your LED routine. At 9600 baud, a byte will arrive every 1mS (give or take), plenty of time to grab and do something with it... you only need to devote a few uS to this task every millisecond... the rest of the time is yours to do with as you wish... with software async input, you need to devote 100% of that time to bit-bang the result.

[garret]

good morning mel and all,

So....setup the harware usart using pbp hserout command...done....

initiate usart receiver...... but don't use pbp hserin command...right?
It would seem that using the hserin command takes me back to software control and timeout periods.

So....i poll pir1<5> to check for reception myself
read the rcreg into a variable
and go back to poll

voila..... it's the question of not using pbp hserin that i'm after. yes...no....?

[Melanie]

We're just talking RECEIVE here...

Avoid SERIN, SERIN2, HSERIN, DEBUGIN etc

all these end up catching Data out of your control...

Refer to the PICs Datasheet as to which flags within which registers pop-up anouncing that goodies have arrived.

The nice thing is that there's a small buffer in the PICs USART... if your program is a bit lazy picking up data, then no worries, it just holds it for you and stacks another byte behind...

[garret]

thanx for everything mel. I'm off to jam it together.

-first i'm going to try and poll for an arrival and then use hserin...knowing that there is something there...shouldn't lose any time.
-Second, i'll try polling and then go straight to the registers and transfer in...no hserin. Mind you here there is no control on assignment to variables and control bytes. I liked what you showed me the other day with an ending confirmation byte...
-third...everything working well....place the usart reception bit into interrupt status and run it as an interrupt....

mel...u'sart the bestest...garret