OpenCPN Runs on Embedded ARM

[Aikiguy]

Ok running through the standard tests. Vector Charts just blow up on me with this error:
odroid@odroid:~$ opencpn

(opencpn:8967): Gdk-CRITICAL **: IA__gdk_colormap_new: assertion 'GDK_IS_VISUAL (visual)' failed

(opencpn:8967): Gtk-CRITICAL **: IA__gtk_widget_set_colormap: assertion 'GDK_IS_COLORMAP (colormap)' failed

(opencpn:8967): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
libGL: built on Jul 23 2014 07:28:00
glXGetProcAddress: glGenFramebuffers not found.
glXGetProcAddress: glGenFramebuffers not found.
glXGetProcAddress: glGenFramebuffers not found.
glXGetProcAddress: glGetCompressedTexImage not found.
Aborted

Have no idea how to sort that out. Any clues here?

The rest seems to be working ok.

When using just rasters I get this error over and over again, is the the error in opencpn code that slows things down? if so how to I send it to null?

(opencpn:6338): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17

On to using the rasters and trying to hook up the instruments, then the radar.

Guy
:-)

[Aikiguy]

Problems with the dashboard module!

The position is reapeated over and over but the rest is a mess.

Screen shot.

Any ideas?

Thanks,
GUy
:-)

[sparticle]

Originally Posted by Aikiguy

I don't know all the ins and outs of the raspberry pi libraries, but I would think it would be possible. However I would spend the $65.00 on the odroid instead of the pi for the extra speed right now.


Guy
:-)

If the Rpi can provide HW Accelerated graphics for OpenCPN then it is definitely a better bet! I can have 2-3 Pi's for he price of one ODROID! On board the instruments and AIS are NMEA via USB and seem to use virtually no CPU to access.

I appreciate the other boards out there, but in terms of the lowest power/most connectivity/best performance then it looks like the Rpi B+ will be seriously hard to beat if we can get the GPU to do the work

Cheers
Spart

[Aikiguy]

The raspberry pi is sllllllooooowww. Will it be fast enough with opengl enabled? Maybe, but I doubt it. The B+ doesn't change the core hardware at all, it isn't any faster than any other raspberry pi.

As a complete solution running as a charting program an instrument data display, and radar overlay. I don't think that there is going to be enough processing power with the Pi.

Don't get me wrong I love my pi, it is the best boat entertainment center ever, and in that roll is wonderful! (Mine has not been turned off for over a month!) It is fun to play with, and it makes a wicked good instrument collector, and rebroadcaster via wifi, or even bluetooth.

As other low power devices with better faster hardware come out, the raspberry pi is going to suffer in comparison. It doesn't have and was not intended to have enough processing power to do what we want it to do.

The one thing the Pi has going for it is a GREAT user base, with a lot of knowledgeable people working on it. The releases for the pi when they come out are much better tested than on the odroid, and there are less problems with things out of the box. However out of the box without opengl the odroid is completely usable as a chartplotter and instrument agregator, the panning is slower than my laptop, but usable, the raspberry pi out of the box is not capable of routing or entering waypoints in any meaningful manner just because it is too slow.

I have both sitting here in front of on my nav station. Both have their place I think. (I can't imagine not having a raspberry pi as and entertainment center for music, and videos aboard any boat).

Time will tell.

Guy
:-)

[sparticle]

Originally Posted by Aikiguy

Time will tell.

Guy
:-)

Guy,

As you say time will tell, I completely agree about the media centre usage. I have 5 Raspbmc pi's at home, all being used as media centres replacing various linux PC's and Zotac machines. They are truly amazing.

On board the plan is to have a primary headless Rpi as the nav machine with connectivity via USB to the AIS/GPS feed and instruments also driving the nav repeater and autopilot (that's where the B+'s 4 USB ports comes in) it also creates a NMEA server feed serving all NMEA and Nav data via Eth0 to the (8W) MiFi AP that also has a USB port for connection to a USB WiFi antenna or 3G/4G dongle. This creates a NMEA cloud and allows the android tablets to connect to OpenCPN via vnc. It also allows phones/tablets to consume the data using other apps. Total 12W.

Secondary cold standby Rpi as backup for above.

Third Rpi Raspbmc/OSMC media player connected to the onboard 12v 24" TV/DVD player (23W inc Rpi) for entertainment. Can be controlled using the Android remote via wifi connection.

Exploring currently building a NAS server with multiple SSD's and an Rpi running minimal Raspbian, (<20MB when booted) and an external array using maybe btrfs. This will be used to backup the Nav pi and logs/routes etc. and as a media repository and server. (pi B+, 4 x SSD's = <10W)

Total power for all of the above is less than my laptop which uses 60-70 W

We will run a HDMI cable to the other port on the TV should we need to display the primary Rpi.

I do have high hopes for the fully OpenGL version of Raspbian

Cheers
Spart

[seandepagnier]

Please check earlier posts in this thread for my results with hardware acceleration on the pi. It works and is about 4 times faster giving somewhat smooth graphics (15 frames per second on 1280x720) for raster charts. Vector charts and cm93 is still quite slow at only a few frames per second.

[seandepagnier]

Originally Posted by Wrong

09:00:29 PDT: OpenGL-> Using 3dfx fxt1 compression

