Mindboards

The on-brick menu system does not know how to execute native arm-linux executables. It also doesn't know what a file without any file extension is. I imagine it thought it was a folder and tried to open it (since folders do not have file extensions).

The only way to run a native arm-linux executable is via the BricxCC GUI using the latest (10/7 or later) test release build. Earlier releases did not recognize arm-linux executables within the Explorer tool but would allow you to compile, download, and run the current project via the compiler menu/toolbar options. Now you can launch these arm-linux binaries from the Explorer tool also.

A simple "hello world" app that draws to the screen is below:
I have defined TextOut as a macro here because it is not yet implemented in my libev3 API library.

Add ev3_lcd.c, ev3_command.c, and ev3_timer.c to the Project Manager tool window for your source program (ex_textout.c). Then just press Ctrl+F5 and watch the screen.

John Hansen

thank you.
actually I'm not much wiser yet.

What I see when I open the explorer tool are currently 2 folders and 2 programs: About the folders it's like on a DOS shell I guess.

But in the context menu of the files the "execute" option is disabled in both cases... - why?

outtest is the program with the broken OUT_A, I see no file extension, but if I double-click it runs nevertheless.

hello_world is MY hello_world program just using an ANSI C command (the code I posted above).

Why doesn't this hello_world make anything?
printf is just a simple ANSI C command writing to stdout (which is the EV3 screen), stdio.h is included, so I think it actually had to run...?

Why do I have to use a lcd library for writing to stdout?

Why can't both files be executed via the context menu, but outtest runs by double-clicking?

Why don't both files have any extension (not sure what Linux executables use as an extension anyway, if any at all)?

Finally, I don't doubt that your hello_world program will run as expected, but I expect MY hello-World program to run because it's most-simple C code complying to C standard syntax...

stdout is never ever ever a graphical display in any programming language or operating system (to the best of my knowledge). If you ran a program written in C with printf on Windows what do you think it would do? Would it draw on the window screen or output to a non-visible stdout?

Possibly, the reason for the disabled context menu option is that you did not install yesterday's test release build? Or I still need to work on enabling the menu option properly. One of those two.

If you ran your printf-based hello world executable by entering"hello_world" at a telnet window prompt it would output "hello world" to the terminal window as it should.

John Hansen

aha, ok, that is the reason why: I expected the EV3 screen to act like a stdout device when I use printf.
A telnet window is of no use for me because I always run autonomous programs, never online to a PC (except extremely seldom for debugging) - despite the fact that I don't even know how I might get one.

So will there once be a ANSI printf-like (variable multi-format, variable multi-parameter) graphic screen output command, probably established by function overloading?
(You remember, missing this was already an issue to me for the NXT, and I don't like TextOut and/or NumOut because they don't feature just this multi-parameter overloaded thing. )

I also usually have much more benefit from a text-console-screen than from a grafic screen (for showing tabular overviews of values of interest) - in case of need, can't the ev3 screen be configured as a text console and then will work with ANSI C printf() ?
Maybe it would be possible ( in case of need) to switch between a grafic screen and a text console within a program during runtime (e.g. switching by button presses between showing 1st, tables and 2nd, charts) ?

doc-helmut wrote: So will there once be a ANSI printf-like (variable multi-format, variable multi-parameter) graphic screen output command, probably established by function overloading?
(You remember, missing this was already an issue to me for the NXT, and I don't like TextOut and/or NumOut because they don't feature just this multi-parameter overloaded thing. )

I also usually have much more benefit from a text-console-screen than from a grafic screen (for showing tabular overviews of values of interest) - in case of need, can't the ev3 screen be configured as a text console and then will work with ANSI C printf() ?
Maybe it would be possible ( in case of need) to switch between a grafic screen and a text console within a program during runtime (e.g. switching by button presses between showing 1st, tables and 2nd, charts) ?

Someone would need to develop a console (char device) driver for the LCD screen. If such a device is available, you should be able to fopen() the device and use fprintf(). I am not familiar enough with the ARM port of Linux to know if such a driver exists for the generic case, but I doubt that it would be available for the EV3 currently.

http://en.wikipedia.org/wiki/Linux_console

yes, thx, that was what I was thinking of:
write chars to the screen exactly like write to a file, just like stdio is designed by C.

different options:
a printxy or writexy (x,y, formatstring, variant1, variant2, variant3, variant4, ... )
or a gotoxy(x,y) plus a write( formatstring, variant1, variant2, variant3, variant4, ... )

important to me:
support of all ANSI fprint formatters, like flags, width, precision (\n, \t, -, +, *, #, %3d, %8u, %5.2f, %x...)
support of passing any number of variants (e.g., just 1 or even 10) plus matching formatters.

The screen is already a framebuffer, so the module is there. You just need to compile and enable it.

you mean, you have to recompile the Linux kernel for this? Or just compile a driver source code and copy the driver file on to the flash?
and after that, how can it be "enabled" ?

pepijndevos wrote:The screen is already a framebuffer, so the module is there. You just need to compile and enable it.

@pepijndevos:

doc-helmut wrote:you mean, you have to recompile the Linux kernel for this? Or just compile a driver source code and copy the driver file on to the flash?
and after that, how can it be "enabled" ?

@John Hansen, Xander Soldaat et al.:
what do you think, when is a BCC/C library for sensors supposed to be published? Or is it already available and I just missed it?

My understanding is that you'll just have t compile the kernel module.