transferring word array to another pic

[garret]

hi all, I think this one is truly nuts and bolts. 16f877a to 16f877a using pbp. I would like someone to suggest the simplest code to transfer a 12 element word array from one pic to the other using serout/ serin.
-break the elements into high and low bytes?
-loop the serout so that transmit is one element at a time?

how about serout porte.0,t9600,'the whole bloody word array'

any pre-existing snippets of code would be really nice to read. And i do thank everyone in advance...Garret

[Melanie]

Take a look at...

http://www.picbasic.co.uk/forum/showthread.php?t=544

Then for simplicity (based on a 12 element word array) try...



For CounterA=0 to 23
Serout porte.0,t9600,MyWordArray.Lowbyte(CounterA)
Next CounterA

Personally I wouldn't ever do that... preferring always to send my Serial Data as ASCII alphanumerics preceeded with a Lead-in and Qualifier and similarly properly Terminated... but good Serial Comms practice is an endless story...

[mister_e]

MyArray var word[12]
Loop var byte

start:
for loop=0 to 11
serout PORTE.0,T9600,[MyArray[Loop]]
next


same for receiver... i guess.

I also agree with the Melanie's suggestion. Well if it's working, it's working ;)

[garret]

wow melanie, how nice it is to see a photo of you after all this time. You look rather excellent. A good photographer and a good subject always tends to impress others....
I find the syntax you came up with to be very hard to fix in my mind. You are stepping through the array on lowbytes of half words...Mind you if it works...! My brain would never come up with such syntax....
Do you think that serin in the same manner will work?

For CounterA=0 to 23
Serin porte.0,t9600,MyWordArray.Lowbyte(CounterA)
Next CounterA

could it possibly transfer the array keeping the right elements in order.

Could you throw me a single line of how you would code your serout with all the accoutrements that you spoke of.

Mister E...thanxs...i am in montreal as well.....

[Melanie]

Thanks for the compliment... I'm told I look better in real-life than in the photo...



CommsPort var PortE.0

SEROUT CommsPort,t9600,[REP $00\16,13,10,"Z-"]
CheckDigit=0
For CounterA=0 to 8
CheckDigit=CheckDigit ^ MyWordArray.Lowbyte(CounterA)
SEROUT CommsPort,t9600,[HEX2 MywordArray.Lowbyte(CounterA)]
Next CounterA
SEROUT CommsPort,t9600,[HEX2 CheckDigit,13,10]

Quickly thrown together...

The first SEROUT flushes any trash out of the receiving buffer (if there is one) and provides a unique qualifier to lock up on which is unlike any possible Data combination... If you're transmitting by wireless, that Lead-In also wakes up the Data-Slicer.

The For-Next Loop transmits your Data Array and doubles in creating a CheckDigit...

The last SEROUT transmits the CheckDigit (so the receiver can verify a good Data packet has been received) and terminates the packet with a Return/Line-Feed combination (again forcing any remaining Data out of the Receivers buffers if Hardware USARTS are being employed).

The bonus here is that you can "break-in" to the transmission and make a connection say to Hyperterminal and "see" the transmitted packet and check each Byte manually if you need to do any Debugging. You don't see the Lead-In, and each packet of Data is on a unique Line on the display on it's own, prefixed with a 'Z-'.

The receiver captures the string of Hex (you don't need to bother capturing the CR/LF - 13/10 - at the end), verifies good Data against the Transmitted CheckDigit and reconstructs the Word Array from the Hex. Simple and Safe.

[garret]

ahhhh!

Your solution as well... You've given me a chunk to work on.
I have an interrupt on the receiving pic producing the raster for a led matrix display. I'm 20mhz running tmr0 at prescaler of 256...so....i beleive the raster (interrupt) is running at 1220 hz.

It looks like your solution should allow the interrupts to continue even through the core of your code. Do you think i should expect any loss of serout-serin timing in the array...

[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