So, is accelerated hardware working, or is noticeable improvement in display quality and speed still due to software?

Maybe your tablet supports big gl (as opposed to opengles) so it could be working after all. I am very suspicious of the above line, fxt1 compression is a last resort, and should never be selected with normal systems. If you have a significant improvement in speed it probably works, the image quality will be improved via software so should be either way.

It is easy to find out. If you get the same results using opengl after removing the libGL.so you built, and using the one installed by your package manager.

Originally Posted by sparticle

From over on the Raspberry forums a new VC4 driver is being developed now that Broadcom has released the source code for the SOC used in the Rpi:

Yes, but they released only the 3d core, not the video core, so any driver developed may work and provide better support, but will still rely on the cpu rather than the video core for many things in the pipeline and the result is a suboptimal driver.

I really suggest sticking to devices with mali drivers, they work a lot better for several reasons.

[Wrong]

boat_alexandra,

Same output using libGL.so from repository.

I don't know why but the link libGL.so to libGL.so.1 in /usr/local/lib didn't work. Permissions could not have been more liberal, so isn't the issue. Because there will never be systemic updates to /usr/local/lib/libGL.so.1, I simply changed the name from libGL.so.1 to libGL.so and cured the problem. I'm sharing this in case others seem to be having the same problem.

[seandepagnier]

Originally Posted by Aikiguy

Problems with the dashboard module!

The position is reapeated over and over but the rest is a mess.

Screen shot.

Any ideas?

Thanks,
GUy
:-)

Maybe try my mingw branch... I know it sounds crazy but it might fix the dashboard.

[seandepagnier]

Originally Posted by Wrong

boat_alexandra,

Same output using libGL.so from repository.

I don't know why but the link libGL.so to libGL.so.1 in /usr/local/lib didn't work. Permissions could not have been more liberal, so isn't the issue. Because there will never be systemic updates to /usr/local/lib/libGL.so.1, I simply changed the name from libGL.so.1 to libGL.so and cured the problem. I'm sharing this in case others seem to be having the same problem.

I think you should try

LD_LIBRARY_PATH=/usr/local/lib opencpn

After putting the glshim libGL.so file there.

Otherwise I believe it must be searching a different folder for libraries before /usr/local/lib and therefore using the software libGL.so which explains why you have fxt1 compression when you should have etc1

[sparticle]

Originally Posted by boat_alexandra

Please check earlier posts in this thread for my results with hardware acceleration on the pi. It works and is about 4 times faster giving somewhat smooth graphics (15 frames per second on 1280x720) for raster charts. Vector charts and cm93 is still quite slow at only a few frames per second.

Yes I have read thorugh all posts and installed from fresh both Raspbian and new complied versions of OpenCPN and glshim and glues. followed all advice and I cannot replicate OpenGL working on the Rpi.

I have read so much on these issues I am on overload. The guys over on the Rpi forums are expecting a native OpenGL 2.0 driver for the Rpi to come from the work being done on the driver by Broadcom and the foundation. The SOC seems to support OpenGL 2.0 so if a driver gets built and included with the standard Raspbian build then we should be a lot better off than using glshim to talk to the blob.

It may only be a few weeks/months away so lets see what happens. Meanwhile I will keep trying to understand some of this

Cheers
Spart

[jzemeocala]

hey everyone,
First off let me say that i am no stranger to linux and I have successfully got glshim to run on the raspberry pi but I have recently upgraded to the cubieboard2 and no matter what OS i try to use or which fork of glshim i try to use, I simply can not get it to work with on this board......I have even tried debugging the various errors with the creator of glshim to no avail.

So I am here begging for one of you that has glshim working to make a .img file of your system that I could use to get things going


and please don't refer me to Building and installing on Cubieboard 2 with HW acceleration | Official OpenCPN Homepage
I am well aware of it and have had no luck.......regardless of what operating system I use (including the original cubian one mentioned in it)

[seandepagnier]

Yes, well keep in mind there is a cpu, video core, and v3dcore. They released only specs for the v3dcore, so the open driver must use the cpu to do everything the video core used to do which is much slower. For opencpn it might actually be ok since the operations are relatively simple.

[sbfreddie]

Originally Posted by jzemeocala

hey everyone,
First off let me say that i am no stranger to linux and I have successfully got glshim to run on the raspberry pi but I have recently upgraded to the cubieboard2 and no matter what OS i try to use or which fork of glshim i try to use, I simply can not get it to work with on this board......I have even tried debugging the various errors with the creator of glshim to no avail.

So I am here begging for one of you that has glshim working to make a .img file of your system that I could use to get things going


and please don't refer me to Building and installing on Cubieboard 2 with HW acceleration | Official OpenCPN Homepage
I am well aware of it and have had no luck.......regardless of what operating system I use (including the original cubian one mentioned in it)

jzemeocala:
I have used Ubuntu distribution Qbee-X from the Cubieboard Forums. I then modified the image with directions I found to work.
Would you like to try to imitate what I did? What distribution are you using?
I could give you the specific directions if you would like.

Thanks,
Freddie

[jzemeocala]

I am actually using Qbee-X right now (although I have been tinkering with its libraries to try try to get it to work) but yes please I would kill for some instructions about now

you can also follow my communication with lunixbochs about the issues ive been having here:

https://github.com/lunixbochs/glshim/issues/61