Question about ARRAYWRITE

[circuitpro]

I have a project in which I'm gathering data from several sources, and need to pass it to another processor when polled. I anticipate the need to save/buffer these messages until I'm polled by the host and ARRAYWRITE looks like a perfect answer. I just started reading the posts about this command today, and am a little confused. I guess you can have multiple ARRAYWRITEs going at the same time because you are allowed to give them different names. Where is this data stored? RAM? EEPROM? How many ARRAYWRITEs can you have going simultaneously? How do you know the limitations of the space available? (I'm using an 18F6722for this project).

Thanks,
Len

[HenrikOlsson]

Hi,
You can have as many ARRAYWRITE in your program as the program memory of your device allows but as with any other command only one is executing at the time.

The data is stored in the specified and previously declared array, ie in RAM.


myFirstArray VAR BYTE[30]
mySecondArray VAR BYTE[30]
ARRAYWRITE myFirstArray, ["This is a test with Arraywrite"]
ARRAYWRITE mySecondArray, ["This is also a test", 10, 13]

Now the first "location" of myFirstArray contains "T", the second "location" contains "h" and so on. Again, remember that they execute sequentially - first myFirstArray is loaded THEN mySecondArray is loaded.

If your trying to load the array with data coming in over the USART or something like that I don't think ARRAWRITE is the way to do it. Sure, you can specify where in the array to start writing but since you still have to keep a "pointer" of "where you are" in the array you might as well fill the array "manually".

If you have several "streams" of data coming in simultanously from several devices you'll have to use a PIC with several USARTs. There's no way of capturing several "serial inputs" simultanoulsy with the SERIN/SERIN2/DEBUGIN commands.

/Henrik.

[aratti]

With one USART and DT interrupt and using a RS485 ring, you can connect several devices at a pretty high speed. Look the data sheet for 75176 (there are several others, but I use this one) for more detail.

Al.

[HenrikOlsson]

Hi Al,
Yes, that's possible, as long as you have control over the transmitting devices or if you don't care if you miss some data by cycling thru the devices listening to one device at a time. If they are self contained units sending data on their own, at will, then it's going to be tricky. If I've missed your point please enlighten me :-)

Now, the OP doesn't say how the transmitting devices works and/or if he has "control" over how they works. Hopefully a multidrop network can be implemented in which case one USART would be enough.

/Henrik.

[aratti]

Yes, that's possible, as long as you have control over the transmitting devices

Yes, Henrik the control is necessary, devices must tx only on request, without it the OP will not achieve much.

Al.

[circuitpro]

Thanks for the info! This particular application is a polled system, and my local PIC needs to process data and format the output into a predefined 'message'. Then when I am polled, I need to forward the data on to the host. I think ARRAYWRITE is the way to go. I was thinking about using an eeprom, but this is definately faster. I am not sure of the time between the polls yet though, and am concerned my data will back up, so need some message buffer space. Thanks very much for your help.

[circuitpro]

One interesting thing...

It seems that ARRAYWRITE does not work with indexed variables.

ARRAYWRITE MSG ["VALUE: ",DEC TMR[X]]

I'm just copying the value of TMR[X] to another variable first for now. Is this a bug, or just not accounted for or ??? Great command nonetheless.

[Darrel Taylor]

It seems that ARRAYWRITE does not work with indexed variables.
ARRAYWRITE MSG ["VALUE: ",DEC TMR[X]]

The statement is missing a comma after MSG, but otherwise ... it should work.
ARRAYWRITE MSG, ["VALUE: ",DEC TMR[X]]

[circuitpro]

Sorry, I was 'winging it' by memory from work. The comma was there, and still no go. I'll keep trying things as I'd really like to use this command. :(

[circuitpro]

I've been looking at this all day, and it just doesn't work:





'PIC18F6722
OSC 40
ARRAYSIZE CON 20
DJAM CON %01110111
ACK CON $06
COMMAND VAR BYTE[20]
MESSAGE VAR BYTE[20]

LOOP1:
ARRAYWRITE MESSAGE,[HEX ACK," ",BIN DJAM]
ARRAYREAD MESSAGE, [COMMAND]
DEBUG STR COMMAND,10,13
ARRAYWRITE MESSAGE,[REP 0\ARRAYSIZE]
PAUSE 1000
GOTO LOOP1

OUTPUT:
61110111

If I just say "HEX ACK" it produces 61110111 (no space as I specified). If I try to use "HEX2 ACK", it doesn't show the first value OR the space, just the binary number! I need to write some rather complicated structured messages and store them, but I've found that

1) IN NO CASE will ARRAYWRITE write more than two items... (if there is more, they just don't show). The exact same structure prints fine using DEBUG.

For example: ARRAYWRITE MESSAGE, ["DJ_TMR",DEC X,":",DEC DJ_TMR[X]] will only show the first two values... DJ_TMR, and DEC X - nothing further.

2) ARRAYWRITE won't work with indexed variables.

All efforts done in PBP 2.60A. If anyone can tell me what I'm doing wrong, I would be most grateful!

L.

[Darrel Taylor]

Try it like this.



'pic18f6722
osc 40
arraysize con 20
djam con %01110111
ack con $06
command var byte[20]
message var byte[20]

loop1:
Arraywrite message,[hex ack," ",bin djam,0]
debug str message,10,13
arraywrite message,[rep 0\arraysize]
pause 1000
goto loop1

[circuitpro]

ok, but what is that doing? Once the array is written, and presumably saved for some time, don't I have to use ARRAYREAD to read it back into a variable to then use it? You are showing me that the message is proper, but I'm not proving a READ. WHAT IS THAT 0 FOR???????

[Darrel Taylor]

ok, but what is that doing?
It's writing string data to an Array, then sending it out using DEBUG.


Once the array is written, and presumably saved for some time, don't I have to use ARRAYREAD to read it back into a variable to then use it?
No, once it's in the array it's ready to send.
You would only need to use ARRAYREAD if string data had been received.


WHAT IS THAT 0 FOR???????
The 0 terminates the string.
When using DEC, HEX, BIN etc. The length of the string is not constant, and you have to mark the end so PBP can find it.
The STR operator in the DEBUG statement will stop sending data from the array when it encounters a 0.

[circuitpro]

ouch, that hurts!