Fatfs-0.13

[cpu20]

Hi,

I have been working with GFILE for logging to a SD-card and found that opening a file for append wasn't implemented yet. This option however is has been implemented in the latest fatfs release.
So I downloaded the latest version (0.13) and replaced the current 0.10b version. As far as I have tested it everything seems to work perfectly with the new version and I also implemented the open for append option which works.
Maybe this is something to consider for µGFX v3.0?

While writing a GFILE-application I also noticed there are no example projects. So I wrote a little example project for fatfs. It's far from perfect but it can be helpful for people starting out with the GFILE-module and fatfs.

Gfile_demo_0.13.zip

[inmarket]

Thank you for the demo. Are you happy for us to add it to the repo?

Yes we would love the upgrade to fatfs-0.13. Can you please create a repo pull request and we will merge it into the current branch (and V3)

[cpu20]

20 hours ago, inmarket said:

Thank you for the demo. Are you happy for us to add it to the repo?

Yes of course!

20 hours ago, inmarket said:

Can you please create a repo pull request

My account on the official repo page isn't activated so I can't do a pull request there.

For now I've pushed it to GitHub: https://github.com/cpu20/uGFX-fatfs0.13
But it seems like my uGFX copy has a lot of leftover changes (3 other commits) which I must revert first. I'll look into cleaning those up tomorrow so you can easily pull in all needed changes without pulling in any leftover files or anything.

[inmarket]

Thankyou. Let us know when it is ready.

[cpu20]

The repo is ready to be pulled in. I hope I didn't forget anything.

Note that I left in the "os_chibios_git.mk" because I changed some things since the first commit. It still doesn't work, but I think it is complete now.
The reason the file doesn't work is because ChibiOS switched form .s to .S assembly files for some startup code. This change needs to be handled in the "compiler_gcc.mk" file, but I do not have the knowledge yet to start messing around with that.

[Joel Bodenmann]

Is it just me or is the demo missing the gfxInit() call?

[cpu20]

It was indeed missing the initialization routine. Added it to the demo.

Let me know if there is anything else missing!

[inmarket]

Interesting. .s and .S are synonymous under windows because the file system is case insensitive. Whilst case can usually be controlled it is not reliable. For .c/.C files the .C files are typically renamed .cpp or .c++ (depending on the compiler/make system) for windows. I will need to investigate the equivalent for .s/.S so I can add the correct handling to compiler_gcc.mk for both windows and unix based systems.

Note: as a result of the above problems the use of .C is falling out of convention and is now sometimes not supported even on linux.

 

[cpu20]

I have been struggeling with .s and .S files before in Eclipse (on Linux) because Eclipse only recognizes .s files. At that time I found that according to this thread, that the .S files are first being processed by the preprocessor when using gcc whereas .s is not.

But I have no idea what has to be changed in the makefile to adopt for this change...

[Joel Bodenmann]

6 hours ago, cpu20 said:

I have been struggeling with .s and .S files before in Eclipse (on Linux) because Eclipse only recognizes .s files. At that time I found that according to this thread, that the .S files are first being processed by the preprocessor when using gcc whereas .s is not.

From personal experience I can confirm that that is indeed the truth.

 

6 hours ago, cpu20 said:

But I have no idea what has to be changed in the makefile to adopt for this change...

I'm gonna leave that to @inmarket as he's the original author of the makefile wizardry. It's complex, especially when things like auto-substitution of cygwin paths come in and so on.

[inmarket]

1. The master repo has now been updated to FATFS-0.13
2. The GFILE FATFS demo has been added
3. The makefile system has been upgraded to support .S files

Thankyou @cpu20 for your fantastic work in getting this ready.

[Joel Bodenmann]

Great work guys! Much appreciated!