Omnimaga > Ndless

Some syscalls disable IRQs/FIQs

(1/1)

Vogtinator:
When I enable interrupts using

--- Code: ---    __asm__ volatile("mrs r0, cpsr;"
                    "bic r0, r0, #0x80;"
                    "msr cpsr_c, r0;" ::: "r0");
--- End code ---

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?

bsl:
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:

--- Code: ---//---- 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 * )

--- End code ---

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:

--- Code: ---//---- 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 )

--- End code ---

Vogtinator:

--- Quote ---For the uart, it might be better to use the Nucleus SDC_* API directly than using the standard library.
--- End quote ---
This doesn't actually solve the issue with ndless' swi handler. I'm currently ill and have no time to debug it, though :(


--- Quote ---Try using SDC_printf() or SDC_Put_String() [formerly called log_rs232]
SDC_Put_String has been tested , SDC_printf untested
--- End quote ---
Untested in which way? Bugs not completely explored or SDC_printf("Hello World!") may not even do anything?


--- Quote ---The program goes resident after hooking into the Battmon task{That frequently updates the battery icon on the screen} . :D
--- End quote ---
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

--- Code: ---#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");
}
--- End code ---
which works without custom syscalls (and will/should therefore directly work with ndless 3.6).

bsl:

--- Quote ---Try using SDC_printf() or SDC_Put_String() [formerly called log_rs232]
SDC_Put_String has been tested , SDC_printf untested
--- End quote ---
> Untested in which way? Bugs not completely explored or SDC_printf("Hello World!") may not even do anything?
SDC_printf is untested.


--- Quote ---The program goes resident after hooking into the Battmon task{That frequently updates the battery icon on the screen} . :D
--- End quote ---
> 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

Navigation

[0] Message Index