FAT: faster way to write data

mikn · Post by **mikn** » Wed Apr 09, 2014 5:40 pm

Which looks correct. Hope that helps.

But it doesn't work anyway. In Software mode - it's ok. In Channel1/2 with same pins - doesn't work. What's wrong?

Post by **Benj** » Thu Apr 10, 2014 3:04 pm

Hello,

Do you mind posting your Flowcode file so far and I will try and replicate the issue here on the exact same device that your using.

mikn · Post by **mikn** » Thu Apr 10, 2014 3:28 pm

The whole project is big, so I left only the problem place. Here's the code:

Post by **Benj** » Thu Apr 10, 2014 4:56 pm

Hello,

Right I have managed to replicate the issue so will have a play and see if I can find out what's going wrong.

Post by **Benj** » Fri Apr 11, 2014 10:47 am

Hello,

Right it looks like the code to ramp the prescaler had problems on the 16-bit PIC devices which caused a lock up.

Here is an updated FAT component which should resolve the issue.

FAT.fcpx: (62.73 KiB) Downloaded 226 times

Let me know how you get on.

mikn · Post by **mikn** » Fri Apr 11, 2014 11:28 am

Now it's passing by and rotating in the loop "while retval>0". Changed two cards, none of them was initialized.

Also lots of warnings:

D:\flowcode\PIC24T~1>pic30-gcc -c -mcpu="24FJ64GA002" -funsigned-char -fno-short-double -Os -I"C:\PROGRA~1\FLOWCO~2\COMPIL~1\pic16\BATCHF~1\..\support\h" -I"C:\PROGRA~1\FLOWCO~2\COMPIL~1\pic16\BATCHF~1\..\MX_support" -Wall -std=gnu99 "Flowcode1sma-p".c -o "Flowcode1sma-p".o
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__ReadStringFromFile':
Flowcode1sma-p.c:356: warning: pointer targets in passing argument 1 of 'FCI_SCOPY' differ in signedness
Flowcode1sma-p.c:356: warning: pointer targets in passing argument 3 of 'FCI_SCOPY' differ in signedness
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__ReadByteFromFile':
Flowcode1sma-p.c:537: warning: unused variable 'FCL_IDX'
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__DeleteFile':
Flowcode1sma-p.c:657: warning: passing argument 1 of 'FCI_COMPARE' discards qualifiers from pointer target type
Flowcode1sma-p.c:657: warning: pointer targets in passing argument 3 of 'FCI_COMPARE' differ in signedness
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__CreateFile':
Flowcode1sma-p.c warning: large integer implicitly truncated to unsigned type
Flowcode1sma-p.c warning: large integer implicitly truncated to unsigned type
Flowcode1sma-p.c warning: large integer implicitly truncated to unsigned type
Flowcode1sma-p.c warning: large integer implicitly truncated to unsigned type
Flowcode1sma-p.c warning: large integer implicitly truncated to unsigned type
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__OpenFolder':
Flowcode1sma-p.c warning: passing argument 1 of 'FCI_COMPARE' discards qualifiers from pointer target type
Flowcode1sma-p.c warning: pointer targets in passing argument 3 of 'FCI_COMPARE' differ in signedness
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__OpenFile':
Flowcode1sma-p.c warning: passing argument 1 of 'FCI_COMPARE' discards qualifiers from pointer target type
Flowcode1sma-p.c warning: pointer targets in passing argument 3 of 'FCI_COMPARE' differ in signedness
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__AppendStringToFile':
Flowcode1sma-p.c warning: pointer targets in passing argument 1 of 'FCI_GETLENGTH' differ in signedness
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__Format_File_String':
Flowcode1sma-p.c warning: pointer targets in passing argument 1 of 'FCI_TOUPPER' differ in signedness
Flowcode1sma-p.c warning: pointer targets in passing argument 3 of 'FCI_TOUPPER' differ in signedness
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__Initialise':
Flowcode1sma-p.c warning: unused variable 'FCL_RETVAL'
Flowcode1sma-p.c: In function 'FCD_08f41_adc_base1__GetString':
Flowcode1sma-p.c warning: pointer targets in passing argument 3 of 'FCI_FLOAT_TO_STRING' differ in signedness
Flowcode1sma-p.c: In function 'FCM_adc_read':
Flowcode1sma-p.c warning: unused variable 'FCL_A1'
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__Read_Next_File_Sector':
Flowcode1sma-p.c warning: 'FCR_RETVAL' may be used uninitialized in this function
Flowcode1sma-p.c: In function 'FCD_07fa1_FAT1__OpenFile':
Flowcode1sma-p.c warning: 'FCL_TEMP' may be used uninitialized in this function

