[FOSS-GPS] RTKLib MIPS requirements?

Tue Aug 14 00:35:01 PDT 2012

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 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/cc56d504/attachment.html>