Can I use LabVIEW 6i Full Development System to communicate with an embedded controller?

[bhenry]

I need to download C code to a BL1500 embedded controller from Z-World using LabVIEW and then be able to run the program and retrieve the data while it is running. My operating system is Windows 2000. Is this possible?

[LV_Pro]

---

@bhenry wrote:
I need to download C code to a BL1500 embedded controller from Z-World using LabVIEW and then be able to run the program and retrieve the data while it is running. My operating system is Windows 2000. Is this possible?

---

It depends on how you communcate with the BL1500. If it is through a serial port connection then there should be no problem writing a LabVIEW program that sends the appropriate commands, reads in the C code and sends it to the uC. If the "C code" is binary in may be a little tricker reading the file in to write it. Now, as to retrieving the data, it depends on whether you know the protocol from the BL1500. I'm assuming that this may be defined in the C code that you are downloading.

If the communications is through other "channels" (i.e. USB) then you may have a little more work to write the code to talk to it.

How are you planning to "talk" to it, both ways (to and from) and in what form is the "C code"?

Putnam Monroe
Certified labVIEW Developer
Senior Engineer - North Shore Technology, Inc.

[bhenry]

I am using the serial port. The C code was written using Dynamic C version 5.24

[LV_Pro]

So the C code is in binary format? Do you know what the expected response from the uC looks like? You will need to build a serial communications portion that can read in the binary file, and write it, with whatever header, etc., the uC expects. The monitoring will probably be done by a different section that will probably need to be able to write and read from the serial port. Use visa calls as the "traditional serial" is not being supported in the future. There are examples of serial communications.


Putnam Monroe

[bhenry]

This sounds like I'm in way over my head. I've had one basic course of C programming and the basic courses I and II in LabVIEW. Thanks for your help.

[Donald]

---

@bhenry wrote:
This sounds like I'm in way over my head.

---

bhenry,
You're correct in that it wouldn't be a trivial exercise, but it would be easier if you cut out the requirement to download the BL1500's program with LabVIEW. Why do you want to download with LabVIEW instead of using DynamicC's interface? Is this an assembly/testing automation situation?

[bhenry]

I want to be able to run the device and exctract the data that it sends back and then put into a predesigned spreatsheet. I don't really care if this is done with labView. Currently the data is cut and pasted from the screen ever 3-4 iterations of using the device. Once all the data is in the spreadsheet, the data is then copied into a Word document so macro can be run that eliminates the text leaving only the desired numbers in a specied format. This block of data is then copied back into a speadsheet where it is determined whether or not it passes and retianed for Device History File. Any thoughts?

[LV_Pro]

I wasn't trying to imply that you needed to know C, rather that the "C code" you would be downloading wouldn't be a text file rather you would have to read in a binary file and send that data via the serial port. How is the uC run? Usually the "firmware" is downloaded from your compiler and then the downloaded program is started to cause the embedded machine to run. Does downloading the code start your uC? How do you normally "read back" the data from it? If you know the protocol that it returns the data and you are mostly interested in automating the reading of that and inserting that data into a spreadsheet or other file, then it sounds doable in LabVIEW. It would be easier if the downloading of the C code wasn't part of the mix, it can get somewhat complicated depending on the uC download protocol. It might require that you break the C code's binary file into sections, provide a header describing the length, calculate checksums, etc., so if you can download that code by some other means and just concentrate on reading back and handling the data that would probably be a lot easier.


Putnam Monroe

[bhenry]

Putman,

Normally I run Dynamic C which will scan for a few libraries and then reset the target. Then I select the .c file I wish to run. When I select "run" it compiles to the target and runs the program. "printf" commands are sent back via the serial port and diplayed on the screen. When the device is used, information is sent back and it is portions of this information that I want to extract. Maybe I should try to creat my own print subroutine that would display only the data I wanted.

[Donald]

---

@bhenry wrote:
... Maybe I should try to creat my own print subroutine that would display only the data I wanted.

---

bhenry,
That sounds like a very good idea.

And though I'm very, very rusty on Z-World/Dynamic C, I think LabVIEW could be of benefit in your system by getting rid of the screen>XL>Word>XL tedium. It could easily catch what the BK1500's printf commands are sending and format/file/etc them however you want.

As mentioned before, replacing the use of DynamicC to select, upload etc. may be more than a relatively new programmer like yourself may want to tackle at the start. I took a brief look at the BL1500's manuals and my dusty manuals for the ZWorld PK2100 and think it might be possible, but I'm sure there would be headaches/growing pains. But at the very least you could just call DynamicC from LabVIEW using the System Exec.vi or some other means.