Communication problem

Started by Georges May 9, 2004
I have experience with the Baisicx 24.

But now, I am trying a brand nex BX-24 with the 2.1 Compiler.

I get the right "Hello Message" but It is imposible to donwload a
new program or stop the Basicx !

I try the rescue function many times without result.
Any idea the help me ?

Thanks for all,

Georges



Georges, I think you will find it's something with your serial cable or connections,
it's probably not the BX-24 chip. If you are using a development board
make sure the ATN jumper is installed. Also, try the ATN diagnostics
on pin4 of the BX-24 chip.

Chris
----- Original Message -----
From: "Georges" <>
To: <>
Sent: Sunday, May 09, 2004 2:07 PM
Subject: [BasicX] Communication problem > I have experience with the Baisicx 24.
>
> But now, I am trying a brand nex BX-24 with the 2.1 Compiler.
>
> I get the right "Hello Message" but It is imposible to donwload a
> new program or stop the Basicx !
>
> I try the rescue function many times without result.
> Any idea the help me ?
>
> Thanks for all,
>
> Georges >
> Yahoo! Groups Links >
>




I have a program 99% operational. There is a routine which parses
serial input data and if it looks correct skips to "DATA_OK: and
writes this data to EEPROM and then sends a response to the PC

If I use the Debug.print statements everything is fine but slow. If I
remark out the debug.print statement then remove the "'"s from the
Call PutQueue routines, I get a value of 243 returned to the PC
instead of "6". This runs much faster but the new values never get
written to the EEPROM. Why 243 and why the write to EEPROM fails is
strange especially when the serial output is after the write.

The output queue is set to 11 bytes.
=================== Code Snip ====================
DATA_ERROR:
Debug.Print "ER" & " " & CStr(byDataArray(0))
'OutData(0) = 15 'NAK
'Call PutQueue(OutComm, OutData, 1)
Exit Sub
DATA_OK:
Call PutEEPROM(lngEEPromAddress, byteDataArray, NUMBER_DATA_BYTES)
Debug.Print "OK" & CStr(lngEEPromAddress)
'OutData(0) = 6 'CByte(6) 'ACK
'Call PutQueue(OutComm, OutData, 1)
End Sub





Well no takers on this question?

How about I break it down into a smaller bite or at least rephrase it.

1) The sub-routine prior to this part of the code works perfect if I
use the Debug.Print reply method. The values (64 of them) are written
to the EEPROM without a problem.

2) If I remark out the Debug.Print and use the Call PutQueue routine
nothing is written to the EEPROM and a value of 243 is sent to the PC.
I removed the data array and tried using a byte variable
called "Value" the results are the same. NOTE: The starting address
(lngEEPromAddress) is well above the end of the program address.

Call PutEEPROM(lngEEPromAddress, byteDataArray, NUMBER_DATA_BYTES)
Debug.Print "OK" & CStr(lngEEPromAddress)
'Value = 6 'ACK
'Call PutQueue(OutComm, Value, 1)

I can leave the Debug.Print in and this progam will work fine albeit
slower that using the Call PutQueue but I would like to know what is
creating the symptom.

Thanks in advance to the group! --- In , "wurlitzer28" <craig.whitley@a...>
wrote:
>
> I have a program 99% operational. There is a routine which parses
> serial input data and if it looks correct skips to "DATA_OK: and
> writes this data to EEPROM and then sends a response to the PC
>
> If I use the Debug.print statements everything is fine but slow. If
I
> remark out the debug.print statement then remove the "'"s from the
> Call PutQueue routines, I get a value of 243 returned to the PC
> instead of "6". This runs much faster but the new values never get
> written to the EEPROM. Why 243 and why the write to EEPROM fails is
> strange especially when the serial output is after the write.
>
> The output queue is set to 11 bytes.
> =================== Code Snip ====================
> DATA_ERROR:
> Debug.Print "ER" & " " & CStr(byDataArray(0))
> 'OutData(0) = 15 'NAK
> 'Call PutQueue(OutComm, OutData, 1)
> Exit Sub
> DATA_OK:
> Call PutEEPROM(lngEEPromAddress, byteDataArray, NUMBER_DATA_BYTES)
> Debug.Print "OK" & CStr(lngEEPromAddress)
> 'OutData(0) = 6 'CByte(6) 'ACK
> 'Call PutQueue(OutComm, OutData, 1)
> End Sub





--- In , "wurlitzer28" <craig.whitley@a...>
wrote:
> Well no takers on this question?

