Raspberry PI and Beaglebone Black.

[D.J.Peters]

FreeBASIC for Raspberry PI and Beaglebone Black can be found here
http://www.freebasic.net/forum/viewtopi ... =5&t=21433

I got my Raspberry Pi and the BeagleBone black today.

Paspberry PI:
ARM® 700 MHz 512 MB, OpenGL ES, SDCARD, analog VIDEO + AUDIO, digital HDMI + AUDIO, USB 2.0, GPIO's, Ethernet 10/100


Beaglebone Black:
ARM® 1 GHz 512 MB, OpenGL ES, 2GB memory disk, microSDCARD digital microHDMI + AUDIO, USB 2.0, GPIO's, Ethernet 10/100


I'm off for 2 days now ;-)

Joshy

[brybry]

The Cubieboard or MarsBoard may also be of interest. They each have 1 SATA port on board. The specs of the MarsBoard are pretty impressive, running at 1.2 GHz and 1GB of DDR3 RAM.

Unfortunately, they are probably not as well supported as RPi or Beaglebone.

My dream is to one day program Cortex-M3 microcontrollers with FreeBASIC.

Have fun, Joshy!

[dodicat]

I don't have any of these gadgets myself, just an old box from Ebay.
But if I did buy one, I certainly wouldn't take it to pieces as D.J.Peters has done, on the first day.

[D.J.Peters]

All works fine here. (HDMI, 3D only on Raspberry PI, Audio, NET, USB etc.)
After a "hello_world.c" and some OpenGL ES test's I learn ARM assembler now.
I use code::blocks and geany as IDE (same as on Win32 and x86 Lnux)
Porting the FB runtime for ARM linux devices should be possible all dev packages are the same as on a x86 Linux box.

The problem is the ARM code emitter for fbc.

OpenGL on the PI can't run in a window it's a kind of fullscreen indepent from current window manager
so ScreenRes() will ignore width,height and depth and ScreenInfo() can return the current resolution and depth.

None OpenGL modes are libX11 stuff same as on x86 lnux.

@DKL
Can FB compile it self if you compile it self with -gen gcc ?

Joshy

[dkl]

Yea, -gen gcc can be used to rebuild fbc itself. In fact I consider -gen gcc more stable than the x86 ASM backend now, because of the unsolved bugs in the ASM backend...

[D.J.Peters]

Hello dkl
if you compile fbc to c code does we get one large c and h file
or does every bas file creates it`s own c file ?

Does the c version of fbc use only the static fb runtime libs or the libc from host ?

Joshy

[dkl]

fbc source code is split into many *.bas modules, there will be one *.c file generated for each *.bas, just like for the *.asm backend.

-gen gcc output has the same dependencies like -gen gas output. It will depend on libfb/libfbmt/libfbgfx, which in turn depends on libc/libpthreads/etc.

[anonymous1337]

dodicat: I believe Raspberry Pi comes like that. It's a computer for hardware hackers/enthusiasts/students. It has a manual and plenty of available support.

Yea, -gen gcc can be used to rebuild fbc itself. In fact I consider -gen gcc more stable than the x86 ASM backend now, because of the unsolved bugs in the ASM backend...

Wow. When did this happen? How about the LLVM backend?

[D.J.Peters]

Hello dkl,
can you support porting fbc to other CPUs ?
would be cool to have fbc as a bundle of *.c files
so far i know we need on other cpu architectures:

libfb.a, libfbgfx.a, libfbmt.a

but was it with the linker stuff ?
crt2.o, crtbegin.o, crtend.o, ...

sorry for my noob questions.

Joshy

[TJF]

would be cool to have fbc as a bundle of *.c files

Do it yourself! Execute (best with fbc-0.9) in folder src/compiler

• fbc -r -gen gcc *.bas

This should generate a *.c file for each *.bas file. On Angström you've to adapt the outcome. Skip the gdm-part (mouse handling) since there's no libgdm. And some __asm__ statements need adaption. That should be all to get it compiled.

so far i know we need on other cpu architectures:

libfb.a, libfbgfx.a, libfbmt.a

fbgfx is NOT a must-have (AFAIK), you can use SDL, GDK or others.

But either fb or fbmt are mandatory. They should compile with gcc on any system.

but was it with the linker stuff ?
crt2.o, crtbegin.o, crtend.o, ...

These are parts of the C build system. They should come with the system.


In the above described way I managed to compile all *.o files (compiler & rtlib) and to build the libfb.a and libfbmt.a native on Angström. But, I couldn't link them yet (The original makefile uses fbc. I'm not familar with alternatives, ld or gcc).

Any help is welcome.

[TJF]

root@beaglebone:~# ./fbc -version
FreeBASIC Compiler - Version 0.90.0 (06-30-2013) for linux
Copyright (C) 2004-2013 The FreeBASIC development team.
root@beaglebone:~#

[TJF]

root@beaglebone:~/Projekte/test# cat a.bas
?"My first FreeBasic program on ARM:"
for i as integer = 1 to 9
?i; " line of putput!"
next
?"Voila!!!"
root@beaglebone:~/Projekte/test# ./a
My first FreeBasic program on ARM:
1 line of putput!
2 line of putput!
3 line of putput!
4 line of putput!
5 line of putput!
6 line of putput!
7 line of putput!
8 line of putput!
9 line of putput!
Voila!!!
root@beaglebone:~/Projekte/test#

... enough for today.

[srvaldez]

hello TJF, would you give a step by step description on how you compiled FB for ARM ?
also give details on any pitfalls and workarounds, I would like compile FB for Mac.
thanks.

[dkl]

When did this happen? How about the LLVM backend?

Well, it happened during September/October after the 0.24.0 release. There were lots of -gen gcc patches coming in at the time, and more until early 2013. Work on the LLVM backend helped the C backend aswell, though after the initial phase of getting excited about it I haven't continued working on it much. But it's still an interesting option, especially to solve the debugging meta data problems with the C backend, and I want to make it work eventually.

Much like TJF said, you can pre-compile the fbc sources (from the src/compiler/ directory) by doing:

fbc -target linux *.bas -gen gcc -r -m fbc

and then theoretically copy the .c files over to the target system and compile them with gcc using something like:

gcc -o fbc -fno-strict-aliasing -frounding-math fbrt0.o *.c -lfb

That's assuming you have already compiled libfb.a and fbrt0.o on the target system. It will probably need further -l options depending on rtlib dependencies, on Linux for example -lncurses or -ltinfo, and -pthreads.

Just keep in mind that the .c code is not system/architecture/ABI-neutral, so for example .c code generated with -target linux won't work on Win32, and (currently as of FB 0.90) it also contains 32bit assumptions so won't work on 64bit, 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.

We've started the 64bit port a while ago (i.e. x86_64 Linux/Windows systems, and theoretically other 64bit too), and I'll continue working on it now that the 0.90 release is done. It includes removing the 32bit assumptions from fbc and of course removing any traces of x86 from -gen gcc output. And just overall qualiy improvements of -gen gcc since it will fully rely on it.

While -gen gcc can already be used to port FB to different architectures (only requiring some tiny fixes as of FB 0.90), porting to a different operating system such as MacOSX or Android is more difficult because the rtlib must be ported first (and the gfxlib2 shouldn't be forgotten either) to use the different set of system functions.

[srvaldez]

thank you dkl for the information.