Hardware & Devices

19-Aug-07 20:26

Hello,

Wen I sent data to my µC, It reciefd only 1/2 of my data. Al the communication parameters are goed. I try software flow control but it dont works. Can sombody help my plaese.

Luc Pattyn19-Aug-07 23:00

19-Aug-07 23:00

Dag Jelle,

tell us some more about your set-up.

I assume you mean SerialPort.Handshake.XOnXOff? This is how I expect it to work:
- communication is enabled by default
- when one side sends XOFF character, the other side should stop transmitting
(but may take a while, say 5 character times, to understand that)
- when one side sends XON character, the other side is allowed to resume transmission
- it works both ways (you can't do different schemes for transmit and receive)
- each side will send XOFF when its transmit buffer is nearly full; on Windows
the serial driver does that automatically, you should not explicitly send XOFF
or XON
- each side will send XON when its transmit buffer has sufficient room
- each side will receive and interpret incoming XON and XOFF according to the
above, the application will never receive them as data
- warning: if you send data (say binary data) that happens to contain bytes
with the same value as XON or XOFF your communication will fail.

Hope this helps.
Groeten.

Luc Pattyn [Forum Guidelines] [My Articles]

this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google

Jelle De Vos19-Aug-07 23:33

19-Aug-07 23:33

Hallo,

My setting are,

PortName = "COM6";
hComm = CreateFile( PortName,
GENERIC_READ | GENERIC_WRITE ,
0,
0,
OPEN_EXISTING,
0,
0);

if(hComm == INVALID_HANDLE_VALUE)
{
Application->MessageBoxA("Kan COM Poort niet openen !\n"
"Neem de kabel uit de poort en\n"
"plaats hem vervolgens terug.",
"Error",
MB_OK | MB_ICONSTOP );
Form6->Close();
}
else
{
dcb.DCBlength = sizeof(dcb);
if(!GetCommState(hComm , &dcb))
{
Application->MessageBoxA("Kan Setting COM poort niet lezen !\n",
"Error",
MB_OK | MB_ICONSTOP );
CloseHandle(hComm);
Form6->Close();
}
else
{
dcb.BaudRate = 9600;
dcb.fBinary = TRUE;
dcb.fParity = TRUE;
dcb.fOutxCtsFlow = FALSE;
dcb.fOutxDsrFlow = FALSE;
dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fDsrSensitivity = FALSE;
dcb.fRtsControl = RTS_CONTROL_DISABLE;
dcb.fTXContinueOnXoff = FALSE;
dcb.fOutX = TRUE;
dcb.fInX = TRUE;
dcb.fErrorChar = FALSE;
dcb.XonLim = 20;
dcb.XoffLim = 20;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
dcb.XonChar = 0xFF;
dcb.XoffChar = 0xFE;
if(!SetCommState(hComm , &dcb))
{
Application->MessageBoxA("Instelling COM poort fout !\n",
"Error",
MB_OK | MB_ICONSTOP );
CloseHandle(hComm);
Form6->Close();
}
}

I dont now of this works, I'm just a beginner.
I onderstand the flow control not so good. Wen the µC send a XOFF charactar, must I read this on my program of read this autometalic the XOFF character. Is my setting good of not good. I don't now.

If you Netherlands, you may me in the Netherlands.
Thanks,

Jelle
Groeten

Luc Pattyn20-Aug-07 0:02

20-Aug-07 0:02

Hi Jelle,

your settings seem acceptable, I have a few comments:
- I am not sure what dcb.fParity = TRUE; does when dcb.Parity = NOPARITY;
I would set it false just to make sure no false parity errors can occur
- dcb.XonChar = 0xFF; dcb.XoffChar = 0xFE;
that is a peculiar choice of characters, normally one uses XOFF = 0x13 (CTRL/S)
and XON = 0x11 (CTRL/Q)
your choice could work also, provided the other side uses the same characters !

you said earlier you were receiving half of the characters, care to explain that
a bit?
and what is on the other side of your serial cable?

PS: yes we could have this conversation in Dutch, but the forum police here
does not like us to do that, and other people might be interested too.

groeten

Luc Pattyn [Forum Guidelines] [My Articles]

Jelle De Vos20-Aug-07 0:22

20-Aug-07 0:22

Hello Luc,

I try it in Englich. This is my code from sending text to my µC. I main the half of characters :

I want to send "versturen van data naar microcontroller" and the µC recievd only "versrn a mcr ".
I have no problem with a other terminal. I think that it maby the programcode is. Hier is my code to transmitting data.

bfData = "Versturen van data naar microcontroller.";
unsigned long dwNumberOfBytesWritten;

if(!WriteFile(hComm , bfData , 30 , &dwNumberOfBytesWritten , NULL))
{
Application->MessageBoxA("Fout bij het versturen van de data !",
"Error",
MB_OK | MB_ICONSTOP );
CloseHandle(hComm);
}
else
{
Edit1->Text = dwNumberOfBytesWritten;
}
}

Thanks,
Jelle.

Luc Pattyn20-Aug-07 0:41

20-Aug-07 0:41

Hi Jelle,

my first impression is the problem is on the microcontroller side; I think
it can not keep up with the transmission speed. When you use a terminal instead
of your app, you send characters as fast as you can type, which is only a few
per second; your app would send that string in less than a second.

Is you microcontroller using interrupts to receive serial characters?
is there an operating system?
does it need a task switch for every incoming character?
or is there a buffer that could store an entire message (whatever that means,
maybe something ending on CR or LF), and just signals the main program once
the entire message has been received?
what are you programming your uC in? assembly, C? what type of uC is it?
do you disable interrupts for a long period of time?
or do you have interrupt priorities, with some higher priority interrupt handler
temporarily disabling your serial receive handler?

you may try the following:
- reduce the baud rate
- add more stop bits

Normally there should be no problem receiving data at 9600bd, that is assuming
you did everything right. If the receiver is say a STAMP, programmed in Basic,
then things may go wrong because too many CPU cycles get waisted in order to
process a single incoming character.

groeten

Luc Pattyn [Forum Guidelines] [My Articles]

Jelle De Vos20-Aug-07 0:59

20-Aug-07 0:59

Hello Luc,

Type µC is AT90S2313 or ATMEGA8535. Assemble is in C. nl : CodeVision. I do the follown. I recieved one character and place it in de eeprom, then I recieved the next character. That all with the USART from the µC. It is possible that the clock-cycles for this meby to slow. I tray with a slower bautrate. wil se.

Jelle.

Jelle De Vos20-Aug-07 1:07

20-Aug-07 1:07

Hello Luc,

I have my setting chance in Bautrate = 300 and stopbits = TWOSTOPBITS. It works.

Thanks for everiting. If you have a problem. mail my.
Jelle.

Luc Pattyn20-Aug-07 1:15

20-Aug-07 1:15

Hi Jelle,

programming an EEPROM cell takes a while, could be from 10 microseconds to
several milliseconds, really depends on specific hardware.
If you did the code to program, you had to insert either a fixed delay, or
a loop testing some READY bit; of course if you use a library to do it, you
may not be aware of it (the documentation may tell you).

If the EEPROM is also holding the code that is executing, then interrupts would
(have to) be disabled I guess.

Maybe the better approach is to have a buffer in RAM, collect a number of bytes,
then program all of them (assuming programming N bytes is faster than N times
programming 1 byte, depends again on hardware). If code is not running
from same EEPROM (hence interrupts enabled), you may use two "ping-pong" buffers,
one buffer gets programmed to EEPROM while the other receives new bytes;
then switch their roles. Doing so would enable communication at 9600bd while
programming! If you are new to this all, it may be too hard to get is all right.

Even with your current set-up, you may try to figure out (from documentation
or experiment) what the highest baudrate is for things to work reliably.
300 baud is really slow if you have say several KB to handle !

greetings

Luc Pattyn [Forum Guidelines] [My Articles]

Luc Pattyn20-Aug-07 1:45

20-Aug-07 1:45

Hi Jelle,

since you are transmitting binary data that goes into EEPROM, I assume it is code,
hence all byte values can occur, including the ones you have selected for XON and
XOFF.

If your microcontroller has dataflow handshaking installed, this may go wrong
when it receives these values, intended as data bytes, but interpreted as flow
control characters.

As far as I know there are only three correct approaches to solve this:
1. don't use flow control at all while transmitting binary data
(so set dcb.fOutX and dcb.fInX false).
2. use a protocol, where your bytes are transmitted in another way, that does
not conflict with the selected XON/XOFF characters; several of them are based
on hex, meaning you send two characters to represent one byte. Examples are
"Motorola S-records" and "Intel Hex".
3. use hardware handshake (that's based on some "control lines" such as "RTS" and
"DTR", to be found on some of the connector pins of your serial port.
Of course this requires you change the settings on the PC side, and the code
on the microcontroller side.

Anyway, some kind of protocol would be nice to have, so you do not just send
the data to the microcontroller, but you actually have a conversation, so the PC
keeps informed as to "everything goes well" or "failed to program EEPROM" or
"Done" or whatever.

Your original problem was having "character overrun", that is receiving a
character while the previous character was not yet been read. There must be an
error flag for that in one of the control registers, possibly also an error interrupt.

Hope this helps you to better understand how it works, and how you can improve
the robustness of your communication.

Greetings

Luc Pattyn [Forum Guidelines] [My Articles]

Jelle De Vos20-Aug-07 1:55

22" Monitor Recommendation

20-Aug-07 1:55

Luc,

The max bauts I test is 1200 bauts. It works and I do not sent Kb. I try with programming my interrups from the µC for using faster bauts. Now I do it with this. It's fast enof.

Thanks, I let you now of it is works.

Jelle.

martin_hughes18-Aug-07 9:30

martin_hughes

18-Aug-07 9:30

I recently bought a Viewsonic Optiquest Q22wb monitor. It was fairly inexpensive, so I wasn't expecting the excellent results it gives.

The screen is bright, sharp and the colour is exceptional - and that's with the VGA connector - hook up via DVI and it get's even better. The viewing angles are also pretty good.

It's a bit sparse on the optional extras - there are no usb ports or built in speakers, but that doesn't really bother me as I've never had a monitor with them.

In fact the only bad thing about it was that it had a single stuck pixel - happily this was quickly resolved by this handy utility: http://udpix.free.fr/[^]

Recommended.

"It was the day before today.... I remember it like it was yesterday."

-Moleman

microcontroller to use ?

shaikhooo17-Aug-07 14:28

shaikhooo

17-Aug-07 14:28

i m planning for usb oscilloscope for pc .
Can someone tell me which micro controller i use, and how to get started?
decided to use C# on pc side.

Luc Pattyn17-Aug-07 14:42

17-Aug-07 14:42

Aha, we meet again.

If you want to build an oscilloscope that takes analoge inputs through an
external peripheral, you will need a lot of technologies, including:
- microcontroller software
- analog electronics
- Windows driver
- Windows app

Probably the most important decision is on interfacing; how will your scope
present itself to Windows? i.e. where in "Device Manager" should your device
appear, will it mimic some other device (and piggy-back on its driver), or
will you have to develop your own driver (a major undertaking)?

And a second decision is how to solve real-time problems; whatever the
maximum frequency, resolution, number of channels, your microcontroller will
need a lot of memory, since you will not be able to sink all data to USB in
real-time.

Once you solved these issues, the actual choice of microcontroller is
not that important, pick any one you feel comfortable with; make sure you
get a built-in USB port and some library support for that.

Have you looked at commercially available solutions? They may inspire you.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Alexander ^M.,19-Aug-07 8:16

Alexander ^M.,

19-Aug-07 8:16

never heard about a micro controller with a .net virtual machine. most micro controllers support assembler and/or c only.

Don't try it, just do it! Wink | ;-)

Luc Pattyn19-Aug-07 8:48

19-Aug-07 8:48

To build an oscilloscope, or some other real-time apparatus, the OP will need
both a PC (running .NET would be nice), and some dedicated hardware that needs:
- to interface to the PC, hence best a microcontroller (yes, with asm or C)
- to take care of real-time aspects, hence best a lot of memory

The smallest .NET machine would be a PDA, probably too expensive and lacking
adequate I/O facilities and real-time capabilities. (It could be nice tho
as the GUI part of the scope!)

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

LaCie Ethernet Disk [modified]

LittleYellowBird20-Aug-07 4:44

LittleYellowBird

20-Aug-07 4:44

When choosing a micro the first task is to work out what you want it to do. Many have built in A to D convertors which you will need (the resolution would not be great but it would get you started).

Also, you need to consider the interface. You can get micros with a USB interface built in and this would make life a bit easier for you. Alternatively, you can use any micro and add a USB interface chip.

FTDI http://www.ftdichip.com do a range of modules which I have tried and got running pretty quickly, you can connect them to your micro using a parallel port or a UART and as well as the chips they sell little modules which get your system up and running very fast. At the PC end I have used both a virtual com port approach and the dll they supply without too much difficulty.

Another big consideration is what development kit is available in your price bracket. Personally I have used the Microchip PIC family alot lately and they have masses of devices and cheap tools. I should also mention Zilog Z8 and the Thompsom ST6 family which are good starter devices.

Good luck, regards Smile | :)

Ali

t4ure4n13-Aug-07 23:21

t4ure4n

13-Aug-07 23:21

Hi Guys
This Question is for any one who has used LaCie Ethernet Disk before

I have 1TB LaCie Ethernet Disk (Gigabit Ethernet - Shared Hard Drive).

I wanted to rest this disk to a different name and IP address but IPConfigurator; a utility provided by LaCie to do this does not do it.
That is you can view the changes made in IPConfigurator but when you connect it to the network its is not recognized by the new name and IP but with the old one.

Any one knows how to do this or at least factory rest it.

-- modified at 5:27 Tuesday 14th August, 2007

o O º(`'·.,(`'·., ☆,.·''),.·'')º O o°
»·'"`»* *☆ t4ure4n ☆* *«·'"`«
°o O º(,.·''(,.·'' ☆`'·.,)`'·.,)º O o°

How to send/receive data from/to an outside source

High0ctane13-Aug-07 6:44

High0ctane

13-Aug-07 6:44

Hi there. I'm pretty new to coding, I'm trying to (slowly but surely) design a program to receive data from a chassis dyno that I'm fabricating. I'm guessing I'd best use the serial port, from what I read using USB 2.0 is pretty much harder. I'd be putting together a microsystem using either a microprocessor or my own electronics. I'd have to transmit data like engine rpm, air/fuel ratio, dyno drum speed etc. Is there a way to read analogue signals with a pc or can it only use digital signals?

If anyone has some good links or books on communicating with the outside world using a pc, I'd love to have some. Thanks a bunch!

Brian

Yup, I'm a NEWB

Re: How to send/receive data from/to an outside source

Dan Neely13-Aug-07 7:07

Dan Neely

13-Aug-07 7:07

The serial/parallel ports are digital only. If you want/need to send analog output you'd need an external box to take and convert the digital commands into analog signals. Assuming you can get one inexpensively a programmable USB control box would probably be the way to go since legacy ports are in the process of being phased out of new PCs. Programming on USB directly isn't easy since you need to write a device driver to talk to a device on the port instead of being able to directly access it.

--
You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer

Re: How to send/receive data from/to an outside source

Luc Pattyn13-Aug-07 7:17

Re: How to send/receive data from/to an outside source

13-Aug-07 7:17

Hi,

you can add an analog/digital convertor to your PC but that has a lot of
disadvantages; for one it ties your solution to your PC, you can not easily
move it to another PC, a laptop, etc.

The better solution is to encapsulate the required functionality in a
"peripheral". It could be built around a microcontroller that has both an
A/D convertor and an RS232C interface on board. Of course such device needs
its own code, it may require assembly or C code (it would not support the
.NET languages !)

If you are in control of the details of command/response coding,
you can make sure each of them use readable/printable characters only AND
have a single common terminator (such as a newline character),
making it a lot easier to communicate (and debug!).
If the required bandwidth is low (only a few tens or hundreds of chars/sec),
and if the real-time requirements are easy (you don't need the PC to react
within a few tens of milliseconds), then the serial port is easy and in fact
a very good way for interfacing a peripheral to a PC.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

High0ctane13-Aug-07 7:50

High0ctane

13-Aug-07 7:50

Hi,
I have to read every output (sensors on the dyno) about once every 50ms. Is serial fast enough?

How bout any books about interfacing with serial and/or USB?

Thanks!

Yup, I'm a NEWB

Re: How to send/receive data from/to an outside source

Luc Pattyn13-Aug-07 7:57