Omnimaga
Omnimaga => Our Projects => Ndless => Topic started by: Vogtinator on January 24, 2014, 06:38:11 pm
-
When I enable interrupts using
__asm__ volatile("mrs r0, cpsr;"
"bic r0, r0, #0x80;"
"msr cpsr_c, r0;" ::: "r0");
and call "printf", "fputs" etc. the 0x80 bit is set again.
Workaround is to clear the bit in the CPSR after the syscall.
SPSR_svc seems to have the correct value in the SWI handler.
I'm using ndless 3.1 r914, is this a bug or did I overlook something important?
-
For the uart, it might be better to use the Nucleus SDC_* API directly than using the standard library.
Try using SDC_printf() or SDC_Put_String() [formerly called log_rs232]
SDC_Put_String has been tested , SDC_printf untested
rs232 output routines:
//---- uart output routines ----
static const unsigned SDC_printf_addrs[] = {0x0, 0x0,0x101019AC,0x0}; // OS 3.1
#define SDC_printf SYSCALL_CUSTOM(SDC_printf_addrs ,int, char *fmt, ... )
static const unsigned SDC_Put_String_addrs[] = {0x0, 0x0,0x101018E0,0x0}; // OS 3.1 formerly log_rs232
#define SDC_Put_String SYSCALL_CUSTOM(SDC_Put_String_addrs ,int, char * )
I have a simple shell using rs232, without the clock on the screen :)
The program goes resident after hooking into the Battmon task{That frequently updates the battery icon on the screen} . ;D
The 2 uart input routines I used for this are listed below.
This seems to be the first multitask friendly Ndless program, that allows this interaction while doing
other things on the calculator.
rs232 input routines:
//---- uart input routines ----
static const unsigned SDC_Get_Char_addrs[] = {0x0, 0x0,0x10101838,0x0}; // OS 3.1
#define SDC_Get_Char SYSCALL_CUSTOM(SDC_Get_Char_addrs ,void, int * )
static const unsigned SDC_Data_Ready_addrs[] = {0x0, 0x0,0x101017EC,0x0}; // OS 3.1
#define SDC_Data_Ready SYSCALL_CUSTOM(SDC_Data_Ready_addrs ,int, void )
-
For the uart, it might be better to use the Nucleus SDC_* API directly than using the standard library.
This doesn't actually solve the issue with ndless' swi handler. I'm currently ill and have no time to debug it, though :(
Try using SDC_printf() or SDC_Put_String() [formerly called log_rs232]
SDC_Put_String has been tested , SDC_printf untested
Untested in which way? Bugs not completely explored or SDC_printf("Hello World!") may not even do anything?
The program goes resident after hooking into the Battmon task{That frequently updates the battery icon on the screen} . :D
I've never seen a task which does it's job worse than that...
If these syscalls have no disadvantages over the c API, why not replace printf(...) with SDC_printf(...)?
And are the addresses (3rd item) for cx cas or cx without cas?
Currently I'm using
#define fputs(s,f) irq_fputs(s,f)
inline void irq_fputs(char *s, FILE *f)
{
fputs(s, f);
__asm__ volatile("mrs r0, cpsr;"
"bic r0, r0, #0x80;"
"msr cpsr_c, r0;" ::: "r0");
}
which works without custom syscalls (and will/should therefore directly work with ndless 3.6).
-
Try using SDC_printf() or SDC_Put_String() [formerly called log_rs232]
SDC_Put_String has been tested , SDC_printf untested
> Untested in which way? Bugs not completely explored or SDC_printf("Hello World!") may not even do anything?
SDC_printf is untested.
The program goes resident after hooking into the Battmon task{That frequently updates the battery icon on the screen} . :D
> I've never seen a task which does it's job worse than that...
The *nix equivalent is a daemon process monitoring the serial port and responding to commands.
Many Nucleus tasks behave like unix daemon processes.
> If these syscalls have no disadvantages over the c API, why not replace printf(...) with SDC_printf(...)?
Previous versions of Ndless had both syscalls, since we don't have full documentation of the Nspire OS we can't choose which to take/reject.
printf and log_rs232 were on the syscall listing for Ndless2.0 and before.
Time will tell which is best.
>And are the addresses (3rd item) for cx cas or cx without cas?
noncascx 3.1