I looked over the code that you provided the first time and nothing
came to mind. Attempting a diagnosis by looking at a small piece of
a system is difficult at best.

One thing that comes to mind is that if data is not removed from a
queue, PutQueue() will eventually not return because it will be
waiting for space to become available.

As a side note, having nothing to do with the question at hand, it is
almost never necessary to use a goto/label in a language that has
modern control structures as does BasicX. Likewise, but somewhat
less so, for Exit Sub. I am not one who is pedantic about GOTO-less
programming. Rather, I reserve their use for those situations where
the alternative is messier, more convoluted or otherwise less
palatable. It's difficult to tell without seeing the surrounding
code but I would guess that an If..Then would suffice nicely.





Thanks for you reply Don. I have attached the entire sub. The program
is ready to ship minus this problem.

Some of the lines are rather long and wrap funny.

byComboGroupNumber can be 0 to 2
lngPistonNumber can be 0 to 87
These 2 variable above help form the starting address for the write
to EEPROM.

As you can see I have tried a few variations for populating the
output in the Call PutQueue routine. I have used a small array and
also tried a single byte.

This routine is only entered if the input queue has the proper number
of bytes. It has worked very well and in fact when using the
debug.print method of reply to the PC I have never received the "ER"
message.

Each message contains the 4 initial data bytes plus 64 bytes of data
to be written to EEPROM. I have verified that all the possible values
of group number and piston numbers will write the proper data to
EEPROM.

Again the 2 problems when using PutQueue are a value of 243 is
received by the PC after each message sent and no values are written
to the EEPROM.

Declarations for the output queue:
Dim byOutComm(1 To 11) As Byte
Dim byOutData(1) As Byte (I have tried both an array size of 1 and 2) ==============================================================

Public Sub DownLoadFromPC()
Dim Lc As Integer, Value As Byte
Call GetQueue(InComm, byDataArray, MESSAGE_SIZE, 0.5,
blTimeOut) 'transfer data from input queue to array
Call ClearQueue(InComm)
If byDataArray(0) = 255 Then 'does it equal 255
If byDataArray(2) = 254 Then 'if equals 254 data is formatted
correctly
byComboGroupNumber = byDataArray(COMBO_GROUP_BYTE)
lngPistonNumber = CLng(byDataArray(PISTON_NUMBER)) 'contains the
number of this piston
'Message Format: 255,Group,254,Piston,x,x,....,CS
For Lc = 0 To MESSAGE_SIZE - 5 'message size =number of data
bytes + 4 system bytes
byDataArray(Lc) = byDataArray(Lc + 4) 'gets rid of 4 system
message bytes
Next
GoTo DATA_OK
End If
End If
Debug.Print "ER" & " " & CStr(byDataArray(0))
'byOutData(0) = 21 'CByte(21) 'NACK
'Value = 21
'Call PutQueue(byOutComm, Value, 1)
Exit Sub
DATA_OK:
lngEEPromAddress = CLng((4000 + (CLng(byComboGroupNumber) *
GROUP_SIZE)) + ((lngPistonNumber - 1) * CLng(NUMBER_DATA_BYTES)))
Call PutEEPROM(lngEEPromAddress, byDataArray, NUMBER_DATA_BYTES)
Debug.Print "OK" & CStr(lngEEPromAddress)
'byOutData(0) = 6 'CByte(6) 'ACK
'Value = 6
'Call PutQueue(byOutComm, Value, 1)
End Sub

Thanks again Don,
Craig
--- In , "Don Kinzer" <dkinzer@e...> wrote:
>
> --- In , "wurlitzer28" <craig.whitley@a...>
> wrote:
> > Well no takers on this question?
>
> I looked over the code that you provided the first time and nothing
> came to mind. Attempting a diagnosis by looking at a small piece
of
> a system is difficult at best.
>
> One thing that comes to mind is that if data is not removed from a
> queue, PutQueue() will eventually not return because it will be
> waiting for space to become available.
>
> As a side note, having nothing to do with the question at hand, it
is
> almost never necessary to use a goto/label in a language that has
> modern control structures as does BasicX. Likewise, but somewhat
> less so, for Exit Sub. I am not one who is pedantic about GOTO-
less
> programming. Rather, I reserve their use for those situations
where
> the alternative is messier, more convoluted or otherwise less
> palatable. It's difficult to tell without seeing the surrounding
> code but I would guess that an If..Then would suffice nicely.