I have said the PicServo talks fine at 19200 baud with a PC program. This being said, last night I sent the PicServo a 'set baud command to 9600' and this is what happened. I began getting the status byte from my 'return version info' command. I could tell as the returned values were either hex 11 or hex 19. It was 11h when i had 'power_on' input attached to voltage. It was 19h when I took it off and bit 3 goes off while bit 4 gets set. This is normal as I understand things. However, it always gives me a 'chksum_error' bit. I read this as bad values were sent to it. My command stream consists of: two AAh , Fh , Fh resets then the first command to retrieve model and version info. It should return two bytes and a checksum. ---------- header, Def_addr, cmd, addcmd cksum I am sending AAh, 00h , 13h, 20h, 33h In case of wrap around, header = AAh addr = 00 cmd = 13h add cmd = 20h request type and version chksum = 33h address + cmd + add'tl cmds and this returns the status ( 11 or 19h). If I understanding the checksum correctly? I am summing the address, command and additional command bytes. I never get the data only the status byte. For this I will have to verify my SendCommand routine. Fine.. But. I know the BasicX24 can speak 19200 well as I use it on the LCD, only one way, transmit. More work to be done. Tonight a circuit to insure good data between BX24 and PicServo. A 7141 Schmidt trigger and a couple of invertors should do it. More to come. BTW, after reducing the baud to 9600 all the RcvStat versions I tried work. (Do While, For Next, If Then) I have illiminated all my Call Delay's with no change. I am a learning son-of-a-gun.... Thanks, Don Lewis --- In , "Frank Manning" <fmanning@n...> wrote: > From: Don Lewis <djlewis@a...> > > > [...] I expect i misinterpreted the > > GetQueue(InQueue, Variable, number) function. while > > I have been over and over the BasicX Docs I did not > > catch that the instring might misrepresent the > > datatype I am trying to capture. I was thinking it > > would store RAW data. > > And you would be right. It does store raw data. > > This is in fact a high performance way of writing to a string. > Byte 1 is the length, byte 2 is the type (fixed vs. variable), and > bytes 3 through N are the characters in the string. > > In other words, low-level data is written directly to the string. > > The problem is that most people probably expect bytes 1 to N to be > the string characters, not bytes 3 through N. > > The system library has a procedure called PutQueueStr but > unfortunately doesn't include its counterpart GetQueueStr. We > should probably add GetQueueStr or something similar in the future > to prevent misunderstandings. > > -- Frank Manning > -- NetMedia, Inc.

From: Don Lewis <> > [...] I expect i misinterpreted the > GetQueue(InQueue, Variable, number) function. while > I have been over and over the BasicX Docs I did not > catch that the instring might misrepresent the > datatype I am trying to capture. I was thinking it > would store RAW data. And you would be right. It does store raw data. This is in fact a high performance way of writing to a string. Byte 1 is the length, byte 2 is the type (fixed vs. variable), and bytes 3 through N are the characters in the string. In other words, low-level data is written directly to the string. The problem is that most people probably expect bytes 1 to N to be the string characters, not bytes 3 through N. The system library has a procedure called PutQueueStr but unfortunately doesn't include its counterpart GetQueueStr. We should probably add GetQueueStr or something similar in the future to prevent misunderstandings. -- Frank Manning -- NetMedia, Inc.