Compilation successful!
Completed compilation, return = 0

Post by **Benj** » Fri Apr 11, 2014 12:02 pm

Hello,

Hmm, I tried it here and one card did work but one didn't. I'll carry on playing when I get a min and see if I can find out anything else.

mikn · Post by **mikn** » Mon Apr 14, 2014 12:32 pm

Benj,
Don't know if it matters or not, but same problem I've met with cal_i2c component.
Chip is Atmega168 running at 8mhz internal RC.
While I work in Software mode with PortC0 and PortC1 pins, it works and connects to external eeprom but it reads memory with big delays (around 1byte per 200ms).
When I change to Channel1 and remap pins from standart C4/C5 to C0/C1, it stucks on Master_Start step and don't go further.
Seems to be common problem as I've got with FAT component.

The project is attached below.

mikn · Post by **mikn** » Wed Apr 16, 2014 5:04 pm

Any news on these issues?
I've bought FC Pro version for a month ago, almost finished with two projects but can't complete them because of these two issues with fat and i2c pin remaps.

Do you have any support channel where we can talk closely and do fix-test-fix-test rounds to get this running? That's really impressive that I can't go forward without fixing these issues now.

Post by **Benj** » Thu Apr 17, 2014 2:37 pm

Hello,

Yes we are looking into these issues for you, however we are currently up against the wall for a deadline so can't look into them today. I will make sure that both issues are made a high priority for next week to allow you to continue with your projects.

mikn · Post by **mikn** » Wed Apr 23, 2014 5:59 pm

Any updates?

Rudi · Post by **Rudi** » Sun May 04, 2014 5:52 pm

Hi mikn,
I hang in this too. ( SD Card PIC24 (FJ256GB106 ) + PIC18 ( F2550 ) ) I will wait after the holiday and MM Team is complet again.
Do you have a extern SD Hardware or a PIC24 Board with SD onOard?
Have you the shematic for the fix Board?
Best wishes.
Rudi

Rudi · Post by **Rudi** » Sun May 04, 2014 6:57 pm

Mathy wrote:
You don't have to create CAL_SPI component. You have to read carefully my post.
As Benj said, you have to :

"Open the window via the view menu and tick the "expose full component tree" setting.

Next click the drop down menu at the top of the properties window and you can now see all the things that make up the FAT component. Select the CAL_SPI component and there are options there to allow you to set the prescaler."

Your problem is not the prescaler but the PPS feature but you have to do that to access to the remap feature.

As you can see in the attached file, I don't created CAL_SPI component, the CAL_SPI appears only after tick the "expose full component tree" setting.

Hi Mathy,

which version of FC6 do you have?
in my 6.0.6 i can not see the CAL_SPI only the FAT ..
..

TY
Best wishes
Rudi

Post by **kersing** » Sun May 04, 2014 7:40 pm

Rudi,

In the "Component debugging" window you need to set the tick next to "Expose full component tree in property pane". Then CAL_SPI will be available in the "Properties" drop down. (You may need to select the 'Component Debugger' from the 'View' menu)

Best regards,

Jac

Rudi · Post by **Rudi** » Mon May 05, 2014 3:14 am

kersing wrote:Rudi,

In the "Component debugging" window you need to set the tick next to "Expose full component tree in property pane". Then CAL_SPI will be available in the "Properties" drop down. (You may need to select the 'Component Debugger' from the 'View' menu)

