Hello Danny,
Thanks for the update... our objectives perhaps are different.
Raspberry-PI is useless for me as there is no commercial product
development path beyond it.
In addition, there is no challenge running a few instances of RTKLIB on
that, or Beagleboard, or Beaglebone.
;)
All the best,
Michele
On 14/08/2012 11:06, Danny Miller wrote:
Since Raspberry Pi finally became available, I've moved away from an
STM32F4 attempt. There's not much purpose to it.
Raspberry takes some getting used to, I'm not very familiar with
Linux. The Debian Squeeze release that was out when Pi was released
became obsolete in mid-July with the much faster, friendlier Debian
Wheezy release. This is important because Wheezy uses the Pi's
hardware FPU, Squeeze did not, which is why it was so slow. RTKLIB
needs that FPU.
I was delighted to find that Debian readily recognized the Silabs
CP2102 USB-to-serial bridge and even the uBlox GPS's USB port. And on
the GPIO pins, it also has a serial port there which is supported by
the OS.
RTKRCV does compile with the GCC included in the Debian release.
However, I'm a bit unclear on how to configure the setup (calling one
GPS a static base station, for example), pass it the ports and what
sort of messages I can expect out of it. There's not going to be any
way to run the GUI version, I assume? Windows emulators like Wine
will never run on the Pi.
Danny
On 8/14/2012 2:35 AM, Michele Bavaro wrote:
Hello Danny,
Have you done any real progress with STM32F4 then?
Best regards,
Michele
On 03/05/2012 14:45, Danny Miller wrote:
I remember seeing that a long time ago, but forgot about it. Hmm, it
does have useful figures.
The A8 at 600MHz would be capable of 1200 DMIPS. At 20% utilization
for 10Hz GPS operation that would indicate 240 DMIPS used, and
that's with the TMS320C64x DSP. However, AFAIK that's not a
floating-point DSP core and I expect you'd have to do a lot of
tinkering with the compiler to get it to send any math to the DSP
core. I suspect it wasn't used. The article doesn't mention the
TMS320C64x DSP except in the Beagle specs.
The STM32F4 is capable of 210 DMIPs. Hmm, that's troubling. There's
still overhead which hasn't even come into play yet. I would expect
compiling to metal would be substantially more efficient but I don't
KNOW that. Then again, it doesn't HAVE to be 10Hz, we could go with
5Hz operation, there's no law saying it has to be 10Hz. Plenty of
overhead at that speed.
Danny
On 5/3/2012 1:04 AM, Michele Bavaro wrote:
Dear Danny,
Sorry, I assumed that you read this paper
http://gpspp.sakura.ne.jp/paper2005/isgps_2009_rtklib_revA.pdf
before posting.
There you may find more details about RTKLIB computational load at
10Hz.
Best regards,
Michele
On 02/05/2012 23:08, Danny Miller wrote:
Well correct me if I'm wrong but this seems to come down to how
many flops it can do, the moving of variables and such is probably
a minority of the processing. That's why I wanna focus on the
flops requirement.
How much resources does RTKLib consume on Beaglebone? Because BB
being faster and capable of RTKLib still doesn't establish the
processing requirements. Is it running at 60% core utilization or
5%?
I did run RTKLib on my i7 Q 740 1.73GHz laptop and the utilization
was basically nil. I really couldn't determine anything from
that, the usage figure was too low to give a meaningful number,
not when the capabilities are at least 100x greater. I mean if
the usage was 10% on that i7 I could pretty well dismiss it
working on a Cortex M4. IIRC it was like a single-digit or
fractional % though and the OS can consume considerable resources
managing the busses and displaying the maps and interfaces so that
doesn't mean much.
Raspberry PI would be nice, but I can't get ahold of one, much
less will it be readily available at this time for widespread
consumption if the application worked. I'm still uncertain if
widespread, long-term, low-price distribution is gonna happen or
just turn out to be vaporware. STM32F4, anybody CAN order one or
a thousand and get them for $15 or better right now. Still got
high hopes of course. Raspberry PI also wasn't designed with a
lot of low-level hardware interfacing so it'd still require a
daughterboard like the STM32F4 to interface with a rover's motors
and sensors and all.
Danny
On 5/2/2012 3:40 PM, Michele Bavaro wrote:
Hi Danny,
I strongly doubt that a STM32F4 will be able to run RTKLIB.
It's true that it runs on a beaglebone, but Cortex-A8 has around
2MIPS/MHz and runs at frequencies close to 1GHz,
whereas a Cortex-M4 has 1.25MIPS/MHz and runs at frequencies up
to 150MHz: there is almost one order of magnitude.
In addition since the structure of rtkrcv is quite strongly
coupled with a Linux OS,
there will be a lot of effort required to port it to a lighter
RTOS, let go to bare metal code.
But I don't want to discourage you.. if you think it's doable go
for it :)
Best regards,
Michele
On 02/05/2012 00:15, Danny Miller wrote:
STM32F4 "demo board" uses an Arm Cortex m4. 32 bit, 210 DMIPs
and a single-precision hardware FPU. I'm slightly unclear on
the memory space it has on this specific board but it should be
192KB SRAM and 1MB flash. That's my porting plan.
If it WORKS, it'll be a great system, these boards are absurdly
cheap. It is several more orders of magnitude of capability
than these 8bit PICs and such, but I don't understand the scale
of the flops requirement of RTKLib. I know it's somewhere
between "much more than any 8-bit controller could ever do" and
"won't even make Intel i7 break into a sweat". And those are
wildly different magnitudes. I don't know exactly where RTKLib
10Hz would be between those.
And it's be running RTKLib and just some minor application
(navigation and monitoring) code which will not be
processor-intensive, and it's not using Linux or an RTOS. So
there's not a significant overheat for other tasks and the
overhead's timing can be managed predictably and accurately.
Pretty much the core can either do it or it can't.
Danny
On 5/1/2012 4:43 PM, julio menezes wrote:
Hi Danny,
I have a core with a hardware FPU, but it's only capable of
doing Single floats, not Double. It is going to break
things to implement the specified Double calcs with Single
precision? I would assume so, but it's worth asking.
The RTKLIB author T.Takasu and A.Yasuda have ported RTKLIB to
a BeagleBoard which has an ARM Cortex-A8- with 1 GHz and
floating point, I do not know if double or single precision.
I plan to move in this direction also, may be using a hardware
less powerful but cheaper.
Raspberry Pi
http://www.raspberrypi.org/faqs
The SoC is a Broadcom BCM2835.
This contains an ARM1176JZFS, with floating point, running at
700Mhz, and a Videocore 4 GPU.
I am waiting, anxiously, the RTKLIB 2.4.2 version with
RTCM-104 phase messages encoder to built a local base station
as where I live there are no near NTRIP network ( less than
10km ).
good luck,
julio menezes
_______________________________________________
This message is sent to you from [email protected]
mailing list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to
manage your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you from [email protected]
mailing list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage
your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you from [email protected] mailing
list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage
your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you from [email protected] mailing
list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage
your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you from [email protected] mailing
list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage
your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you [email protected] mailing list.
Visithttp://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
subscription
For more information, checkhttp://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you [email protected] mailing list.
Visithttp://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
subscription
For more information, checkhttp://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you from [email protected] mailing list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
_______________________________________________
This message is sent to you from [email protected] mailing list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
