Schwob wrote:
> Thomas,
> 
> this is probably not what you want to hear or read but why writing a
> bootloader in "C". It does not get a lot closer to hardware than a
> bootloader and the programming language of choice should be assembler.
> I do know the basic internal bootloader of the C164 and it is less
> than 50 lines of assembly code. If you want to tell the micro on a
> register level what to do, C is probably the wrong tool!?
> 
> Sorry if you consider this post non-constructive but I have been in
> the embedded software businee for a long time and there are many times
> when to use "C" and a few time when to use assembly language.
> 

[...]

I wrote a secondary loader for C167 in C. It works quite well,
thank you.

I also wrote the Linux code that loads the main program in the
C167. I only mention this because there was ___no___ examplary
existent code. The C167 "community" is "you're on your own".


------------------------------------------------------------
Creepy, Soulless Gigolo for President ? NOT !
---------------------------------------------
THK is one weird, weird something.

On 2004-08-17, Schwob <schwobus@aol.com> wrote:

> this is probably not what you want to hear or read but why
> writing a bootloader in "C".

Nobody said he was.  The "C" code we're talking about runs on a
Linux system and talks to the bootloader via a serial port.

Did you really think his he was using Linux as the OS for a
bootloader?

-- 
Grant Edwards                   grante             Yow!  I like the IMPUDENT
                                  at               NOSE on that car... Are you
                               visi.com            a TEEN-AGER?

Thomas,

this is probably not what you want to hear or read but why writing a
bootloader in "C". It does not get a lot closer to hardware than a
bootloader and the programming language of choice should be assembler.
I do know the basic internal bootloader of the C164 and it is less
than 50 lines of assembly code. If you want to tell the micro on a
register level what to do, C is probably the wrong tool!?

Sorry if you consider this post non-constructive but I have been in
the embedded software businee for a long time and there are many times
when to use "C" and a few time when to use assembly language.

Cheers, Schwob


Thomas Baier <thomas@tho-bai.de> wrote in message news:<412219ed$0$28834$9b4e6d93@newsread4.arcor-online.net>...
> Andrew Jackson wrote:
> 
> >> int comport = openport("/dev/ttyS0");
> > Aside from Gary's comment, do you mean "/dev/ttys0" (no DTR)? Or does your
> > microcontroller have a full set of control lines?
> > 
> >     Andrew
> 
> Hmmm, I tried /dev/ttys0 and got an error while writing, so I think I should
> use /dev/ttyS0 instead. I also tried /dev/cua0, but that doesn't work, too.
> What I expected as I found out that /dev/ttyS0 and /dev/cua0 should be the
> same device, aren't they?
> What exactly is DTR? I google a bit and found out that "the DTR signal is
> generated by your workstation and tells the computer or device on the other
> end that you are ready (a space voltage) or not-ready (a mark voltage). DTR
> is usually enabled automatically whenever you open the serial interface on
> the workstation."
> What does that mean for me? How can I find out if my microcontroller does
> have a full set of control lines? But wouldn't all the other thinks (like
> transferring hex and vm-codes to an existing OS) I'm already able to do
> work, if that is the problem?
> 
> @Gary:
> >>write(comport,0,1);
> >This looks suspicious.
> 
> What exactly looks suspicious at this line? How to do it in the correct way?
> I tried
>         unsigned char handshake = 0;
>         int ret = write(sfd,&handshake,1);
> but that doesn't work, too and as I think it is really the same, isn't it?
> 
> 
> 
> Thanks for your help
> 
> Thomas

On 2004-08-17, Andrew Jackson <alj@nospam.com> wrote:
>
>> [Again, assuming you mean DSR.]

> Mea culpa: I was thinking of the system connected seeing DCD
> being asserted which is really DSR on the modem.

No, DCD on the PC is is DCD on the modem.  It's an output from
the data set and an input to the data terminal.  DCD, DSR and
DTR are three different signals.

> You also used to be able to take a lock on the port by
> creating a magic file but that maybe showing my age ( which is
> also why I referred to /dev/ttys0 and /dev/ttyS0 :-) ).

There still is a convention of applications creating lock files
under /var/lock for mutually exclusive access to serial ports.

-- 
Grant Edwards                   grante             Yow!  How many retired
                                  at               bricklayers from FLORIDA
                               visi.com            are out purchasing PENCIL
                                                   SHARPENERS right NOW??

Well, it was the CRTSCTS option that causes my problem. So I cut it out and
now everything works fine.

Thanks for your help

Thomas

> [Again, assuming you mean DSR.]
Mea culpa: I was thinking of the system connected seeing DCD being asserted
which is really DSR on the modem.

> IIRC, if the CLOCAL flag is not set, read() and write() will
> block waiting for CD.
That's what I understand too. I have some code from '94 which fiddles with
CLOCAL to open and write without waiting for CD.

> IIRC, /dev/ttysN and /dev/ttycuN devices _used_ to block if the
> other one was in use, and an open() on /dev/ttys used to block
> waiting for CD.
You also used to be able to take a lock on the port by creating a magic file
but that maybe showing my age ( which is also why I referred to /dev/ttys0
and /dev/ttyS0 :-) ).

    Andrew

On 2004-08-17, Andrew Jackson <alj@nospam.com> wrote:

> Serial communications are always fun &-). DTR is "Data
> Terminal Ready". Devices like modems can be configured to
> assert DTR when they answer a call.

Nope.  PC's are "data terminals": they control DTR and read
DSR. Modems are "data sets": they control DSR (usually asserted
on power-up) and read DTR.

> On Linux systems, attempts to open /dev/ttyS? will only
> complete the open when DTR is asserted (they "hang" until
> then).

[Again, assuming you mean DSR.]

Not true.  I just opened /dev/ttyS0 and it had DSR inactive:

$ ./showmodem.py /dev/ttyS0
DTR:1 DSR:0 RTS:1 CTS:0 CD:0 RI:0 

DTR is active, but that's because DTR is an _output_ and is
asserted during the open().

> Using /dev/cua0 allows a program to open a serial line without
> considering the state of DTR.

Use of the "cua" devices has been deprecated for many years, and
they aren't even present on modern installations.  If they're
there, they're probably identical to the the ttyS devices.  I'm
not even sure there is a way to make an open() call block
waiting for DSR.

IIRC, if the CLOCAL flag is not set, read() and write() will
block waiting for CD.

IIRC, /dev/ttysN and /dev/ttycuN devices _used_ to block if the
other one was in use, and an open() on /dev/ttys used to block
waiting for CD.

-- 
Grant Edwards                   grante             Yow!  I feel real
                                  at               SOPHISTICATED being in
                               visi.com            FRANCE!

Thomas

http://www.easysw.com/~mike/serial/serial.html

may be helpful to you.

    Andrew

Thomas Baier wrote:
> Hi there,
> 
> I've got a little problem while working on a bootloader for a C164
> microcontroller. The microcontroller gets the data over the serial port.
> I've already implemented some functions that transmit some vmc and hex
> files to the controller while there is a OS running on it. But now I'd like
> to transmit my one bootstrap loader and I've got some problems with the
> serial communication in C. 
> 
> Here's my code to configure the serial port under linux (I'm working on Suse
> Linux prof. 9.0):
> 

Look back in C.A.E a few months for my example on how to really set termios to raw.



-- 
------------------------------------------------------------
Creepy, Soulless Gigolo for President ? NOT !
---------------------------------------------
THK is one weird, weird something.