sharc_serial.txt

matlab串口m文件

As a certified Newbie, I've had a tough time getting the Sharc EZ-Lite kit to communicate 
with a PC via the asynchronous serial port so a PC program can poke and peek at variables 
on the Sharc and thus control the DSP from a front-end GUI. I struggled with finding out 
the correct byte order (and what about the bits?), the need for a therapeutic BADC0DB4 e-
sync message, setting up the Comm port for binary non-handshaking communication, and all 
that. Thanks to TW, who helped me with crucial info. My particular program is written in 
Visual Basic. I stand in awe of the people in this group who are doing things like 
finessing the memory limitations of the EZ-Lite and worrying about DMA features... 

Several people E-mailed me after my post about how to get a PC to talk to the Sharc EZ-
Lite board, wanting to know these closely-guarded secrets. Below are the main points. The 
WhyGee Sharc page guy is also going to post this information, perhaps in more complete 
form. 

1. To send the message packets corresponds to the various commands, you send each 32-bit 
word in the sequence described in the documentation, like page 6-7 or 6-10. You send each 
word as 4 "ASCII" characters (if you want to think of them that way), like a control-B if 
the byte/character is supposed to have a numeric value of 2. But you send the four 
characters/bytes within each 32-bit word in Reverse order. So, for a typical command 
which has a Packet Length of 2, you would first send the 4 zero bytes (all bits zero) for 
the Source ID and Destination ID; that 's just the way it is. Then, in the next 32-bit 
word containing your particular command and the Packet Length, you would first send the 
byte whose numeric value is 2, then a byte whose numeric value is zero (because the low-
order 16 bits are really 0 and then 2, not just 2), and then the 2 bytes corresponding to 
the particular command, also LSB (least-significant byte) first. You do not do anything 
funny to the bits within each byte; they are sent in the usual order that a PC UART sends 
them in. (You probably already knew all this, but it's hard to be sure when it still 
doesn't work! See below.) 

2. The Sharc may not be listening to you. You have to get its attention by sending a 
magic 'wake up' signal, called Host ReSync. This is 0xBADC0DB4 . (The 0x just means that 
BADC0DB4 is given in Hex notation.) You do not have to send the 0 bytes (Source and 
Destination ID) before this, though it probably doesn't matter because this magic signal 
will cause the EZ-Lite to start listening to characters from the PC again. As implied by 
0xBADC0DB4, the resync signal consists of the (decimal) bytes 180, 13, 220, 186, in that 
order. When in doubt because your setup isn't working, send this signal. The EZ-Lite can 
very easily get confused and stop listening to your characters if you send it some wrong 
stuff. You also have to send this signal the very first time, when you have just powered-
up or reset the board and have the delightful Peter Gunn theme playing. 

3. Make sure your serial port UART/software is set up for raw "binary" communications, 
not just printable text characters. You also want it to _avoid_ doing any of the usual 
helpful things like linewrap, XON-XOFF handshaking, etc. In Visual Basic version 5, this 
is easy to achieve using the MSComm component-- set its InputModeBinary property to true 
and its NullDiscard property to false. I also enabled the Comm port's DTR signal, but I'm 
not sure if that matters to the EZ-Lite. Set Handshaking mode to None. I haven't yet 
tried this in C. If you get this stuff wrong, null (zero) bytes may well disappear the PC 
and Sharc won't be able to communicate. 

4. Some of the above info comes from a document entitled "Update to SHARC EZ-KIT Lite 
Message Packet Protocols." I got this from someone at ADI, but haven't yet asked if it's 
OK to distribute this WordPad document to people who, uh, might actually want to talk to 
their EZ-Lites. This two-page document also reveals how to change the baud rate.

5. One other point, in case you're trying to do your own GUI PC front end for a program 
on the Sharc: You just "poke" and "peek" at variables in your Sharc program, using, for 
example, the Write DM32 command described in section 6.3.2. (I suppose you could write a 
more elaborate message-passing scheme if you wanted to.) To find out where your 
particular variables are in the Sharc's memory, use the 'ga' (Get Address) command of the 
diag.exe program. To look for variable myvar in your program, you have to use an argument 
of _myvar for the ga command. 

Hope this helps other Sharc newbies, 

Chuck Cooper