I’m fairly new to this, but I have worked out how to use a Console Application project to automatically switch LEDs on and off which are connected to my FEZ Domino’s various Analogue and Digital Pins, given the many tutorial examples available online - The FEZ Domino is connected to the Desktop via USB. I have also come up with a Windows Application project Form which has radio buttons which turns on and off coloured pictureboxes on the same form. I have even put both projects into the same solution and they both work in splendid isolation!
My problem now is trying to work out how to pass the desired status of the LEDs from the Windows Application project form to the Console Application project in order to achieve manual control of the LEDs from the Desktop. Not being a C# guru, I am not sure if this is achieved by global variables, strings or some other clever way and would therefore appreciate if someone could please point me in the right direction.
The easiest way now is to use a serial port. Yes you are connected over USB but that is used for debugging. You can use it for both but I do not recommend song so. What other gear do you have? If nothing then get yourself an RS232 shield. Google or up.
Silly question if I may - Does using an RS232 shield also require a serial connection on my Laptop? Also, would you recommend any particular RS232 Shield for the Domino?
What I would like to eventually do is use my microcontroller to support an underwater ROV via an Ethernet cable between the Laptop and Microcontroller, as I understand that Ethernet cables can be much longer than other types of tethers (I have seen the serial Underwater ROV on the TinyCLR site for the Panda by the way). With this in mind, is there something else I need to do here for an Ethernet connection?
Going back to communicating data (strings, variables, etc) between projects within a C# solution - Any ideas how best to achieve this? Are you recommending I do not use the USB for both debugging and passing commands because it is complicated or because it is bad practice?
Ethernet cable might just be used for the cabling medium, but is still using something like RS232 signalling over the wire. RS485 is probably better suited to longer distance communication. Not sure what depth you want to take your ROV to but that is also a factor; what cable connections are you going to use so that they’re protected.
If you do need ethernet, then you need a Fez Connect shield or an ethernet shield using Wiznet w5100 chip.
Personally, using CDC mode to get both debug and serial comms to the PC is not a bad way of going about it in the short term, but you can’t beat having a dedicated connection.
Communicating data - you have to have an agreed data / message format. It’s totally up to you to figure that out and code for it. It could be as simple as the Windows app issuing a command that says nothing more than a string like “?”, and the ROV then dumps back everything it cares about and is measuring. “L” might be you guessed it turn left, “R”, “U”, “D”, whatever… it’s totally up to you. Or alternatively, you could implement a 3dimensional Logo language interpreter, or whatever you choose.
I’ll have a look at the links which I am sure will be most helpful.
Not being a C# wiz though, I’m still a bit unclear though how within the overall C# solution, I pass data between the C# Windows Application project with the interface form and the C# Console Application project which actually talks to the Domino. In other words, is there a way to assign a value to a string or variable in one C# project and read it in the other (within the same solution) and if so, how do I do this?
one side does a WRITE() to the UART, and on the other side it READs the value. They are independent pieces of code, they just need to agree what the “message” is and each end then has to deal with the message it gets.
Start simple.
Write a program for Fez that sends a response when it recieves the character “A” on the UART.
On the PC, use a terminal program and watch what happens when you type a B in. Then type A.
Then, once you have that working, change the terminal program to be your program that then sends A and B and displays any data that is returned.
If I understand you correctly, both the READ and WRITE code resides in the Console Application project of the C# solution, but surely I will still need to use a separate C# Windows Application project in the overall solution for the form that is used for the laptop on-screen controls? If this assumption is correct (as I understand that I cannot produce the WPF forms in a Console Application project), I still do not understand how these two C# projects share data before I even get to the stage of communicating with the actual Domino.
For instance, if I have within one C# project a WPF form that uses two radio buttons to select between either a red or green LED and changes the status of either a variable/string depending on which radio button is selected. Then, I also have a separate C# Console Application project to do the READ and WRITE with the Domino in order to turn the respective LEDs on or off. How do I pass the information from the string/variable set in the WPF Form to the Console Application? Every time I have tried this, the value of the string/variable seems to be only local to one project and not recognised by the other.
Sorry if this is seemingly a bit of a silly question, but I sense this is something relatively simple to address in C#; although my C# book seemingly fails to address this matter!
They’re two separate applications, they only share what is agreed on.
I’m no WPF/Windows developer so you’re on your own there. Start with a new (separate) project would be my suggestion.
This is just a proposed way to achieve what you want. You may not want feedback, you may not care, but this is one way I thought of your red/green problem.
In your Windows App, when you click the radio button for RED, it does a SEND of the word “RED\n” over the UART. It then waits to get a confirmation for a length of time, and if the confirmation of “OK\n” comes back, then it knows the LED has changed and can update the indicator that shows the RED LED lit. If the uart.read() fails to get an “OK\n” response before timing out, it shows there’s an error. When you click the GREEN radio button, it sends “GREEN\n” and waits for confirmation, and handles the return the same way.
In your Fez app, it waits for commands. If it gets a “RED\n” command sent in, it then responds. That might mean turning all other LEDs off then turning the red LED on, or it might mean just turning the RED LED on. Once it does that, it returns “OK\n” to the sender. etc etc.
Both READ and WRITE functions need to exist in both apps, for bi-directional communication. You could have totally one-way comms, but if a command was mis-read at the other end you’d get no feedback - maybe that’s a problem you need to deal with, or maybe not, depends on whether your “Dive” command stops after a certain period of time or if it just keeps going down and down and down and…
They share data because they communicate it over the link, not because of the way you define them in VC.
I have never been successful in having full .NET projects in the same Visual Studio solution as a Micro Framework project. If you encounter problems later this might be the cause.
Many thanks for this - I will purchase the Fez Connect Shield as suggested by Gus and try getting to grips with serial communications as well as trying out the things you have suggested.
Next silly question if I may - Although Gus also recommended that I purchased a Serial-to-USB eBlock for serial-over-USB communications, clearly the Connect Shield has an Ethernet socket which I plan to use in future anyway. Therefore, instead of purchasing the Serial-to-USB eBlock, can I not just simply use an Ethernet Cable between the shield and the laptop for sending/receiving data by the UART-PC method previously suggested with the Fez USB connection for loading/debugging the application via USB with the laptop? In other words, does the Ethernet connection use the same method to send/receive data or would I need to do something completely different to achieve this? Thought I better ask before spending more pocket money!
Ethernet shield uses TCP/IP to communicate. Serial to USB shield uses UART.
Worlds apart !
If you want to communicate over Ethernet, then it’s possible, but seriously it’s a significant learning curve. Since you’re new here, I’d approach it simply and just use serial comms to get started.
I’ve had a look at the ‘USB Client’ Tutorial and noted the CuteDigi RS232 Shield used there - Is this possibly a better (and cheaper) way to achieve the serial connection than going down the Fez Connect Shield with Serial-to-USB eBlock route?
By the way, a little bit of research into RS232 suggests that, providing I keep the baud rate at 9600 or below then I could use up to 50 feet of cable, which is probably just enough for what I am eventually trying to achieve.
RS232 shield is one way to deal with this problem. How are you going to connect your PC to the RS232 cable though? Do you have a DB9 serial port on it? If so, great, but if not then you need to convert that connection back to USB through a FTDI or similar cable (which can be problematic for drivers on the PC side)
The e-block is a great way to go in my view because you end up with a USB port and that’s a much more “universal” serial bus (:)) connection to have on a modern PC.
I was originally thinking connecting the R232 Shield to the Domino then using a converter at the laptop end; but noted what you said about problematic for drivers on the PC side.
All things considered, UART through the Connect Shield and eBlock seem like a good way to get to grips with communicating between Laptop and Domino, but I will need to move away from USB thereafter to allow longer-range communications, given the limitations on USB cabling. I suspect that after mastering UART, although the complexities of it fill me with dread, learning to use TCP/IP through the Connect Shield will be the logical next step. That said, your earlier suggestion about RS485 has not gone totally unnoticed either, given the potential to use a longer tether with an ROV - I presume the software side is exactly the same as RS232, just slightly different hardware?
Another question, if I may: With two USBs connected, once the loading/debugging of my application is complete, am I able to disconnect the loading/debugging cable and still, over the second cable, continue sending control signals and receiving sensor data?
a USB converter just takes your “regular” UART (serial port at TTL levels) and allows it to talk over USB. This means that if you wrote your app to use the UART and it happened to be using just a short cable using TTL, minimal/no code change would be needed to move to using an RS232 shield on the same UART. The same should apply to a TTL - USB Converter.
Think of the debug / power cable as one tether only, and the separate channel for comms (be that UART to USB or UART to RS232 or UART to RS485 or even TCP/IP over ethernet) will still be operating.
