SDFileSystem interfering with buttons?

I was trying to write an interface to make the file library a bit easier to use, but for some reason when I use a global SDFileSystem, the Pokitto’s buttons (apart from the right button) become unresponsive.

I’m using the same pins used in other examples:

SDFileSystem sd
(
	/*MOSI*/P0_9,
	/*MISO*/P0_8,
	/*SCK*/P0_6,
	/*CS*/P0_7,
	/*Mountpoint*/"sd",
	NC,
	SDFileSystem::SWITCH_NONE,
	25000000
);

If I remove the object, the buttons work again.

Here’s the bin with sd defined:
WithSD.bin (53.4 KB)

Here’s the bin without sd defined:
NoSD.bin (25.0 KB)

And here’s the code:

The annoying thing is I did manage to get SDFileSystem working before, hence this thread.

It’s possible that the two are related somehow.
It’s also possible that it might be a mistake in my project settings, but I think it’s unlikely.

Its the mbed interrupt handler. It doesn’t seem to like my hardcoded handlers.

Fortunately, the fix is easy. I will replace the mbed handler but keep the level triggering.

It will take me a while to get to this as I am currently working on a new repository that can be imported to EmBitz / mbed online / Platformio

1 Like

I had a feeling that would be the case.
There’s no rush to get it going if you’re busy.


Could that be causing an issue with petifatfs as well?

There’s another issue I had but I haven’t got round to posting about it.
Using petifatfs the file reading was working but the file writing wasn’t.
It was writting the same data to file no matter what I gave it to write,
(or at least it seemed to be the same).

I won’t go into detail for now.
One problem at a time.


I noticed the new repo.
I think I starred it about 18 minutes after creation.

Meanwhile, perhaps you could comment on this:

PokittoCore cpntains toolchain settings for ARMCC (mbed online) and GCC (EmBitz). It also contains a ready-to-go project (with your base target system) for EmBitz. However, if you import the repo to mbed online, the example target is hidden inside PokittoCore folder and may cause confusion & problems (if user also provides main function etc)

What shall we do? Should we require user to always provide main.cpp and.My_settings.h?

Now that there seems to be a lot of interest to read and write to SD: I am using both PetitFFS and SDFS at in the Tracker project, PFFS for reading (because it is faster) and SDFS for writing (as it can create new files and folders). I have removed all NOPETITFATFS defines from the PokittoLib.

So the question is that should I make a Pull Request of it now? Is that something you need?

We could do.

It’s an extra step, but it’s not too much of a problem.
My_settings.h is more of an issue than main.cpp since adding your own main.cpp is common practise in other environments.

Normally I’d say resolve the interrupt conflict first because bugfixes are more important than features, but it might be easier (from a Github merging point of view) to add the changes needed to have both file system mechanisms working simultaneously.

That said, if the interrupt conflict would mean we wouldn’t be able to test the dual filesystem then that could be a problem.

So basically I think it boils down to how easy it would be to merge the two and how easy it would be to test whether the changes work after merging.

The interrupt fix is a 15 min thing. You can make the PR if you’re ready for it.

@Pharap : I will simply make an optional PokittoHelloWorld repo. So if one wants a ready-to-go template, you can additionally clone the HelloWorld repo

1 Like

Would it be worth keeping the ‘ready to go’ template in for the EmBitz users?
And would the PokittoHelloWorld repo work for both mbed online and EmBitz?


While we’re discussing issues, I’ve got this PR ready to solve issue 17.
I’d ideally like to help clear the issue backlog.
I hope to look into issue 16 at some point and then maybe we’ll be able to completely clear the issue backlog.

I am finalizing an example program for it.

1 Like

Ok, there is now a PR for using PFFS and SDFS in the same program. I made an example program “SDCardIO” which tests and measures the performance in reading, writing and making a directory in SD.

I also fixed Core:filemenu() function which can be used to select a file from SD.

Let me know if you find problems in SD card writing or reading. I have tested it with Tracker and SDCardIO programs.

5 Likes

@Pharap and @Hanski, I have compiled (using Hanski’s version of the pokittolib which can combine both filesystems), checked and compared both of your example programs and these are my observations:

  • @Hanski: your program runs fine (except for the petitffs part)
  • @Pharap: when I run your program unaltered, some buttons do not respond indeed (for example button A, so I cannot pass the volume screen), however when I place this part
SDFileSystem sd(/*MOSI*/P0_9, /*MISO*/P0_8, /*SCK*/P0_6, /*CS*/P0_7, /*Mountpoint*/"sd");

in the main function just after Pokitto::Core::begin(); it does work and all of the buttons seem to respond again.
Edit: I got this program running https://github.com/Pharap/DiskioIssue

3 Likes

What about before begin?
If it only works after begin then we know it’s a conflict with begin.
If it works before begin then it’s an issue with it being initialised at the global scope.

After some more testing: it works when it is placed inside the main function (before or after begin does not seem to make a difference).

1 Like

In that case the problem is with global initialisation,
which is strange to say the least.

maybe someone else should also test and confirm this…