Best regards,

Jac

Hi Jac

nice

i wounder me

.. i did search a long time

...
great Konzept!...
Thank you - now i found this.

Best wishes!
Rudi

Edit:
hour later

i got it!
SD ( 8 GB ) is runing
Thank You for this Thread!

mikn · Post by **mikn** » Mon May 05, 2014 9:36 pm

I've tried this already but it didn't help. Still waiting for the news from Matrix. This project is stuck on the last step with FAT.
Other project is stuck with I2C pin remap, same problems.

Rudi · Post by **Rudi** » Tue May 06, 2014 12:22 pm

mikn wrote:I've tried this already but it didn't help. Still waiting for the news from Matrix. This project is stuck on the last step with FAT.
Other project is stuck with I2C pin remap, same problems.

Hi mikn, please don't give up!

my project in PIC24 stop too in the UART/USB
http://www.matrixmultimedia.com/mmforum ... 54&t=14635
http://www.matrixmultimedia.com/mmforum ... 54&t=14649

but i know, if MM is complete after the Holiday the guys will do all what they can do for runing.
,,
,,, i have found in "Starter Kits" .. example SHURE PIC24 Advancer Development KIT, there is a SD Card Holder,
this is other pinned because the SPI is "shared".. ( i do not know 100 procent how this named correct in english )
not all that not running with FC6 is a "bug".. sometime the Hardware is pinned crazy like from this "Shure.."
the example Codes runs in MPLAP only - because SHURE make "bridge Code" for the Hardware.. ( i found this explicite in the DB-DP11115 )
so example a "USB CDC" is included, it runs ( initialise ) after a button is pressed, and then the LCD show "UART"..
and in Windows is a CDC COM Port avaiable.ll.. if i return the button to a other "menu" at the LCD...
the UART is still avaiable in Win as CDC Port.. but if i come back to the LCD Menu "UART" the UART CDC at WIN
is show but not running again.... ;-/.... after i turn off and turn on the SHURE Board... and First Time select the UART Menu...
then the CDC again in WIN is come and working... Shure has still "Sleep" functions in the code... and this must then
code by "custom C " in FC...

This is, because at this board, many peripherie is on Board.. but not enough pins..
so the demo codes allways support... -UART ... or the LAN ... or the USB OTG as USB Flash and so on...
the word "or" is the magic word ..

It must very detailed lock in the shema and electric for the "beginners Board" that can buy at Market...
not all is running without problems...

I hope i have take the right words in english and you can understand what i mean.

Which Board do you take?
Or do you make a Shema / electric by your self?

The concept of FC is great. At begin i am very skeptical, for "clicking" code.. ...but the potential is great...
and if you work with many projects you are very flexibel in this...
many many futures are in FC6 hidden - this debugger window i search hour too

...
( i think i do not read exactly what benj write too

) ...

the guys allways help and have friendly service.
It is shame, that a lot of bugs in the FC6 but i am sure ... step by step - i am very sure - this will be clean and done.
i suspect a Base mistake, because all is with the Clock Speed ... Baudrategenerator.....I2C need a exactly CLK too...

I have bougt the comerc Packs all 700 EUR ..... only ARM i have not buy, because i work just in time not with this.
My wish for support the PIC32 will be fantastic if MM will go on in this - i dream from PIC32 Pack

and will buy fast ..
..i wish i wish i wish..

My Problem is, i am a "beginner"... and i know only the little Base because i hear from FC First Time in V4 and V5 ...
If i know more - i am sure, i can find this or other in FC by myself
and can share this here... but i learn just in time this .by myself.. and the MM Team allways give Tips that let me save many Time in search... try...
and i will understand this...

..i hope you can go on.

My Test in SD was in PIC24FJ256GB106 and PIC18F2550
The PIC24 ( 11115 Board 20Mhz Crystal ) i can not run with SD Function.
But I have succesfull done
-> LCD ( yeah )
-> Buttons ( SW2, SW3, SW5 )

