Hi, I am really new to programming using keil. I wanted to create a windows form kind of application which takes some parameters from a user and then runs the C code present in the file based on the inputs.
I have the C code files with me, but i am not able to set up a user interface (the form).
Can anyone please help me.
Thanks and Regards, Siddharth Gupta
Hi Friends. Thanks a lot for all the comments.. Let me explain my requirement and then please let me know what is the best way i can go about developing a solution.
1) I have a board which has a 8051 MicroController. 2) I have a USB based connection from this board to my system. 3) I need to develop a software that has a windows form in which a user will feed some values. 4) depending upon these values i want to send some commands to the MicroController.
I can design the form in C#. But now the problem arises how do i generate 8051 commands and send those commands to the 8051 controller using C#.
So someone can please tell me how can i generate commands for 8051 using C# from application. Pointers to some examples will also help.
Additionally i have to send commands over USB and receive data from the device.
If in case anyone has an alternative way of implmenting my program. Please Please guide me.
thanks and Regards, Siddharth Gupta
Siddharth Gupta,
Sorry about being snippy before, but your question is a rather large task for this forum to completely provide you with what you need to do to resolve your 'question'.
1) I have a board which has a 8051 MicroController.
Answer to #1) You are running a lower level processor
2) I have a USB based connection from this board to my system.
Answer to #2) the only link is via a USB between the systems. Thus you need a host-side USB driver and the 8051 based unit must also have a USB device driver.
3) I need to develop a software that has a windows form in which a user will feed some values.
Answer to #3) Not only will you need drivers on both ends (PC and the 8051 based device), but you will also need to establish a protocol layer to contain your personalized command/response set of information.
4) depending upon these values i want to send some commands to the Micro-controller.
Answer to #4) Over and above the USB drivers. You will have to define how this GUI interacts with the user and then send the results via the USB protocol and transmit it.
You are asking a lot from this forum, as we cannot provide you with the proper protocol, what the GUI should look like, and what the exact solution would be. I am sure most of the veteran contributors are fully capable of handling this task, but again, it would take a long time to simply provide you with an answer with so many unknowns. And even if you were to clarify those unknowns, I doubt if anybody will donate that much 'free time' to your problem.
Now if you don't need the GUI interface you can do what I said and have the 8051 communicating over the RS232 (DE9) ports and run Hyperterminal as it's user interface. Yet again you will have to develop the proper communications protocol.
Your friend, who said that you have the code already, is probably half-right. He may be speaking about the Device Side (the 8051) USB stack, and its USB requirements. Study that software package along with the USB stack and layers and you may have found your higher-level protocol. Now all you will have to do is write the USB driver for the host (PC) side. A company called Jungo (http://www.jungo.com) may help you develop the host side driver for the USB interface. What is then left is for your GUI interface to 'speak' through this host-side USB driver.
I think that is about the 'best' answer you will get on this forum. You will not get any 'code' that specifically answers your needs.
Like what stephen phillips said, you may have thought that the interface would be "trivial" to do, but it is not a simple task to write [robust] USB drivers.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Does your 8051 has USB? Or does your 8051 board has a USB-to-serial chip so that the 8051 chip just sees serial data, and the PC sees an extra serial port?
In case the 8051 board just shows up as another serial port, you will be able to forget everything about USB and concentrate on standard RS232 communication.
If all you need is to send commands, then you can send each command as a single character: 'A' -> Read ADC and report value back. 'B' -> Blink LED. 'R' -> Reboot.
If you need to also send parameters to the board, then it would probably be easiest to send each command as one text line followed by a line break. "A10\n" -> Read ADC channel 10. "A0-7\n" -> Read ADC channels 0 to 7. "B,1,100,100\n" -> Blink LED 1 with 100ms on time and 100ms off time.
If your board does not show up as a standard serial port, then you should have a talk with your teacher about exactly what library code the school is helping out with, since I do not believe that they would expect you to implement all that on your own.
Presumably, by "system" here, you mean the PC on which the Windoes form is to run?
As Per says, you need to explain how this "USB based connection" appears to both the 8051 and the PC!
"the problem arises how do i generate 8051 commands and send those commands to the 8051 controller using C#."
That depends entirely on the nature of the "USB based connection", and has nothing to do with the fact that an 8051 is involved!
Any decent embedded USB thing should come with model drivers and examples from the supplier. If yours doesn't, then you should seriously consider ditching it for one that does!
I know of about 2000 such boards that have one of about 300 different '51 derivatives on them.
WHAT BOARD (link, please) WHAT '51 (link, please)
Erik
plz Tamir for avising?
"WHAT BOARD (link, please) WHAT '51 (link, please)"
As far as the PC GUI App is concerned, this is almost certainly irrelevant!
Yes and no. It could possibly solve the open issue about the USB.
As far as the GUI is concerned, it just deals with whatever API is provided by the driver - it neither knows nor cares what is physically connected to the end of the link.
eg, the connection may appear to the PC as just a bog-standard COM port - so, as far as the GUI is concerned, it's just a standard exercise in sending stuff to a COM port, and receiving stuff from a COM port!
As far as the GUI is concerned, the GUI developer may have to implement a protocol to transfer using a driver the GUI developer has to install. So what may be irrelevant to the GUI application need to be irrelevant to the GUI developer.