I've actually found lots of good information on the internet.
Are you hell bent on learning VB? Personally, I prefer C# since my roots are in C, and C is a way more respected language than Basic or Visual Basic for that matter...
The point I'm trying to make is that I can post some serial port communication code for C# that can literally be implemented in 4 lines of code.
(Of course I'm utilizing the not yet universally supported .NET framework) but Microsoft actually does a fairly decent job of pushing these frameworks via windows update, so my experience in recent time has been good)
Nowadays, Microsoft has information on their knowledgebase with examples written in Visual Basic and C# so I'm sure that if you're more confortable with Basic, you can do it just as easily.
In the .NET framework, there is a SerialPort class, so writing to a serial port (and I don't have my code in front of me, so don't try this verbatim) is done something like this:
Code:
using System.Ports.IO
SerialPort DarrensPort = new SerialPort();
byte tempByte;
DarrensPort.BaudRate = 9600;
DarrensPort.StopBits = StopBits.One; //The number of stopbits is an enumerated data type, its pretty clean actually.
DarrensPort.Parity = Parity.None; //Parity is also enumerated
DarrensPort.Open();
DarrensPort.Write("Hello"); //While you can write a string to the serial port like this, keep in mind that strings in C# have the length of the string as the first character and that will get sent down the port.
DarrensPort.Write(0x55);
tempByte = DarrensPort.ReadByte();
char[] charArray = new char[DarrensPort.bytestoRead];
charArray = DarrensPort.ReadExisting();
I can post up real code when I have it in front of me, but that's basically how it goes.
I'm just now getting into doing native USB stuff, so as soon as I have that figured out I can post some information. From what I understand, USB is A LOT different. Every device has an address, and each device has a certain number of "Endpoints" and you can have multiple channels of data within those endpoints. I haven't dug too deep but I can easily see why it is a preferable method of communication since you can have one channel designated as a data channel with the other being a command channel, rather than having to find clever ways to mix the two like on a serial port.
Login
Register
FAQ
Search
