On Sun, Apr 12, 2009 at 03:14:38PM +0200, Robert Brusa wrote:
> On Sat, 11 Apr 2009 18:44:34 +0200, Sergei Gavrikov
> <sergei.gavri...@gmail.com> wrote:
>
>> On Sat, Apr 11, 2009 at 06:15:50PM +0300, Sergei Gavrikov wrote:
>>> On Sat, Apr 11, 2009 at 12:42:50PM +0200, Robert Brusa wrote:
>>> > Hi
>>> > When running the example serial.c that comes with ecos-3.0, I get no
>>> > output on the serial i/f of my AT91SAMX512-based board. I am using a
>>> > configuration where I have enabled hardware drivers for ser0 and
>>> ser1 and
>>> > disabled ser2 (see attachment).
>>> >
>>> > serial performs a lookup for /dev/haldiag - and fails. In fact, this
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Ups, I missed this. Of course it will be, because, you have disabled
>> *SERIAL2 == your HAL's /dev/haldiag (read the below's explanations)
>> there is
>>
>> cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL2 { user_value 0 };
>>
>> in your ECM.
>>
>> My assumes the below were based on that what SERIAL2 device is alive.
>> But that is not wrong.
>>
>>
>> Sergei
>>
>>
>>> > string is not present in my configurations ecc-file. What I find there
>>> > is: /dev/ttydiag. But when changing haldiag to ttydiag, the result
>>> is the
>>> > same: No output on ser0 or ser1.
>>>
>>> Hi
>>>
>>> Now I knew your target's name and I can know what is it. So, it has 3
>>> serial channels (I did not know about). According HAL, diagnostic and
>>> debug channels are asigned with channel 2 (as you named it "ser2"). So,
>>> all diagnostic output, by default, will be appear on the diagnostic
>>> channel or at the "ser2", won't it?
>>>
>>> // it should appear at "ser2"
>>> diag_printf("test string
");
>>>
>>> Unfortunatly, I can only guess what you want to have. Let's assume, that
>>> you want to see the output the above on "ser0". In this case you have to
>>> change
>>>
>>> cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
>>> user_value 0;
>>> }
>>>
>>> for "ser1" it will "user_value 1" (by default it is equal 2 == "ser2").
>>>
>>> Let's look on examples/serial.c again and your ECM options. I noted that
>>> you do not tweak the option the above.
>>>
>>> serial.c:83:printf("Starting serial example
");
>>>
>>> According the attached ECM, your printf() will print on the device
>>>
>>> cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
>>> user_value ""/dev/ttydiag""
>>> };
>>>
>>> So, printf will be to use diagnostic channel ("ser2"), becuase, the
>>> above option points on "/dev/ttydiag". Where did you expect the output?
>>> It seems for me, it will appear on "ser2".
>>>
>>> serial.c:85:err = cyg_io_lookup( "/dev/haldiag", &handle );
>>>
>>> The "/dev/ttydiag" is a device name (a generic diagnostic device name).
>>> By default, when an eCos cdl_componet CYGPKG_IO_SERIAL_TTY_TTYDIAG is
>>> enabled, it uses itself a layered device with name "/dev/haldiag". Look,
>>> please, for a reference at
>>>
>>> /opt/ecos/ecos-3.0/packages/io/serial/v3_0/src/common/tty.c
>>>
>>> and you will see how the device's names are assigned with the layered
>>> devices (dep_names) acording CDL options.
>>>
>>> The first and non-layered `/dev/haldiag' device exactly is
>>> /opt/ecos/ecos-3.0/packages/io/serial/v3_0/src/common/haldiag.c
>>>
>>> Note: about a DEVTAB_ENTRY internals you can find information by a link
>>> the below (look at the chapter's name as on "how-io-driver-works")
>>> http://ecos.sourceware.org/docs-latest/ref/io-how-to-write-a-driver.html
>>>
>>> Well, I knew that "/dev/haldiag" (with your settings) is "ser2".
>>>
>>> > On the other hand, when changing to /dev/ser0 or /dev/ser1, I get this
>>> > particular line on the ser0 or ser1 interface - as expected. But all
>>> > other output generated by printf-statements still is "unvisible".
>>> Is this
>>>
>>> Of course, particular, I can assume that that line
>>>
>>> "serial example is working correctly!
";
>>>
>>> will appear on "ser2".
>>>
>>> And when you changed CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE (/dev/ser0,
>>> /dev/ser1), your printf's will be there, but not on /dev/haldiag.
>>>
>>> Now you knew what "/dev/ttydiag" is by default, and I not saw that you
>>> assigned default console with another device. So, printf will just use
>>> haldiag_putc (=HAL_DIAG_WRITE_CHAR) to out strings on "ser2". And it's
>>> no deal that you enabled cdl component CYGPKG_IO_SERIAL_DEVICES.
>>>
>>> Well, on the not-a-reduced targets (with GDB support) those printf's, by
>>> default, all will appear just in GDB (on diagnostic | debug channel).
>>>
>>> So, if you know where you want to see the diagnostic output, specify
>>> that with cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL.
>>>
>>> I hope, that was it.
>>>
>>> Sergei
>>>
>>> > a bug or do I get something wrong?
>>> > Robert
>>>
>>>
>>> > --
>>> > Before posting, please read the FAQ:
>>> http://ecos.sourceware.org/fom/ecos
>>> > and search the list archive:
>>> http://ecos.sourceware.org/ml/ecos-discuss
>
> Hi Sergei
> thank you for your help. Following your script I achieved that I get the
> following output on uart1:
> ---------------------
> Starting serial example
> Found /dev/haldiag. Writing string....
> serial example is working correctly!
> I think I wrote the string. Did you see it?
> Serial example finished
> ---------------------
> An this is absoutely great. what I want at the end is to use:
> serial_0 for efficient bidirectional (interrupt driven) communication
> serial_1 should act as my console-device (also efficient)
> serial_2 is not wired on my board, but I possibly could use it to access
> the output to serial_2 through my JTAG debugger. I will have to test
> this.
>
> What I do not yet understand: Is diag_printf in my current configuration
> (see attachment) now going to serial_2 using an at91-specific efficient
> driver or still the polling write routine? Or none of both, because there
> is a conflict?
>
> I coninue testing. I think much of what I want to achieve is now working.
> It looks good. Thanks
> Robert
Robert, as _I_ understand/understood
eCos offers 1) a non-interrupt driven diagnostic output on UART, it's a
wellknow diag_printf() and diag_*() routings. I look on it as on atomic
hal_diag_led() :-), it can be placed even in ISRs. It uses a polled
mode. It is a very useful thing on a debug stage. By defualt, it is
serial_2 for your HAL. Every diag_printf() in your program used it.
Once again, by default it is polled raw output and blocking input.
2) the interrup-driven serial drivers: 1st kind of them is a raw serial
driver, 2nd kind is a tty-like serial driver (a bit overhead let us to
have an ability to edit the entered lines), and 3rd -- the termios-like
serial drivers (there is more overhead there, but it is a portable way
to manage the terminals);
I can assume that your needs are to get the raw serial driver on the
serial_0 ("/dev/ser0"). I assume it will be used, for example, either
for PPP or SLIP interface and the tty-like serial driver on serial_1
("/dev/tty1").
First, you need to enable CDL component
cdl_componet CYGPKG_IO_SERIAL_DEVICES {
user_value 1;
}
to get working the interrupt driven serial drivers. I also assume that
you want to get non-blocking I/O for those serial ports. That's it
cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
user_value 1;
};
Think about any king of flow control if you need to have it.
cdl_component CYGPKG_IO_SERIAL_FLOW_CONTROL {
...
The above is your decision. At the least you can have XON/XOFF, a HW
frow control is hardware depended (I do not know what is your UARTs).
But, my question is, Do you need it? Be careful with flow control.
For serial_1 enable the below component (it will be your /dev/ser0):
cyg_io_lookup("/dev/ser0", ...);
cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL0 {
user_value 1;
};
Look then on other options CYGNUM_IO_SERIAL_ARM_AT91_SERIAL0_* and
change that what you need (e.g., you will want to increase default
buffer size).
Now the serial_1.
cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL1 {
user_value 1;
};
Look then on other options CYGNUM_IO_SERIAL_ARM_AT91_SERIAL1_* and
change that what you need.
As I could understand, you tnink about serail_1 as TTY-like console, so,
enable the option the below: cyg_io_lookup("/dev/tty1", ...);
cdl_component CYGPKG_IO_SERIAL_TTY_TTY1 {
user_value 1
};
And I assume that you do want to see ptintfs on this console, doesn't
you?
cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
user_value "/dev/tty1"
};
I guess that printf ("hello, world!
") will appear on your serial_1.
And I assume that fgets(buf, MAXLINE, stdin) will works too for the
serial_1.
If you plan to make some pice of a termios code to spin on serial_1, you
will need to enable the component
cdl_component CYGPKG_IO_SERIAL_TERMIOS {
user_value 1
};
and then you can try to "open" it as cyg_io_lookup("/dev/termios1",
...);
And at the end about diagnostic port (serial_2). To get a polled mode
only you can disable
cdl_component CYGPKG_IO_SERIAL_ARM_AT91_SERIAL2 {
user_value 0
};
And then you won't be able "open" (cyg_io_lookup("/dev/haldiag", ...);
You saw it already. That device wraps a non-layered TTY-like
"/dev/ttydiag". BUT, you will be able to call diagnostic "atomic"
routings (e.g. diag_printf) and it's output will be appear on serial_2,
If you want to have TTY-like ability (line buffered output) on HAL
diagnostic, enable the component the above; and then examples/serial.c
will be able to manage "/dev/haldiag", you saw that too.
If you have not the connector on serial_2, it won't be useful for you.
And it is bad, because eCos sources use a lot the diagnostic routings
(assertions fails, debug messages, etc.). It seems for me that you have
to up a few configurations on a debug stage. To get work diagnostic
either on serial_0 or serial_1 (remember about console channel #).
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL {
...
Note: Your friend at configure stages
cdl_option CYGDBG_IO_INIT
But, all outputs will appear on diagnostic channel! By the way, I
remember someone on the list told about "a redirection" diagnostic
output into an area of RAM. Look what HAL_DIAG_WRITE_CHAR is. And surf
throught out the list.
IMHO, it is useful to enable cdl_option CYGBLD_IO_SERIAL_EXTRA_TESTS and
look at those sources and play with the tests.
Well, everyone (I'm not exception! :-) dreams about:
$ yes | make config
to get a working linux kernel for own needs, but, in the most cases it
is not possible. IMHO, eCos is the same: ecosconfig new <target> is
just a start...
Good luck,
Sergei