I did actually jack the delay between readings up by 10 fold (to 10ms or 100ms I
think), but it didn't seem to help. Would it be a simply modification to
change the code to block for acknowledgement, just to see if it is merely a
Also, I'm using the standard 8-N-1 settings, which I assume are default with the
driver? In reference to hardware control, are you referring to the micro side?
TO fit in with the trogdor driver I assume I should have no flow control?
Quoting Brian Gerkey <gerkey@...>:
> On Fri, 21 May 2004, Tim Arney wrote:
> > I've come across a problem in developing a microcontroller which pretty
> > conforms to your trogdor driver (now named "walker" for my purposes). It
> > during the serial comms initialisation the driver feels it isn't being
> > acknowledged, and unfortunately my experience with linux serial
> > is non-existent.
> > Walker connection initializing (/dev/ttyS0)...player error :
> > walker_player.cc:ReadBuf():
> > read() failed: Resource temporarily unavailable
> > player error : walker_player.cc:WriteBuf():
> > failed to get acknowledgement
> hi Tim,
> The "Resource temporarily unavailable" message means that read() is
> returning with errno set to EAGAIN. In other words, you're trying to
> read() a character from the serial port, but there aren't any characters
> there to be read.
> Warning: this kind of problem is very difficult to diagnose remotely,
> especially when the diagnoser (in this case, me) is unfamiliar with
> your hardware.
> Given the tests that you've done, my guess is that the micro does send the
> ACK, but not fast enough. ReadBuf() tries to read the ACK something like
> 10 times, which a small sleep in between each try, and then it gives up.
> I would try increasing the sleep time and/or number of tries.
> > I would like to test the initialisation manually in linux, but have no idea
> > to use the likes of minicom. Is there a really simple way to send the 3
> > characters down the line and see what comes back in linux.
> minicom's your best bet; it's actually quite easy to use, although
> difficult to explain by email.
> Alternatively, you can write a simple C program that does what you want.
> Take the basic initialization sequence from your driver (open(),
> cfsetispeed(), tcgetattr(), tcsetattr(), write(), read(), etc.) and use
> them to build a standalone program that opens the port and inits the micro.
> Debug like this until it works, then port the changes back into the driver.
> > Also, I'm not sure if this is relevant, but the micro's UART is configured
> > run at 9600, so I've changed the two lines from Setup() that specified
> > to:
> > cfsetispeed(&term, B9600);
> > cfsetospeed(&term, B9600);
> > Is this all that needs to be done to reduce the data rate?
> Yep, that's all you need to do. Unless you're also using a parity bit
> or hardware flow control.
UTS CRICOS Provider Code: 00099F