Matrix user forums

Hello !

I found a very strange problem.
In the attached file, you will see the exported macro who give me want to kill something or to burn my board !

I use float calculation to measure the acceleration in G.
This is the first icon in my macro. I put C0 at a high level before this macro and C0 at a low level after to measure the time it take to do the calculation : 6.8ms.

After that, I have a 19 characters string to write to my SDCARD and each time I enter in this macro.
When I have all the 512 characters, I write the file sector.
The complete 512 bytes take 24ms to be written.

My problem is when the fisrt icon is inhibited, the complete 512 bytes function take 24ms. Ok, that's good.
But if the first icon is not inhibited, the same complete 512 bytes function take 174ms !!! ( with of course, the C0 pin at the same place in the diagram ).

Do you know what's append ?

Thank you for your help

Hello Mathy,

Floating point calculations on a 8-bit device are going to take a huge amount of runtime to process as they are essentially 32-bit numbers and as such have big functions to allow the 8-bit device to manipulate the number correctly. Is there any way you could do the same calculation using integer maths or maybe lookup tables which would be significantly faster?

Hello Benj,

The question I have is why the same calculation take one time 24ms and after 174ms ?
Look at my flowchart and my post, I need to understand why I mesure that.

The look up table seem's to be nice to solve my problem but I never use that.
I need to read the three value on the accelerometer and store them into a CSV or TXT file on my SDCARD.

The accelerometer return me a 12bit signed integer value.
How can I give to each value, the good one in the lookup table ?

Thank you for your help

Hello.

I haven't had a chance to look at your flowchart I'm afraid, but when writing to SDCARD you are essentially writing to a FLASH block.

It all depends on how this card is managed. Optimisations aside, if the data you are writing is all zeros, for example, it can always be written to any area of FLASH. This will be fast for most systems as the code that writes the card will most likely not bother to erase anything. If however your data has ones in it (high bits) then these can only be written by first erasing the sector. This is very slow in relation to the write.

Is it possible that without the first call you are writing data that does not need an erase, and if you add the first call then it does? As a test, try hard-coding the data to write to what it would be if the icon was enabled, and disable the icon. Writing the data to card but not calling the macro will help decide if the problem is the macro itself, or the data it is outputting.

Jonny

Hello !

I found the problem. It was a problem in my flowchart.
Now the float calculation + writing on the SDCARD take a "normal time".

Im curious to see how many time this same code would take on DsPIC or on Atmel ARM7.
It is just a MIPS question or there are more optimizations on those corresponding compilers ?

Thank you for your help

Hi Mathy,

Thanks for letting us know.

The FAT routines will certainly run faster on a 16-bit or 32-bit device. It's not just a question of MIPs as there are a lot of 32-bit variables to process and therefore a 8-bit device is going to have a lot more work to do then a 32-bit.

Float variables are also 32-bit so processing these is going to take far less time on a higher bit depth device.

Personally I would recommend the 16-bit PIC EP range as they can run up to 70MIPs, cheaper then a standard AVR and are virtually as straightforward to use as a standard 8-bit PICs. Unfortunately they are all surface mount so you need a custom PCB. The EB064 can support 16-bit DIL package dsPIC33 chips running up to 40MIPs.

For comparison a standard 8-bit ECIO running at 48MHz runs at 12MIPs.

Thank you Benj for the information.
But now, I believe that Microchip has stopped to work on the pickit3 flash program and it is not possible to program EP series.
I believe that the only way is to load the generated hex file in mplab. mplab will generate a firmware for the pickit3 "mplab mode".

Do you have other solution for that ?

Hello,

Hmm that's true. Just tried it with the stand alone software for the PICkit 3 and your right it's not detecting it! Dissapointing.

I think the solution is to give Microchip grief until they flip flop their decision back and add support to the PICkit 3 software. It will very likely happen it's just a matter of when. Normally when the customers start shouting and the technical people

I will also pass some comments across to Microchip and see if I can lean on them a bit. Don't have much weight but I will try.

Seems there is a big PICkit 3 discussion going on at the moment regarding production programming which basically seems to invalidate features such as bootloader based programming and storing values to the flash.

Hello Benj,

Thank you for your time.
I will post on the Microchip forum !

Have a nice day.