[FOSS-GPS] RTKLib MIPS requirements?

Michele Bavaro mic.bavaro at yahoo.co.uk
Tue Aug 14 02:31:33 PDT 2012


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 FOSS-GPS at lists.osgeo.org 
>>>>>>>> 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 FOSS-GPS at lists.osgeo.org 
>>>>>>> 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 FOSS-GPS at lists.osgeo.org 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 FOSS-GPS at lists.osgeo.org 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 FOSS-GPS at lists.osgeo.org 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 fromFOSS-GPS at lists.osgeo.org  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 fromFOSS-GPS at lists.osgeo.org  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 FOSS-GPS at lists.osgeo.org 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20120814/eaaca370/attachment-0001.html>


More information about the FOSS-GPS mailing list