pause is in
-> USB Slave
-> LAN Enc28J...
-> UART

The PIC18f2550 ( BOLD 18F2550 20MHz Crystal ) i have succesfull done
-> LCD
-> Buttons
-> UART ( this runs like a Dream

-> PortB (Digital for Software SD ( RB4, RB5, RB6, RB7 )
-> PortB (Digital for Software UART (WiFi Board ) Tx, Rx RB2, RB3 ) for Debug Displaying at Android Handy / Windows Client
-> PortB (Digital for Software UART (Wifi Board ) Tx, Rx RB0, RB1 ) for Forwarding Incommings ( RS232 HW ) and Communication
-> RS232 HW for MIDI IN / Midi Out
Next i make 4051 Mux/Demux at Free Ports.. i am not shure, how i must make this... so i will ask next Time for this, because this is
a big "step" for me and i think i can not do this allone by my self...

..i want say:

Don't give up!
You will found the little "bug" ... whatever this will be...
in the PIC18F2550 the last "bug" was CCP2 MUX...was set RB3 / can set to RC1 ... in the config bit
was wrong - if i change this to RC1 the SD Card was go on... ( i have test at First Time with RC1, RC0, RA4, RA5.. but this was wrong .. )
Now i give the SD at Pins RB4..RB7

The only thing that is not correct run with PIC18..
SD work.. but make sometime a little other..
i know, that i must take a FIFO / Buffer for the Data..
this will done next time,, and then the sd will work like my "LS-MIWI" ( goggle this - that i make with FC6

and Benj 's Tip with "Circular Buffer"... -- like a dream for me

i have give up my Project.. because allways data was shake and missed... then benj give me the tip with "Circular Buffer"... i have understand the prinzip and the LS-MIWI was go on perfect for me.
btw @benj thank you again

..

Not allway's "understand MM" the problem that user have, because many do not speak english in mother language,,,and sometime the problem is not declared right..
so allways give many many input .. rather too much than too little...( this i google with translater )

.. i hope you can go on next time..
..

Best wishes
Rudi

mikn · Post by **mikn** » Tue May 06, 2014 1:43 pm

The difference between your and mine project is that you create it by yourself and I have already running hardware with another firmware and just change the firmware to my version. So I am 100% sure the hardware works ok. Just need to sort up the software part.
I hope Matrix will do the update soon. But anyway it could be great to have kind of a reply "yes we have found the bug" or "we can't replicate it and need more test from you" so I won't loose the time and make more tests (but I've tried almost all variants).

Rudi · Post by **Rudi** » Tue May 06, 2014 2:13 pm

mikn wrote:The difference between your and mine project is that you create it by yourself and I have already running hardware with another firmware and just change the firmware to my version. So I am 100% sure the hardware works ok. Just need to sort up the software part.
I hope Matrix will do the update soon. But anyway it could be great to have kind of a reply "yes we have found the bug" or "we can't replicate it and need more test from you" so I won't loose the time and make more tests (but I've tried almost all variants).

Hi mikn,

i understand you...
btw:
my PIC24 Demo Board ..
http://www.ebay.de/itm/250960691555
the pic24 Board that runs very well with demo code in MPLAP too, in SD card too, but the demo is in hex file... the source that shure give with this is not the same. to the hex file.
if i translate the source in mplap the hex file is standard without SD Card. ;-/

...SNIP

•This demo board can also be used to demonstrate the function of PIC24 Storage Demo Board(Product Number: DB-DP11122) by Sure.
There’s a little bit difference in hardware between these two demo boards and modified program will be provided, which can be directly used.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...SNIP OFF

and this only in hex ;-(

The pins in the shema i append..

SCK.....RG6[4]
SDI......RG7[5]
SDO.....RG8[6]
SD_CS..RB11[24]

for the "SD Card" ... this is not functionallay with the SD Card Compo...
so i think - the Hadware is shared ( see side 5/6 )
the SOIC is the maigic word.....that have

SPIFlash_WP
SPIFlash_CS
SCK
SDO
SDI

.... and this is done in the "hex file" but nót in the source...
Remeber.. "little bit difference in hardware between these two demo .."
..
;-(

btw2: the mod in hardware is "pin Sharing by softcode"... still in hex..

the pic18f2550 Board is transparent

http://cgi.ebay.de/ws/eBayISAPI.dll?Vie ... 1149760397

at this the SD Card will go on at RB4..RB7 as digital Ports..

the next try i make with a same PIC24 but in the Starter Kit..
and a SD Shield, i will try to connect the same pins like the Advancer Board.
this sd shield i will take the same like i get on in PIC18F2550.

the change between the board Advancer and starter ..are:
The Advancer run with Crystal 20 MHz
The Starter Kit run with shared 12 MHz ....that share with a PIC18F67J50 ( this PIC has function like the PicKit...)
With the Starter kit i get UART well in Software Mode with the RS232 Compo
in the Advancer... no change ;-(..

so, if you have the src for the hex in your hardware, that run well,
have a detailed look into - how the code is written, you will found the point, why this not go on..
but if you have not the src - like i am - i have not the src for the runing hex - so we can hope for a tip from MM...
..

Best wishes
Rudi

Post by **Benj** » Tue May 06, 2014 4:36 pm

Hello,

I have been able to replicate the issue using the FAT component with SPI hardware on a 16-bit PIC so i'm hoping I can get this resolved for you soon.

I've tried this already but it didn't help. Still waiting for the news from Matrix. This project is stuck on the last step with FAT.
Other project is stuck with I2C pin remap, same problems.

The I2C peripherals are not re-mappable, Might have dropped the ball a bit with this issue can you remind me what is happening and I will make sure the bug is on the list for us to look into?
Sorry seen it now, ATMEGA with I2C. I will investigate.

Post by **Benj** » Tue May 06, 2014 4:47 pm

For the I2C component issue try using the I2C Master component rather than the CAL_I2C component.

The pins in hardware mode should not be configurable and it looks like the I2C Master component is correctly greying them out so they cannot be changed.

I will see if we can get the pins greyed out in the CAL component to avoid misleading what is possible.

mikn · Post by **mikn** » Tue May 06, 2014 6:48 pm

Benj wrote:The pins in hardware mode should not be configurable

External memory is located on C0/C1 pins, but hardware channel1 is C4/C5. In software it's very slow and I'm wondering how does original firmware work fast as usual?

Post by **Benj** » Wed May 07, 2014 9:51 am

Hello,

I think I may have found the problem with the 1MHz I2C in software mode. It basically works out the baud based on the calculated software clock delay in microseconds. As the delay would be 0.5us @ 1Mbps it actually ends up wrapping and giving 256us delay time or a baud of 1.9Kbps. I have modified the CAL code so that it hard codes the delay to 1us if the calculation is less than 1. The max baud with software mode is therefore currently fixed at around 500Kbps yet significantly faster than the previous 1.9Kbps.

Copy the attached file into your "C:\Program Files (x86)\Flowcode 6\CAL\AVR" and let me know how you get on.

Post by **Benj** » Wed May 07, 2014 1:34 pm

Think I've fixed the bug in the FAT component for the 16-bit PIC platform.

There was a bug in the FAT component where it tried to apply a speed change before the SPI was initialised which was locking up the program. File lives here: "C:\Program Files (x86)\Flowcode 6\components"

FAT.fcpx: (62.75 KiB) Downloaded 161 times

There was another bug in the CAL SPI file which was masking off a few of the upper bits of the SPI control register which was causing a problem during speed change. File lives here: "C:\Program Files (x86)\Flowcode 6\CAL\PIC16BIT"

PIC16BIT_CAL_SPI.c: (15.34 KiB) Downloaded 167 times

Let me know how you get on.

mikn · Post by **mikn** » Wed May 07, 2014 5:52 pm

Thanks, Benj! I will test them on Monday and report here if there will be any issues.

Matrix user forums

FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data

Re: FAT: faster way to write data