Pokitext: text editor on pokitto

Doesn’t seem to work even after formatting :confused: Emulator shows the files but Pokitto still doesn’t.

I guess I could use PFFS for listing the files and SDFS for opening and saving, but after a quick try now it does this: listing directory files works (PFFS), then I save a file (SDFS), and now I can no longer list directory files (PFFS, even if I call pokInitSD before every attempt to list the files. Code here).


And also now I found that I can’t even open a file on Pokitto with SDFS (PFFS was able to open it. Emulator opens it even with SDFS). I dunno, I must be doing something horribly wrong.

You can’t use both libs at the same time, SD cards have state and the libs will interfere with each other.
I’ll give the code a look when I get home, I don’t have my Pokitto with me.

Edit: Have you tried my loader? Does it work with your card? Just trying to isolate the cause.

Can you upload your makefile and my_settings.h?

1 Like

Well I thought so, but this example is using them both?


Will do.


Works. So it’s probably just me screwing up :smile:

Thanks for the assistance!

Maybe, maybe not. That filesystem lib there has been tweaked/bugfixed a bit.
Now we know it’s not an issue with your card, I’ll try to see if I can reproduce the issue here.

This works:

    DirHandle *dir = sdFs->opendir("/");

    while (i < TextEditor::MAX_FILE_NAMES)
      dirent *ent = dir->readdir();
      if (ent == 0)
      fileName = ent->d_name;



Calling closedir is important, otherwise you’re leaking a lot of memory.

1 Like

Awesome :slight_smile: no need to rush though, I’m leaving it for tomorrow anyway.

PokittoLib seems to need a refactor here, I’m struggling with the lack of documentation and a simple, unified API.

1 Like

Alright, gimme a sec to try.

1 Like

I totally agree.

Nope sorry, still doesn’t work for me :neutral_face: I’ve even reformatted the card again. I’ll have to get a sleep for this. But you’ve fixed me one bug at least, that’s good.

It’s not easy I know. You first want to make automated tests to make sure you don’t break things in the process. This needs some planning.

How are you testing it?

I formatted the card to FAT32, put two small txt files on it, then put the card to Pokitto, turn it on, open the menu in the editor (just navigate with arrow keys), select “open” and there it freezes (ATM there’s no error checking so NULL dereference happens… on emulator files are correctly listed).

Hmm… that’s exactly what I did, but the file list worked and I was able to open a file, go back to the list, open another, and so on.
Try my build? firmware.bin (97.4 KB)
(No hurry, go to sleep already :stuck_out_tongue: )

Am on mobile now, but I’ll try it before sleep. This definitely seems weird, I bet it’s some awkward mistake on my side :smile:


Your bin freezes as well. I don’t get it, your loader worked, so the card has to be working. And PFFS was able to list the files as well. Yes, my SD card is actually in the Pokitto right now. Very very strange. I’ll look at it tomorrow!


Unless your SD card isn’t plugged in properly (actually happened to me once, had me scratching my head wondering why file access suddenly stopped working), it doesn’t sound like it’s just a mistake. :thinking:

Try this:
Install Loader v0.0.3 then test this bin: firmware.bin (67.4 KB)

1 Like

I was actually once trying to access the card while it’s been in the laptop, so now I keep checking it’s actually there.

Actually this works – the files get listed. How did you do that? I have noticed my firmware.bin is much larger, which is probably because of -O3… have you turned it off? Could that be the problem?


Without optimizations it doesn’t run :hushed: Gives just a red screen. It needs at least -O1 or -Os (it’s still bigger than your bin).

1 Like

That last bin doesn’t include a filesystem library at all, that’s why it’s smaller. It’s using the loader’s filesystem API, which is why I asked you to update. I didn’t implement a check, so if you were to install the original loader it would crash.

This rules out issues with your code and shows that there’s a problem with the combination of SDFS and your card. I suspect that if you tried the previous bin (which uses SDFS) on another card it might work.

1 Like

Yep, another card works.

What can be wrong with the card?

Hard to say without debugging SDFS on it. :thinking:

We really need a list of all these broken things so we can start fixing them.

In fact I might put these on the big TODO list later.

This is why I’d eventually like to switch to an object implementation.
Then the destructor can close the directory and nobody has to worry about leaks.