SDK programming on fx-9750GIII
Posté le 23/10/2020 05:06
Hi, I hope it's ok if I post a question in English. Please answer in French if you like.
I just got an fx-9750GIII that I would like to make an add-in for. I setup the SDK as described here:
Programmer en C sur Graph 35/75 +E I was able to compile the example program and run it in the simulator.
I copied the Default folder and MonochromeLib files described here so the SDK will produce an SH4 add-in.
[Tutoriel] Configurer le SDK pour le rendre compatible SH4 I created a new project and got warnings about SH4_compatibility.h redefining key macros. I put #define __KEYBIOS_H__ at the top of my file so keybios.h would not include key constants and the warning went away.
My project contains MonochromeLib.c, SH4_compatibility.c, and main.c. It compiles to a G1A that is 4.34k. When I run it in the simulator, I get an error saying "Nonexisting memory by data write access at 87FFFFFC" and the trace jumps to the declaration for GetKeyMod, but maybe that is normal for the simulator if it doesn't support the new GIII. When I run the add-in on my calculator, the screen freezes and I have to press the reset button on the back.
What can I do? Does anyone have an empty project that will compile and run for the 9750GIII or 9860GIII that they can share?
Here is my code:
define __KEYBIOS_H__
#include "fxlib.h"
#include "SH4_compatibility.h"
#include "MonochromeLib.h"
// #include "string.h"
int AddIn_main(int isAppli, unsigned short OptionNum)
{
unsigned int key;
//Bdisp_AllClr_DDVRAM();
ML_clear_vram();
locate(1,4);
Print((unsigned char*)"This application is");
locate(1,5);
Print((unsigned char*)" sample Add-In.");
while(1){
GetKey(&key);
}
return 1;
}
Citer : Posté le 18/07/2021 15:55 | #
Thank you for investigating this! I thought you hade a bit more experience with Linux, so I included some details below to hopefully clear some things up for you.
Yes precisely. PATH is, as you may know, an environment variable, a kind of named variable that is defined for each process in the system (this applies to almost any OS, not just Linux). PATH is ubiquitous at it is used to locate programs, and it is important that it is passed properly from process to process, so that CMake can for instance find sh-elf-gcc.
The export command is a shell command that does two things; first it assigns a shell variable (which is like any variable in a C program); second instructs the shell to export it, meaning that every process which the shell spawns from that point on will have that PATH passed as an environment variable.
(For your information, when you log in you have what is called a login shell running behind-the-scenes along with your desktop, and that shell is what reads .profile. It exists as long as you are logged in. This is not the same shell that you obtain when you obtain a terminal; that one is tied to the terminal window and is closed with it.)
By printing PATH from inside the fxsdk script, you have proven that the value of this variable for the fxSDK process is not what we intend it to be. So the question is why would the shell not set the PATH as we intend when starting the fxsdk process? This all seems pretty strange to me, but there is surely a reasonable explanation. Do you run the fxsdk command with env or sudo or another wrapper program?
Addition: It doesn't matter where you put the echo "$PATH" in the script since the variable is never changed. Still, you are correct that there is only a single call to CMake.
Citer : Posté le 18/07/2021 19:54 | #
Thanks for all the details! This is very good to know and new to me.
Yes, running fxsdk with sudo seems to be at least part of the problem. The script prints the whole PATH if I run it without sudo, which is probably to be expected if you know more about Linux than I do. Hmm, I was getting a load of permission denied errors, which led me to try fxsdk with sudo. I tried building fxsdk without sudo since it may need to see the full PATH:
make -C build
make -C build install without sudo produces an error:
file INSTALL cannot copy file
"/home/temp/fx9750giii/sh-elf-2.36.1-11.1.0/fxsdk/build/fxsdk.sh" to
"/usr/local/bin/fxsdk": Permission denied.
I tried with sudo and it appears to have installed correctly.
Building gint is producing a new error:
[ 1%] Building C object CMakeFiles/gint-fx.dir/src/cpg/cpg.c.obj
[ 2%] Building C object CMakeFiles/gint-fx.dir/src/cpu/atomic.c.obj
[ 3%] Building C object CMakeFiles/gint-fx.dir/src/cpu/cpu.c.obj
[ 5%] Building ASM object CMakeFiles/gint-fx.dir/src/cpu/ics.s.obj
[ 6%] Building ASM object CMakeFiles/gint-fx.dir/src/cpu/registers.s.obj
[ 7%] Building C object CMakeFiles/gint-fx.dir/src/cpu/sleep.c.obj
[ 9%] Building C object CMakeFiles/gint-fx.dir/src/dma/dma.c.obj
[ 10%] Building ASM object CMakeFiles/gint-fx.dir/src/dma/inth.s.obj
[ 11%] Building C object CMakeFiles/gint-fx.dir/src/dma/memcpy.c.obj
[ 12%] Building C object CMakeFiles/gint-fx.dir/src/dma/memset.c.obj
[ 14%] Building C object CMakeFiles/gint-fx.dir/src/intc/intc.c.obj
/home/druzyek/fx9750giii/sh-elf-2.36.1-11.1.0/gint/src/intc/intc.c:9:10: fatal error: string.h: No such file or directory
9 | #include <string.h>
| ^~~~~~~~~~
All of this was rebuilt on a fresh VM. sh-elf-gcc --version and echo $PATH from the command line both show as expected.
Citer : Posté le 19/07/2021 13:25 | #
Okay so now the problem is identified. Using sudo will indeed clear the PATH.
This is because sudo is very careful with invoking commands as super-user, as small details can hide critical security vulnerabilities. In particular, sudo clears the environment and sets it to some default values so that the caller's environment does not bleed onto the super-user process. There is an option to preserve the environment (which may or may not be allowed by policy), but I don't recommend using it because the real problem is using sudo altogether.
The commands you are showing are for building and installing the fxSDK. Even if you install a program in /usr/local (the almost-universal default), which is a root directory and thus requires sudo to install to, you can still execute the program without sudo after installing it. This is because the program is marked as world-executable, meaning that anyone can run it. In fact, almost all of the commands that you run daily are installed in /usr but can be executed by anyone.
Note that you should not run random/amateur programs as sudo, not necessarily because of trust issues, but to protect against mistakes. For instance, the scripts I have written are tested, but not nuclear-security-level tested. It is possible that under some circumstances the script fails and deletes the wrong file. Not using sudo protects your system against such mistakes because the script would not be allowed to remove important files. When using sudo, a bug that goes wrong on accident can really mess you up. For this reason, people who make non-sensitive/lighthearted programs like me ensure that you can avoid sudo as often as possible.
Now, installing the fxSDK in a root folder is not a problem in itself, it's fine. As you can see on the main README I suggest using a different install folder (which is called the «prefix» in this context). Programs build with CMake use the -DCMAKE_INSTALL_PREFIX option to that effect.
Typically, instead of /usr/local which is a root folder, you could have installed in ~/.local which is a common non-root one. This would have gone like this:
Since the fxSDK doesn't try to write files after it's installed, you can leave it in /usr/local. But other programs such as sh-elf-gcc would not play so nicely, as they write files often, and almost every fx-9860G or fx-CG 50 library out there adds their own. If you install sh-elf-gcc in a root folder, you will have all kinds of trouble with permissions and you will end up using sudo all the time, which is really annoying and a bit risky too.
Anyway, back to your problem. Your fxSDK install seems to work fine, the gint error you have is because the standard library has recently been split up. gint used to provide a couple of functions from the standard library, but this could not go on forever, so I joined Yatis' effort to build a proper libc which is now at fxlibc.
It's almost comical how many repositories there are now (^^"), if you get bored of it you might want to try Dark Storm's pre-built packages (for Arch Linux derivatives and maybe soon for Debian ones too, as he mentioned earlier today he wanted to explore that route) or GiteaPC which does the same Git stuff as you do but automatically.
Citer : Posté le 05/08/2021 01:40 | #
Thank you for the very full explanation of all this. I wasn't able to install GiteaPC on Ubuntu the last time I tried. I'll give it another try while you get gint straightened out with the new library. Could you let me know how to uninstall gcc, fxsdk, and the other things that might interfere with GiteaPC? Thanks again.
Citer : Posté le 05/08/2021 08:27 | #
For binutils and GCC, you need to remember you $PREFIX; if not, run which sh-elf-gcc, the prefix is everything before bin/sh-elf-gcc.
You can manually delete:
For the fxSDK, you need to identify the prefix again with which fxsdk; I believe this time it's /usr/local.
Delete (with rm -f so that files that don't exist don't cause errors):
If you have installed libraries (gint, OpenLibm, fxlibc, etc.) they will be gone when you delete GCC.
I'm sorry you have to go through such trouble every time, if you have any feedback to improve the process I'll be happy to try and make it simpler. x)
Citer : Posté le 10/08/2021 02:29 | #
Good news - I was able to install GiteaPC this time around.
As far as advice, avoiding the entire build process with GCC and gint is probably the best way to go since the process just doesn't work on Ubuntu. Using GiteaPC is a good option, although this is also not reliable on Ubuntu as I found out last time I tried. Maybe a single .deb file that installs everything and is verified to work on Ubuntu?
Thanks again!
Citer : Posté le 10/08/2021 09:02 | #
Excellent - I hope this is the end of it. As far as Ubuntu is concerned I can try and add support. Previously you've mentioned sh vs. bash (with errors on [[) and another error which you did not save. Is it one of these?
A .deb file is also a possibility; I will admit I've avoided it so far because there are quite a few distributions out there and I don't think I have the energy to maintain a lot of binary packages. I'm banking on the fact that if you can follow the tutorial then I should be able to automate it... we'll see if it holds.
Thank you for your patience