search

Timendus / ticalc-usb

A library to communicate with TI graphing calculators through WebUSB
https://ticalc.link
GNU General Public License v3.0
29 stars 4 forks source link

"Not enough free memory" error with TI-84+CE #14

Closed commandblockguy closed 3 years ago

commandblockguy commented 4 years ago

When trying to send a file to a TI-84+CE, it always fails due to a lack of memory, regardless of the actual free memory on the calculator.

This seems to be because DUSB_PID_FREE_RAM always returns 0 on the CE - I'm not sure if there's actually a way to get the quantity of free RAM on the CE.

I'm not sure what the best solution to this would be - I guess it could just try to send the file without checking RAM capacity if the device is an ez80 calc.

commandblockguy commented 4 years ago

I asked around a bit on Cemetech, and apparently it gives an accurate memory report, but only when not on the homescreen, since the homescreen uses all of RAM as an input buffer.

Timendus commented 4 years ago

Interesting. Does it matter for the calculator's ability to receive the file? If the homescreen is using all the RAM or not?

Have you tried sending a file while not on the homescreen yet?

commandblockguy commented 4 years ago

The calculator can still receive files silently while on the homescreen - I think that it deletes the input buffer or restarts the context while transferring files. I haven't tried sending files while on the mode screen (which is apparently the only screen beside the link screen where the correct RAM value is returned), as I just disabled the check on the site so I could test other things, but based on packet sniffing and the values returned by other programs it should cause the check to succeed. With the check disabled, I was able to send some programs, but not others, so I'll look into that more and create another issue.

Timendus commented 4 years ago

That last bit sounds more like a file parsing issue to me.

I guess there are a few obvious ways to fix this RAM issue:

  1. Ask the user to go into receive mode manually
  2. Ask the user to be okay with sending the file, even though there doesn't seem to be enough RAM
  3. Just send the file without checking for space
  4. Check for space in either RAM or flash (does that even make sense?)

I don't really like any of those. Also, I don't like that with the current API all of them would need to be implemented by each different application using this library. And risk getting implemented in different ways. A slightly more elegant way to solve that is to extend the calculator.canReceive(file) method to check for space too, and count calculator.getFreeMem().ram == 0 as there being space for some models..? That at least insulates the consuming application from the weird specifics of the different devices.

commandblockguy commented 4 years ago

Perhaps, depending on the model, calculator.getFreeMem() could return undefined for ram if it would otherwise be 0. End applications would have to account for the free RAM not being known one way or another anyway. I also think that just sending the file without checking free space (at least on calcs where that's not possible) would work fine, as the transfer will just fail if there's not enough free space. Also, some variables receive directly into flash, so you would have to check the amount of free flash for those, but the amount of free RAM for others. So, that would be another reason to move the memory check into calculator.canReceive().

Timendus commented 3 years ago

@commandblockguy I have deployed both fixes. Can you check if this has solved your issues? Then we can move on to the next problem, that some files don't send, in a new issue :)