Raspberry PI and Beaglebone Black.
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
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
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
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
1280 × 720 My C64 emulator written in FreeBASIC on ARM CPU.
1280 × 720 JASC soccer by Pitto.
@dkl and others
your C code generator is perfect !
it run's without any changes, what a fun.
Joshy
1280 × 720 JASC soccer by Pitto.
@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.
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
Cool stuff! =)
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
All files uptodate now (libsupc++ was missing in my build undefined references to operator new/delete)
downloads: http://www.freebasic.net/forum/viewtopi ... =5&t=21433
Joshy
downloads: http://www.freebasic.net/forum/viewtopi ... =5&t=21433
Joshy
Last edited by D.J.Peters on Jan 30, 2014 16:34, edited 6 times in total.
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
1920 x 1080 FreeBASIC on Beaglebone Black Arch Linux
1824 x 984 FreeBASIC on Rasperry PI Arch Linux
Joshy
1824 x 984 FreeBASIC on Rasperry PI Arch Linux
Joshy
Last edited by D.J.Peters on Sep 25, 2017 20:39, edited 1 time in total.
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
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
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
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
speechless ?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
Joshy
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
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.
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.
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
Thx for answer Joshi!
---------------------------------
I feel exciting hacking days for FB are coming! Did not expect it so early!!
---------------------------------
I feel exciting hacking days for FB are coming! Did not expect it so early!!
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
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
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
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
Nothing you did wrong. Just install the missing libraries. The commandled-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?
- sudo apt-get install libGL-dev* libGLU-dev* libfreeglut*
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
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
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
Re: I got my brand new toys. (ARM Linux new target for fbc)
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.
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.)
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?
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.
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.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.
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.)
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)dkl wrote:If .ctors and .dtors section are missing then perhaps they're not supported on the platform and missing from the linkers ldscript
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?
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
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:gl_test.bas now compiles & links but does not run.
What about the libglut-dev? (It's deprecated, I recommend to use libFreeGlut-dev instead.)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)
BTW: libgui isn't related to OpenGL, AFAIR.
Re: FreeBASIC ARM6/7 for the Raspberry PI and Beaglebone Bla
The rounding I simply replace by a cast. (When using -gen gcc you needn't care about speed issues, option -O... can do that.)I couldn't understand why fbc uses inline assembly for this rather than just calling the C99 rounding functions.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.
-gen gcc also uses inline asm for naked functions ...