Raspberry PI and Beaglebone Black.

For other topics related to the FreeBASIC project or its community.
D.J.Peters
Posts: 7776
Joined: May 28, 2005 3:28

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby D.J.Peters » Jul 18, 2013 0:01

Hello dkl, an old problem is back. :-(

Do you remember /examples/dll/dylib.bas or FBSound a hidden cursor in terminal after loading a *.so with FreeBASIC on Linux ?

The same happents with 0.90.0 on ARM now.

Joshy
D.J.Peters
Posts: 7776
Joined: May 28, 2005 3:28

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby D.J.Peters » Jul 18, 2013 2:45

1280 × 720 My C64 emulator written in FreeBASIC on ARM CPU.
Image

1280 × 720 JASC soccer by Pitto.
Image

@dkl and others
your C code generator is perfect !

it run's without any changes, what a fun.

Joshy
Last edited by D.J.Peters on Sep 25, 2017 20:38, edited 3 times in total.
Jonge
Posts: 129
Joined: Jul 17, 2012 17:51
Location: Norway
Contact:

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby Jonge » Jul 18, 2013 8:13

Cool stuff! =)
D.J.Peters
Posts: 7776
Joined: May 28, 2005 3:28

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby D.J.Peters » Jul 18, 2013 8:59

All files uptodate now (libsupc++ was missing in my build undefined references to operator new/delete)

downloads: viewtopic.php?f=5&t=21433

Joshy
Last edited by D.J.Peters on Jan 30, 2014 16:34, edited 6 times in total.
D.J.Peters
Posts: 7776
Joined: May 28, 2005 3:28

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby D.J.Peters » Jul 18, 2013 21:05

1920 x 1080 FreeBASIC on Beaglebone Black Arch Linux
Image

1824 x 984 FreeBASIC on Rasperry PI Arch Linux
Image

Joshy
Last edited by D.J.Peters on Sep 25, 2017 20:39, edited 1 time in total.
D.J.Peters
Posts: 7776
Joined: May 28, 2005 3:28

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby D.J.Peters » Jul 19, 2013 20:08

FreeBASIC implement Sleep() internal with fb_Delay()
it`s a simple wait with timeout comand select().
I don`t know why but it has no effekt on BBB Angstrom Linux.

I must ask one member of the Angstrom dev team.

Joshy
D.J.Peters
Posts: 7776
Joined: May 28, 2005 3:28

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby D.J.Peters » Jul 19, 2013 20:21

