Dear all, I have one question about how to send debug code(8-bit) from within 8051 C program in "real-time" to working computer ?
Background: Currently 2 ways are used to debug issue: #1. via serial port(to show debug code Ex. string or Hex number) #2. via LA(to observe what we want to see by setting trigger conditions)
For #1 we can show everying but it occupy more code space;besides it add "delay" within code...
For #2 we can see more detailed information but LA has limited RAM and thus we can not "log" complete firmware behavior...
Question: Is there any other method we can use to send Ex. debug code(8-bit) outside to computer in real-time and we can "log" much data ?
My first thought is: - Use Port1 of 8051-A to send 8-bit value in Keil C Ex. P1 = 0x66; - Connect Port1 of 8051-A to Ex. Port1 of 8051-B - 8051-B is responsible for read Port1 and send out by USB (<- it seems there exists tool kit for this purpose...) - In computer system one application is written to receive the debug code and show on screen( much like HyperTerminal...)
Is it workable ? or there is also ready-made way ? or better way to achieve this goal ?
Besides, it must be ok if: P1 = 0x66; P1 = 0x77; P1 = 0x88; ( we have to see "66" "77" "88" on screen and no loss)
Could you give me some recommendations/comments ?
Thanks !
I presume that's supposed to mean "Logic Analyser"?
"but LA has limited RAM and thus we can not "log" complete firmware behavior"
So get one that does have enough RAM - or a comms link to something with enough storage (eg, a PC)!
;-)
Essentially, what you want to do is to build a "logic analyser" in your 2nd 8051...
External equipment would not be able to pick up an 8-bit value from a port and know if you do one 0x66 write or if you did two. You should use a handshake linesomewhere. Maybe limit yorself to a 7-bit code or define a specific value as forbidden and then do:
P1 = 0x66; P1 = 0x66 | 0x80; ... P1 = 0x77; P1 = 0x77 | 0x80;
or
P1 = 0x66; P1 = 0; ... P1 = 0x77; P1 = 0;
Yes, you will lose a bit of speed, but the external hardware will have a way of picking up the individual writes. The alternative with a hardcoded value between each output may suffer from racing conditions - a single "latch" bit is easier to implement.
Look up the LOG command and SLOG command in the debugger manual. It's quite versatile but cetainly not real time. You can use a breakpoint to trigger a debugger script that will printf to the command window. You can log anything written to the command window to a file, create a file or append to a file. Just remember, this printf is a debugger script utility and has nothing to do with the standard C printf although it works almost the same. You can pick up variables and port values from your target code to print to the file. Bradford
To Andy Neil, LA can observe detailed H/W behavior, such as "transferred data on bus" and involved H/W signals. But it can not log much due to RAM-limit.
Different debug tool has different occasion to use.
To Per Westermark and Al Bradford, Thanks for your information and I will allocate time to study it.
The first method I want to realize is: connect Ex. P1 to 7-segment and display "progress code" or any 8-bit value.(It is just like what I used before when porting BIOS).
Second, I will find way to log Ex. P1's value by external H/W or create specific mechanism to catch firmware behavior and log as much data as possible...
If you send out 7-bit data and use the 8th bit for latching, then it is easy to combine this with a large RAM and an address counter that gets stepped one tick whenever the latch bit gets cleared, and the data gets stored in a memory cell every time the latch bit gets set.
With a suitable RAM, you will be able to catch a lot of data at very high speeds.
You could then: - deactivate the write signal to the RAM - change 7 of your I/O signals from output to input use. - reset the address counter - tick through all addresses of the RAM and read back the 7 bits of data and for example send on the serial port to a PC for further analysis.
Or you could make use of 7-segment digits to show the address and data and have buttons to tick the address counter one step forward/backward and just manually read the contents - but remember that if you read the data externally, you must then first have deactivated the output drive for the processor pins that are connected to the data lines of the RAM, or you must have a buffer chip with tristate function between processor and RAM.