Last Updated October 12, 2003
Bob Larkin did a FANTASTIC job with thie DSP-10. This is undisputed, so don't get me wrong here.....some of us may want to run in a Windows-based environment though.
I have written an application that talks to the EZKIT-LITE board, as well as the KK7P DSPx board. It is mainly for experimentation and development, so don't expect many bells and whistles. For now, all this thing does is:
(a) Loads the Program into Memory;
(b) Downloads it to the DSPx / EZKIT-LITE board;
(c) Sends the appropriate "$GO" command to the monitor.
While developing the code, I discovered how the EZKIT-LITE monitor is somewhat brittle. For example, you'd better not be sending it anything while you're expecting a response from it, because those characters will be ignored (perhaps it is the UART code overrunning internally, whatever). In order to make things compatible with the bulk of the EZKIT and DSPx boards, I elected to make it work with the widely-distributed monitor code. The serial port interface code runs on its own independent thread, and patiently waits for the appropriate acknowledgment from the DSPx before proceeding with the next command.
Here's what you do:
Download the ZIP file and save it most-anywhere on your computer. Double-click on the zip and extract out the program ezload.exe from the zip file. Double-click on it. (You may want to dowload ULED1.EXE, an application that will flash the FL1 flag LED with a Morse-Code "1" as a simple diagnostic).
Tests to Try:
(1) Invoke the Application;
Exit the Application using the upper-right "X" button, Alt-X or Alt-F4.
(Did it terminate without a fuss?)
(2) Invoke the Application
"File->Com Settings," OK
Exit the Application using the upper-right "X" button, Alt-X or Alt-F4.
(Did it terminate without a fuss?)
(3) Invoke the Application
"File->Beep DSP-10"
You should see the line $$$ go out, followed by "-I-: Valid Response Detected."
If communication with the EZKIT fails, you will see an -E- message with comments about a timeout occurring.
(4) Invoke the Application
"File->Read DSP File" to load your program. Find the .EXE file, such as ULED1.EXE, and press OK.
The last line you see should be "$GO" followed by a "-I-: Valid Response Detected."
What this means if any of these tests fail:
| Failed Test | Possible Reason |
1 |
The code is still buggy. Lastest version moved "COM Settings" control to only execute with the cComThread semaphore (fancy way of saying it won't change serial ports while the serial port is trying to do a read or a write, which was proven to be a very very bad thing to try). |
2 |
I may have lied through my teeth about fixing (1) above |
3 |
If (1) and (2) passed, this will just mean that I can write thread-safe code, but you still can't talk to your EZKIT (for reasons I do not understand). |
4 |
If test (3) passes, and (4) fails, then we have some timing issues in the serial port code. The serial port thread handler operates on a "wake up every 50mS / 750mS time interval" manner. This means that the handler only runs 20 times a second, and safety / timeouts have a 3/4 second latency on them. I could see this still occurring. |
Remember that one of the things about the EZFAST program is that it downloads the bulk of the code at 115,200 bps, not 9600 (hence the name "FAST" is used). I don't have this implimented at this time; There were enough bugs with the serial port code as-is to not complicate matters with the fast download time. Note that it will indeed take over a minute to download the application code to the DSP-10.
And yes, I am fully aware that the UHFA application is a DOS program, so it may appear totally pointless to have a windows-based loader. Put on your thinking cap for a minute and imagine what the next-logical step would be though......
Releases:
| Release Version | Notes |
| 2003_10_12f | Serial Port configuration / control now runs only with the cComThread
semaphore properly secured. This will stall the actual serial port handler, such
that pipes may be flushed, closed / re-opened without any threat of contention occurring.
Instability with killing the application was replicated locally on a win98 box, and
this change cleaned up the issue completely. dcs structure includes 9600bps default, just in case the "set baud" entry fails. dcs structure also passes "no" for rts/cts by default, a possible escape from previous versions. Note that the d_com member of global really needs to be moved to a private member of cComThread. There were compiler errors when combining wx/thread and wx/ctb, so I just punted and exposed the semaphore to the global routine. This makes for horrible coding, but hey, no warnings / no errors, and it does the trick. |
Please feel free to send me constructive feedback.
ka7exm at gmail dot com