Frank, I don't hold anyone else responsible for my own lack of knowlege. I am glad you and others are offering options that I may think about and try. I went through them all this last weekend. As for your suggestion below, Yes PicInString is a string. I am expecting bytes returned. The status info returned is Int numbers to read and bytes to OR and AND against. I expect i misinterpreted the GetQueue(InQueue, Variable, number) function. while I have been over and over the BasicX Docs I did not catch that the instring might misrepresent the datatype I am trying to capture. I was thinking it would store RAW data. Thanks again for your patients. Don Lewis --- In , "Frank Manning" <fmanning@n...> wrote: > From: Don Lewis <djlewis@a...> > > > Well another weekend goes by and I can still only > > communicate with the Pic-Servo chip with serial > > from a PC through a ttl to serial convertor > > Maxim233 chip. > > > > The BX24 through ttl to the P-S still sends data > > and I can stil see the echo from the PS tx pin > > but can not read valid data. > > It doesn't help that the SNR on this thread is very low, which is > partly my fault, I'm sorry to say. > > > Tonight I will try a 7414 between BX and PS chips. > > This is getting too old. > > > > Talking between two other devices and the BX > > using both ttl and regular serial was easy. > > OK, so you're receiving data, but the data is not valid? Part of > the problem might be in translating this QBasic line: > > RetStr = INPUT$(n, #1) > > To this BasicX line: > > Call GetQueue(PicCom3In, PicInString, N, 1#, TimedOut) > > where PinInString is a string type. This is legal, but might not > be doing what you think it's doing. It's writing in binary > directly to a string, which includes the 2 byte descriptor at the > front of a string. > > You probably want something different. Check out this code as an > example of reading a 2-character string: > > '------------- > Option Explicit > > Dim PicCom3In(1 To 13) As Byte > Dim PicCom3Out(1 To 10) As Byte > '------------- > Public Sub Main() > > Dim RetStr As String > Dim B As Byte > Dim N As Integer > > Call OpenQueue(PicCom3In, 13) > Call OpenQueue(PicCom3Out, 10) > Call OpenCom(1, 19200, PicCom3In, PicCom3Out) > > Do > RetStr = "" > > ' Read pair of characters. > For N = 1 To 2 > Call GetQueue(PicCom3In, B, 1) > RetStr = RetStr & Chr(B) > Next > > ' Echo to console. > For N = 1 To Len(RetStr) > B = Asc(Mid(RetStr, N, 1)) > Call PutQueue(PicCom3Out, B, 1) > Next > Loop > > End Sub > '------------- > > -- Frank Manning > -- NetMedia, Inc.

From: Don Lewis <> > Well another weekend goes by and I can still only > communicate with the Pic-Servo chip with serial > from a PC through a ttl to serial convertor > Maxim233 chip. > > The BX24 through ttl to the P-S still sends data > and I can stil see the echo from the PS tx pin > but can not read valid data. It doesn't help that the SNR on this thread is very low, which is partly my fault, I'm sorry to say. > Tonight I will try a 7414 between BX and PS chips. > This is getting too old. > > Talking between two other devices and the BX > using both ttl and regular serial was easy. OK, so you're receiving data, but the data is not valid? Part of the problem might be in translating this QBasic line: RetStr = INPUT$(n, #1) To this BasicX line: Call GetQueue(PicCom3In, PicInString, N, 1#, TimedOut) where PinInString is a string type. This is legal, but might not be doing what you think it's doing. It's writing in binary directly to a string, which includes the 2 byte descriptor at the front of a string. You probably want something different. Check out this code as an example of reading a 2-character string: '------------- Option Explicit Dim PicCom3In(1 To 13) As Byte Dim PicCom3Out(1 To 10) As Byte '------------- Public Sub Main() Dim RetStr As String Dim B As Byte Dim N As Integer Call OpenQueue(PicCom3In, 13) Call OpenQueue(PicCom3Out, 10) Call OpenCom(1, 19200, PicCom3In, PicCom3Out) Do RetStr = "" ' Read pair of characters. For N = 1 To 2 Call GetQueue(PicCom3In, B, 1) RetStr = RetStr & Chr(B) Next ' Echo to console. For N = 1 To Len(RetStr) B = Asc(Mid(RetStr, N, 1)) Call PutQueue(PicCom3Out, B, 1) Next Loop End Sub '------------- -- Frank Manning -- NetMedia, Inc.

FYI: as my life is an open book.... Well another weekend goes by and I can still only communicate with the Pic-Servo chip with serial from a PC through a ttl to serial convertor Maxim233 chip. The BX24 through ttl to the P-S still sends data and I can stil see the echo from the PS tx pin but can not read valid data. Tonight I will try a 7414 between BX and PS chips. This is getting too old. Talking between two other devices and the BX using both ttl and regular serial was easy. Therefore I feel I have some experience. Now it might be a hardware issue thought the ttl rise and fall transitions look very clean and fast on the O-Scope. Thanks, Don Lewis

From: Dan Bielecki <> > > From: Don Lewis [mailto:] >> >> [...] >> Do >> If StatusQueue(PicCom3In) Then ' Does go true >> Exit Do >> End If >> Loop > [...] > > In the sub RcvStat, you have that funky Do Loop that > checks if data is on the inbound queue. Because of the > break in logical structure with the Exit Do, there is > heavy stack usage as the system maintains the logic > token of the Do Loop. > [...] > Simplify that Do Loop like so: > > DO UNTIL STATUSQUEUE(PicCom3In) > CALL DELAY(0.00) > LOOP I agree it's a good idea to replace exit-do with do-until. But it's a good idea because it's easier to read, not because it uses less stack. All of the following blocks of code use the same amount of stack. Stack use is determined by the Boolean expression: ---------------------------- Do If (Expression) Then Exit Do End If Loop ---------------------------- Do Until (Expression) Loop ---------------------------- Do Loop Until (Expression) ---------------------------- Node1: If (Expression) Then GoTo Node2 End If GoTo Node1 Node2: ---------------------------- Speed and EEPROM memory requirements are not all the same, but stack use is the same for each block. -- Frank Manning -- NetMedia, Inc.

--- In , "Dan Bielecki" <Dan.Bielecki@A...> wrote: > Because MAIN( ) is a subroutine. > ....and subroutines have a caller. > > .db. Yes, but the caller does not have to be another task, i.e OS task. And MAIN does not have to be a true subroutine either. It could be just a syntaxial (spelling?) issue, to indicate where to start. To me it would make no sense to have another task running in the background, as all actions are (or could be) interupt driven. See my earlier post. Ingvar

From: Dan Bielecki <> > From: Frank Manning [mailto:] > >> From: Dan Bielecki <> >> >>> [...] >>> Based on my personal experience with your platform, >>> no-op do loops are a thing to avoid. The Delay >>> call serves or triggers some internal function to >>> smooth out execution-jitter of the instruction-set >>> as it flows thru the Atmel, thereby causing a BX >>> to seize during runtime. [...] >> >> You have some example code that demonstrates this? > [...] > > Frank, Com'on. I couldn't make that statement if > I didnt have code to see it happening in the first > place. Do you have a StampMEM and a proper test > environment this time around? > *** > If not, you can set up a visual of the jitter, yourself: > > In VB, create a project that grabs the PC's time and > sends it to the BX on com1 every second. Why aren't you posting the code? I thought that was what you agreed to do? > In BasicX, create a project that reads the time > on Com1, syncs the bxRTC once if not done already > with the PC's time, and then outputs the time from > the PC to the LCD+ on line one, from that point on. > > On LCD+ line two, output the BX's RTC time every > second. > Now fire them up and watch them. Every second, the > PC will send down an HH:MM:SS and the BX will output > its time. Right as the seconds roll over, between > 0 an 1, and then again between 1 and 2 there will be > the jitter I spoke of. > The BX will be in the jitter and lag, loose a second > and the PC time will remain ticking. > > By second-3, the BX will have recovered from the > jitter and be ticking along again in time with the > PC, up to second-59. [...] I don't understand why you aren't posting the example code yourself, but OK, I wrote a similar program that synchronizes from the PC clock on Com1, and sends data back through the same serial port. I'm also using two empty do-loops to wait for data. Zero delays are not being used: Do Until (StatusQueue(InputQueue)) ' Null Loop I don't see any problems with the program. The errors you describe are not appearing. The code is shown below, and was adapted from the GPS text decoder application note in the BasicX distribution. -- Frank Manning -- NetMedia, Inc. Attribute VB_Name = "TimeDecoder" '-------------------- Option Explicit Private TimeGPS(1 To 3) As Byte Private Const MaxDigits As Byte = 5 Private PowTenLookup(1 To MaxDigits) As Integer ' 11 byte buffer. Private Const InputQueueSize As Integer = 20 ' 1-byte buffer. Private Const OutputQueueSize As Integer = 10 Private InputQueue(1 To InputQueueSize) As Byte Private OutputQueue(1 To OutputQueueSize) As Byte '-------------------- Public Sub Main() Call Initialize Call SyncTime Do Call GetFix(TimeGPS) Debug.Print Call DisplayPCTime Call DisplayBXTime Loop End Sub '-------------------- Private Sub SyncTime() Dim Hour As Byte Dim Minute As Byte Dim Second As Single Call GetFix(TimeGPS) Hour = TimeGPS(1) Minute = TimeGPS(2) Second = CSng(TimeGPS(3)) Call PutTime(Hour, Minute, Second) End Sub '-------------------- Private Sub DisplayBXTime() Dim Hour As Byte Dim Minute As Byte Dim Second As Single Call GetTime(Hour, Minute, Second) Debug.Print "BX: "; CStr(Hour); ":"; CStr(Minute); Debug.Print ":"; Fmt(Second, 2) End Sub '-------------------- Private Sub DisplayPCTime() ' This procedure transmits time in HH:MM:SS format. Dim B As Byte Dim MSDig As Byte Dim LSDig As Byte Debug.Print "PC: "; B = TimeGPS(1) LSDig = B Mod 10 B = B \ 10 MSDig = B Mod 10 Debug.Print Chr(MSDig + 48) & Chr(LSDig + 48) & ":"; B = TimeGPS(2) LSDig = B Mod 10 B = B \ 10 MSDig = B Mod 10 Debug.Print Chr(MSDig + 48) & Chr(LSDig + 48) & ":"; B = TimeGPS(3) LSDig = B Mod 10 B = B \ 10 MSDig = B Mod 10 Debug.Print Chr(MSDig + 48) & Chr(LSDig + 48) End Sub '-------------------- Private Sub Initialize() PowTenLookup(1) = 1 PowTenLookup(2) = 10 PowTenLookup(3) = 100 PowTenLookup(4) = 1000 PowTenLookup(5) = 10000 Call OpenSerialPort End Sub '-------------------- Private Sub GetFix( _ ByRef TimeGPS() As Byte) Const RecordStart As Byte = 13 ' <CR> Dim B As Byte Dim N As Byte Dim Colon As Byte ' Character ' Position Do Do Until (StatusQueue(InputQueue)) ' Null Loop B = GetByte ' 1 Loop Until (B = RecordStart) TimeGPS(1) = CByte(GetNumber(2)) ' 2 .. 3 Colon = GetByte ' 4 TimeGPS(2) = CByte(GetNumber(2)) ' 5 .. 6 Colon = GetByte ' 7 TimeGPS(3) = CByte(GetNumber(2)) ' 8 .. 9 End Sub '-------------------- Private Function GetNumber( _ ByVal DigitCount As Byte) As Integer ' This function converts a decimal string to an ' integer. The string is of length DigitCount. ' ' Each character must be a decimal digit. Dim PowTen As Integer Dim N As Byte Dim InByte As Byte PowTen = PowTenLookup(DigitCount) GetNumber = 0 For N = 1 To DigitCount InByte = GetByte GetNumber = GetNumber + (CInt(InByte - 48) _ * PowTen) PowTen = PowTen \ 10 Next End Function '-------------------- Private Sub OpenSerialPort() Const Baud As Long = 19200 Const PortNumber As Byte = 1 Const SerialInputPin As Byte = 0 Call OpenQueue(InputQueue, InputQueueSize) Call OpenQueue(OutputQueue, OutputQueueSize) Call OpenCom(PortNumber, Baud, InputQueue, OutputQueue) End Sub '-------------------- Private Function GetByte() As Byte Dim Value As Byte Do Until (StatusQueue(InputQueue)) ' Null Loop Call GetQueue(InputQueue, Value, 1) GetByte = Value End Function '--------------------

Frank, Com'on. I couldn't make that statement if I didnt have code to see it happening in the first place. Do you have a StampMEM and a proper test environment this time around? *** If not, you can set up a visual of the jitter, yourself: In VB, create a project that grabs the PC's time and sends it to the BX on com1 every second. In BasicX, create a project that reads the time on Com1, syncs the bxRTC once if not done already with the PC's time, and then outputs the time from the PC to the LCD+ on line one, from that point on. On LCD+ line two, output the BX's RTC time every second. Now fire them up and watch them. Every second, the PC will send down an HH:MM:SS and the BX will output its time. Right as the seconds roll over, between 0 an 1, and then again between 1 and 2 there will be the jitter I spoke of. The BX will be in the jitter and lag, loose a second and the PC time will remain ticking. By second-3, the BX will have recovered from the jitter and be ticking along again in time with the PC, up to second-59. Visually it is as if seconds 0,1 and 2 are not full seconds and are shorter then seconds 3 thru 59. *** I saw the jitter since I communicate with my BX in real time. I have a process that sync's the clocks and then will only issue a new sync command if the BX reported back a different Date/Time then the PC. When I first implemented the process, I would see the two CPUs sync-ing at 0, 1 & 2 seconds, then be in sync until the next minute ticked by, then do it all over again, every minute. The reason was that the BX lags behind at those times, reports a different second then the PC and the PC would send the sync to put it back in time. This jitter is even more pronounced on the black one. I only used to loose real time once every 5 or 6 days on the older green BX -- until it locked up. The replacement black one needs the RTC sync'd every day. It actually looses time now under v2.1. I have another black one that was just ordered, sitting on the workbench. I've been meaning to test it out also. What goes on in the OS at seconds-rollover of 59 to 00 and why does it take up to three seconds to do? Whatever it is, code some logic in a tight loop that is running right around rollover time and you can get a BX that is very hard to gain control of from the IDE. A tight loop is hard for the IDE to gain control of anyway and if in that 3-second rollover window....even more so. By the way, aesthetically, I prefer the black over the green. Is it a Revision marker to indicate something? .db. -----Original Message----- From: Frank Manning [mailto:] Sent: Thursday, February 05, 2004 1:18 PM To: Subject: Re: [BasicX] BX24 and Pic-Servo (JRKerr) From: Dan Bielecki <> > [...] > Based on my personal experience with your platform, > no-op do loops are a thing to avoid. The Delay > call serves or triggers some internal function to > smooth out execution-jitter of the instruction-set > as it flows thru the Atmel, thereby causing a BX > to seize during runtime. [...] You have some example code that demonstrates this? If a processor seizes, it seems to me that should be easy enough to verify. > Personally? Without seeing any source, I think it > has to do with the odd timing skips one sees in > the RTC, right around the time the Seconds roll > into the Minutes. There's this little hiccup, > right there in the timing. Between 0-second and > 1-second, and then again between 1-second and > 2-seconds. After that, the remaining 58-seconds > are in time. [...] Again, you have some example code that demonstrates this? -- Frank Manning -- NetMedia, Inc. _____ > .