D.J.Peters wrote:Hello dkl, an old problem is back. :-(

Do you remember /examples/dll/dylib.bas or FBSound a hidden cursor in terminal after loading a *.so with FreeBASIC on Linux ?

The same happents with 0.90.0 on ARM now.

Joshy
speechless ?

Joshy
dkl
Site Admin
Posts: 3209
Joined: Jul 28, 2005 14:45
Location: Germany

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby dkl » Jul 19, 2013 20:36

It's a fundamental problem of Linux FB rtlib design. It modifies terminal flags upon initialization (global constructor called from fbrt0.o), and restores the flags on clean up (global destructor called from fbrt0.o). Most importantly it disables terminal echoing.

It works as long as there is only 1 rtlib involved, but when loading .so's with dylibload() or directly with dlopen(), then there will be a 2nd rtlib active which can disrupt the 1st rtlib's expectations, especially if the .so will be unloaded after the main rtlib. (then the 2nd rtlib clean up runs after the 1st rtlib's cleanup, making restoring terminal flags impossible)

Nowadays dylibload/dylibclose temporarily reset the terminal flags, so the .so gets to see the original terminal state, and clean up order doesn't matter.

- But anyone using dlopen/dlclose directly, instead of FB's dylibload/dylibclose, will run into the problem.

- Another possible reason is a crash, when rtlib clean up routines aren't being called, and the terminal state isn't reset (this is pretty annoying for debugging, but I know no way to fix it).

- It's also possible that the rtlib init/clean up functions need adjustments if terminals on the ARM Linux systems are too different. (I don't think that's it, but I don't know)

I'd add printf() calls to fb_hInit()/fb_hEnd() and fb_hInitConsole()/fb_hExitConsole() to determine how often and when they're called (ideally it'd be like a proper push/pop stack), and also display the addresses of the global __fb_ctx and/or __fb_con variables to detect duplicate rtlib copies in memory.
ike
Posts: 383
Joined: Jan 17, 2011 18:59

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby ike » Jul 20, 2013 3:37

Thx for answer Joshi!
---------------------------------
I feel exciting hacking days for FB are coming! Did not expect it so early!!
led-bloon
Posts: 33
Joined: Jan 06, 2010 8:16

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby led-bloon » Jul 20, 2013 5:43

Joshy
First off, to you (and not forgetting the devs) - great job!
I think this will give a massive boost to FreeBASIC.
Unfortunately, less knowledgeable cretins like me, will need
help initially.
I have the latest Raspian image loaded, and all updated, on a
Raspberry Pi Model B.
I have installed your latest tar.gz code, no problems. Compiling
a simple terminal based "hello world" no probs!
Tried OpenGL gl_test.bas in Examples folder and the linker fails
(cannot find GL, GLU & glut)
Any ideas what I have done wrong?
Best regards
linux-less led
TJF
Posts: 3474
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby TJF » Jul 20, 2013 8:37

led-bloon wrote:... no probs!
Tried OpenGL gl_test.bas in Examples folder and the linker fails
(cannot find GL, GLU & glut)
Any ideas what I have done wrong?

Nothing you did wrong. Just install the missing libraries. The command

    sudo apt-get install libGL-dev* libGLU-dev* libfreeglut*
outputs a list of similar library names and asks to install them all. Just answer NO and restart the command with the correct names.
led-bloon
Posts: 33
Joined: Jan 06, 2010 8:16

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby led-bloon » Jul 20, 2013 11:15

Thanks TJF for reply, I ended up using synaptics gui package manager

Added libraries (so far):
libgl1-mesa-dev (16 pkgs in total)
libglu1-mesa (probably not needed)
libglu1-mesa-dev
libgui-dev (7 pkgs in total)

gl_test.bas now compiles & links but does not run. I also notice that other examples
require more libs to be added. I will continue to load libs and list them for future
reference.

Once again, thanks (ALL) for this amazing programming language!
linking-led
TeeEmCee
Posts: 250
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: I got my brand new toys. (ARM Linux new target for fbc)

Postby TeeEmCee » Jul 20, 2013 14:29

Cool, it's great to see other people working on an ARM port too, and that a lot of progress has been made! I've been dragging my heels on cleaning up my patches and submitting to dkl for months. If we put our patches together we should be nearly there.

Last month Seth Hetu managed to crosscompile the OHRRPGCE to ARM GNU/Linux and run it on the Raspberry Pi:
http://tmc.castleparadox.com/pics/ohrpi.png

And before that I successfully crosscompiled the OHRRPCE to Android:
http://lists.motherhamster.org/pipermai ... 16456.html

My approach has been to use a crosscompiling toolchain, partially because I didn't realise that -gen gcc was stable enough to compile fbc itself. I'm also using SDL instead of libfbgfx.

I haven't yet ported all necessary changes for Mac OS X support to FB 0.90 but that should be trivial; I'm still using my old Mac fork of FB for now.

dkl wrote:not to mention that there still is some x86 inline asm used by -gen gcc to implement fast & "properly" rounding (the FB way of rounding) for float <-> integer conversions which won't work on other architectures.


I couldn't understand why fbc uses inline assembly for this rather than just calling the C99 rounding functions. However I just checked, and it turns out that GCC only inlines the standard functions if -fno-math-errno is specified, so I guess there is some rationale. Prehaps fbc should pass this argument to GCC? The danger is that a FB program explicitly calls a C math routine and then checks errno. I guess it would be possible to prevent inline in certain cases in this way.
Anyway, here is my patch to switch to the *lrint* functions:
https://sourceforge.net/u/teeemcee/fbc/ ... 8a17f7408/

(Warning, most of the commits on that branch are kludges and not suitable for merging. I hadn't intended to speak up yet.)

dkl wrote:If .ctors and .dtors section are missing then perhaps they're not supported on the platform and missing from the linkers ldscript


The ARM ABIs do not have .ctors and .dtors. Instead AFAIK initialisers are placed in .init_array, and there is no array of destructors defined in the ABI. Instead the initialisers should call the __aeabi_atexi function to register a destructor. Actually I do see an .fini_array section being created, which I think isn't part of the ABI, but is instead processed by a destructor registered by libc. (See also)

Do you know why the rtlib is concerned with these ABI internals instead of just using the GCC __attribute__((__constructor__(priority))) and __attribute__((__destructor__(priority))) attributes? The manual placement of function pointers in .ctors/.dtors breaks both on ARM and on Mac OS X, and I see no good reason to use it on x86 Windows/Linux either.
(Eg: kludgy patch: https://sourceforge.net/u/teeemcee/fbc/ ... 21d02518d/)

However, having said that, a ran into a problem where __attribute__((__destructor__(101))) didn't work on Android: fb_hEnd doesn't get run although it's put at the end of .fini_array. If I remove the priority then it is run, so for now I leave it out.

Speaking about fb_hEnd, I ran into another problem. Because Android doesn't have ncurses I wrapped all of the ncurses code in DISABLE_NCURSES:
https://sourceforge.net/u/teeemcee/fbc/ ... e26468f2c/
I did this by disabling the bare minimum lines of code, so some of the terminal setup and teardown code still happens; a nonsymmetrically amount. Commandline programs run on Android cause the terminal (adb shell) to end up in a screwed up state. Also PRINT causes some garbage to be printed. Either someone familiar with terminal state setting will need to fix this up (and commands like COLOR will need to be disabled), or all the terminal code and commands, not just those depending on ncurses should be disabled. Or you could just not care, since who writes commandline programs on a Unix without ncurses anyway?
TJF
Posts: 3474
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby TJF » Jul 20, 2013 16:24

led-bloon wrote:gl_test.bas now compiles & links but does not run.

I can't test on RaspPi. But for testing my fbc-arm version I got an OpenGL application running on BBB without any tricks.

led-bloon wrote:Added libraries (so far):
libgl1-mesa-dev (16 pkgs in total)
libglu1-mesa (probably not needed)
libglu1-mesa-dev
libgui-dev (7 pkgs in total)

What about the libglut-dev? (It's deprecated, I recommend to use libFreeGlut-dev instead.)

BTW: libgui isn't related to OpenGL, AFAIR.
TJF
Posts: 3474
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla

Postby TJF » Jul 20, 2013 16:30

dkl wrote:not to mention that there still is some x86 inline asm used by -gen gcc to implement fast & "properly" rounding (the FB way of rounding) for float <-> integer conversions which won't work on other architectures.

I couldn't understand why fbc uses inline assembly for this rather than just calling the C99 rounding functions.

The rounding I simply replace by a cast. (When using -gen gcc you needn't care about speed issues, option -O... can do that.)

-gen gcc also uses inline asm for naked functions ...

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 11 guests