|
It's pretty straightforward, but you'd do better to look it up on MSDN or even pinvoke.net, there's articles on it here on code project, also. I think Nish has one where he refers to it as IJW ( it just works )
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Hi,
I once looked into AVR, but ended up using a small Microchip PIC instead
(with assembly code).
And did serial comm with that, long before .NET emerged.
I will revamp that project pretty soon, this time with .NET !
if you can control the target by sending commands over a serial line,
if you know the command language (syntax and semantics),
if the number of bytes per second is reasonable (less than say 500),
if your PC has a serial port that is compatible with your target's,
if your cable is set up correctly (null modem needed?),
then you could simply write the PC-side of the app using C# and
use the SerialPort class for communication.
The SerialPort class offers port initialization, plus elementary read and
write operations (both in binary in case you need bytes, or in text characters
if your commands are "printable"). If text, be careful about text encoding,
C# uses Unicode characters (which are 16-bit), your target probably uses
8-bit ANSI (or 7-bit ASCII), so you may need an explicit Encoding.ASCII
If your command language is built from printable text, I would advice you test
your hardware set-up first, using a terminal emulator such as HyperTerminal.
If not, you need to start programming right away and would be best to try a
simple and harmless output command first, something that would make your
AVR show some reaction without being time critical or dangerous.
Then you could try to receive something; hopefully your target sends
something when it starts up, so you would catch that and show it on a Form or
Console. Your first receive attempt might use a synchronous read; final code
would require you switch to asynchronous operation, i.e. you install
a handler that gets triggered by a DataReceived event (soemwhat similar to an
Interrupt Service Routine); be careful, the event runs on a separate thread, one
that cannot reliably operate on GUI Controls, you would need Control.Invoke()
for that.
Have fun !
|
|
|
|
|
thnx for the info yes my commands are not printable iam trying to making it simple for mapping the values ..and the baud rate also its simple but any code snippet where i can get a little more idea. thnxx..
|
|
|
|
|
The CodeProject site hosts several articles on serial port and C#, such as
this one[^].
It uses printable text, which is not what you need, but it shows you how to
open a port, how the asynchronous DataReceived event works, how to use Invoke(),
etc.
You could study it, and you might even decide to modify it to make it work with your
binary command language, so you could use it to get accustomed to the
communication stuff before doing your real application.
|
|
|
|
|
well i do see it i understood the code one thing is confusing me that wht did u meant exactly by printable values by seeing this i was thinking somthing different before can u elobrate please i will be really thankful..
|
|
|
|
|
When setting up a communication (or a storage) you have to make a basic decision
as to how represent the commands or data.
1. one way is using text (say ASCII characters); the advantage is you can read
it easily, you can save it to a file, then edit it; you can use an RS232C spy
to watch the characters on the cable, you can use a terminal emulator, etc.
The disadvantages are you need more bytes (since not all bit combinations
are allowed, e.g. ASCII printable is only 0x30-0x7E), and you must encode
(translate number to chars) and decode (translate chars to number).
2. the other way is using bytes simply as binary bit patterns, as you have
choosen to do. In this case, you must provide your own command encoder/decoder,
so a general-purpose tool such as a terminal emulator cannot help you in the
debug stage.
As far as SerialPort class goes,
For 1. you typically would use the methods Write(string), ReadChar, ReadLine;
for 2. you would use Write(byte[]), ReadByte, Read.
|
|
|
|
|
thank u for all the info Luc...i just wanted to add tht is these are the only steps that i hvae to follow...or any other instructions also ..thanks regards
|
|
|
|
|
You're welcome.
I can not possibly predict everything you might need in your further development,
that is part of the planning (guessing?) stage. You are in the best position
to know the requirements, the context and the status...
|
|
|
|
|
i think i mail tht java code also ..exactly tht will be in C# but u meant ..tht the code for controlling the servos will be in tht also right..when we open port then we pass on the intructions ..for the movement right..something like tht..or not..
regards
|
|
|
|
|
|
in short how we move servos from software applications  like do we have to map the valus for 0-255 or 0-128 depending on the baud rate how ? please explain
|
|
|
|
|
If your target contains one (or more) servos, you should provide a command to
select the servo and give it a new position.
As explained before you either use textual commands (easier to use and debug,
slightly more difficult to receive and decode) or binary commands.
That's up to you.
The baud rate is not really relevant, except for one thing: you need sufficient
bandwidth to pass all the information in time (you can not send 100 bytes per
second over a serial line that operates at 110 Baud !) If you need to download
(PC-to-target) a lot of data (say a speed ramp-up/ramp-down table) or maybe the
target's code itself, then you might want to use a relatively high baud rate...
Please keep in mind that receiving serial data on PC-side is somewhat tricky
(independent of baud rate): a PC is very busy with a lot of processes and threads,
so it is not always ready to capture incoming data. Therefore I recommend you
limit the target-to-PC communication to a few messages per second, and avoid
them to be time-critical.
This also means that low-level algorithms (such as move until micro switch
gets closed) are best handled by the target in autonomous mode, without
involving the PC (so PC says "move till switch closes", target does whatever
it takes to do that, then target reports "OK, did it, switch now closed".
Hope this helps, and fits the plans you have.
|
|
|
|
|
yes thnx alot i will ..follow basic ..as much firstly if its done if i find any problems i will reply u in one day or 2 thnx ..
|
|
|
|
|
I need to write functions that will allow the user to change network settings ( we are doing this as part of an Embedded XP project and need to provide our own interface. )
Can anybody direct me to where I can find documentation on how to do this?
I realize I'll have to write the code myself and probably end up calling Windows APIs but I can't find anything helpful out there.
TIA - Jeff.
|
|
|
|
|
|
Thanks for your help. That worked great. Now on to my next problems:
Getting/setting the proxy settings
Setting the account a machine will log in as.
TIA - Jeff.
|
|
|
|
|
Hi,
can anyone help me , how can i change title of the folderBrowserDialog in c# .
thanx.
-- modified at 13:57 Thursday 5th July, 2007
Praveen Sharma
|
|
|
|
|
|
I guess you will have to try and use P/Invoke to call the Win32 function
SetWindowText() in user32.dll
|
|
|
|
|
Use SetWindowText
The SetWindowText function changes the text of the specified window’s title bar (if it has one). If the specified window is a control, the text of the control is changed.
but to use this function u have to use some other functions too
i suggest u to download and install "API-Guide" and look windows functions in it
|
|
|
|
|
Hey everyone,
This may be a very simple (hopefully it is) question and answer, but I'm having trouble figuring this one out.
I want a SaveFileDialog and an OpenFileDialog to start in a chosen directory. Seems simple enough, I'll just create the directory in case it doesn't exist, and then set the InitialDirectory property of the dialog -- but for some reason it's still opening in the last directory that I had browsed to in a previous dialog.
Here's the code:
private const string ATF_FILTER = "AOI Template Files (*.atf)|*.atf";
private const string C_SAVE_DIRECTORY = @"./Saved Templates";
private void Save_Click(object sender, EventArgs e)
{
Directory.CreateDirectory(C_SAVE_DIRECTORY);
SaveFileDialog diag = new SaveFileDialog();
diag.InitialDirectory = C_SAVE_DIRECTORY;
diag.DefaultExt = ".atf";
diag.Filter = ATF_FILTER;
if (diag.ShowDialog() == DialogResult.OK)
{
DrawBox.SaveTemplate(diag.FileName);
}
}
Any idea what could be going wrong?
Thanks,
Phil
|
|
|
|
|
PhilDanger wrote: Any idea what could be going wrong?
Relative path perhaps? As someone pointed out in the last few days, best practice is to use absolute paths.
|
|
|
|
|
Turns out it works correctly when I switch it from a forward slash to a backslash:
private const string C_SAVE_DIRECTORY = @".\Saved Templates"; //works!
Could you elaborate a bit on the benefits of using an absolute path over a relative path? My intuition and previous web experience tells me that using an absolute path would not be the best solution, but perhaps times have changed.
Thanks,
Phil
|
|
|
|
|
PhilDanger wrote: benefits of using an absolute path over a relative path?
Well they are "absolute". Relative is subject to the Current Directory so it's only as good as a guarantee that it hasn't changed or is not something other than what you expect it to be.
|
|
|
|
|
Hi,
it depends on FileDialog.RestoreDirectory which by default is false, but
it seems you want it to be true.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
