I really should export Ndless's program launcher to let you call it instead of replicating it in your shell. This would avoid: - bugs duplication such as the missing clear_cache() in your code which may make the launch crash in some conditions - breaking your shell if the program format changes, which may happen when new features are included (such as compatibility flags or other programs metadata)
Sharing functions dynamically would require dynamic libraries, which is not supported and not really planned in Ndless. But these functions can also be exported as a static library, bound with the program launched at compile time (see how libndls is built and used or bwang's C library somewhere on Omnimaga).
Sharing variables would require a Shared memory, I don't know if the TI-Nspire includes anything like this. A dirty workaround would be to pass the address of a memory block allocated by the shell to the programs launched as a command line parameter, and access the variables relatively to this base address. This could also be used to call back dynamically functions from the shell by the way.
Just try to malloc() or realloc() and check a NULL return.
We could also try to export in Ndless the Nucleus memory pool object used by the OS and make possible direct reads of the free space value from the structure.
EDIT: Could the Nspire-gcc errors be due to the ARM toolchain not being set up correctly? I installed an arm-linux-gnueabi instead of the recommended arm-none-eabi.
Ok: - Make sure "which arm-linux-gnueabi-gcc" returns something in a console - Replace all the occurences of "arm-linux-gnueabi-gcc" with "arm-linux-gnueabi-gcc" in the scripts nspire-gcc, nspire-as and nspire-ld.
Show Posts
