Hi, Now ticker is working fine with interrupt handling, context switch happening as expected. The problem is that put_name() and print_time() are not producing any output (except for the first three instances before _Thread_Dispatch get them executing again after _Thread_Delay_ended has been executed for each of them), however, when I replaced them with printk I got the output as expected. Also printf is not working there. At the end of the test when calling rtems_test_exit and _exit, I got "Fatal Error 4 Halted" (I have implemented _CPU_Fatal_halt to print the error this way at cpu.h). Any hints what's the problem?
On Sat, Jul 19, 2014 at 12:11 AM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > The ASM macro needs to be properly used in rtems/score/cpu.h. > > I sent a patch to devel@ but it is really a hack. Things compile but > I wouldn't trust it. > Thanks for the patch. > + ASM should protect C only code from being used in .S code. > And vice-versa. > > When I started, there was C code exposed to .S. When I blocked > off a huge block of the code, I discovered two macro constants > in the middle that were needed in .S files. Please check how these > are done in other ports to minimize the number of ifdef's and > to keep things logically together. The area I saw them in looked > like a dumping ground for miscellaneous stuff. Maybe you inherited > it but I don't like it. > > Also ... > > + minimum failed to compile in a weird way. Could be a side-effect > of what I did but I don't see how. > > + I don't like your cpu isr disable/enable. Post the bodies in a > new email thread. I think neither is using the right asm constraints. > And enable seems to be using too many instructions. My guess is > you only need to get the value in a register and move to the spr. > Handling the constraints right will probably reduce this to one > instruction. We need Christian's help since I don't know or1k asm. > > + disable didn't return the previous level so it couldn't be restored. > > + I (think) I fixed the prototype for _CPU_Initialize_fp. > > In general, any warning originating from score/cpu code is very bad > and usually indicates a real problem. It also results in 1000s of > warnings in the build logs. > > --joel > > On 7/18/2014 3:16 PM, Hesham Moustafa wrote: >> On Fri, Jul 18, 2014 at 4:19 PM, Gedare Bloom <ged...@rtems.org> wrote: >>> I see you are kind of copying the file structure of ARM. I'm not sure >>> this is a good example for a simple port. m68k is more >>> straightforward. >>> >> Which file?y >>> -Gedare >>> >>> On Fri, Jul 18, 2014 at 10:17 AM, Gedare Bloom <ged...@rtems.org> wrote: >>>> On Fri, Jul 18, 2014 at 1:35 AM, Hesham Moustafa >>>> <heshamelmat...@gmail.com> wrote: >>>>> On Thu, Jul 17, 2014 at 3:10 PM, Joel Sherrill >>>>> <joel.sherr...@oarcorp.com> wrote: >>>>>> This definitely sounds like not handling the context switch necessary >>>>>> part of the >>>>>> IRQ processing properly so always returning to IDLE. I call this a >>>>>> simple return. >>>>>> >>>>>> All ports have a version of this code. no_cpu should have reasonable >>>>>> pseudo-code. >>>>>> m68k is likely the easiest to read as real code. >>>>>> >>>>>> You need to do a simple return if: >>>>>> >>>>>> (a) IRQ is nested, or >>>>>> (b) DISPATCH_NEEDED is false >>>>>> >>>>> This is a macro that defines the address of the corresponding variable >>>>> within the per cpu config table right? Please correct the following if >>>>> I it's wrong. From assembly (when doing restore after C ISR handler is >>>>> executed), I have to load this variable value, check if it's true >>>>> (greater than zero), and if yes, jump to _ISR_Dispatch. I am a little >>>>> confused what context should be loaded in both cases of: simple >>>>> return, and _ISR_Dispatch; In case of _ISR_Dispatch, should I save >>>>> stack pointer and return address and other context like normal context >>>>> switch (function call)? While in interrupt context (simple return), I >>>>> am saving almost all registers with some other necessary registers >>>>> related to exceptions. >>>>> >>>> Please see >>>> http://rtems.org/onlinedocs/doc-current/share/rtems/html/porting/Interrupts-Interrupt-Dispatching.html#Interrupts-Interrupt-Dispatching >>>> >>>> Summarizing: >>>> >>>> You need to update a few variables before calling the user ISR: >>>> _Thread_Dispatch_disable_level += 1 >>>> _ISR_Nest_level += 1 >>>> >>>> And decrement them after returning. >>>> If ISRs are nested you do a simple return. >>>> >>>> Then you need to check if _CPU_ISR_Dispatch_disable is set, if so do a >>>> simple return. >>>> >>>> Then you need to check if DISPATCH_NEEDED, if so you need to do the >>>> ISR_Dispatch. >>>> >>>> >>>>> One thing I have a problem with, is when using some macros like >>>>> DISPATCH_NEEDED (it's a variable address right?) I am normally >>>>> including rtems/score/percpu.h from the assembly file (which does the >>>>> magic) to get these definitions but the compiler suffers. I think I >>>>> have to provide compiler option or something to just include #define >>>>> macros? If yes, where to add it? >>>>> >>>> Make sure to include rtems/asm.h before including percpu.h so you get >>>> the ASM defines instead of C defines, since you are (presumably) >>>> writing this in assembly. You could also use inline assembly, but then >>>> you need to use expression operands [1] to provide access to these >>>> variables instead. >>>> >>>> [1] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html >>>> >>>> -Gedare >>>> >>>>>> Otherwise, you need to some CPU specific magic to get our of the IRQ and >>>>>> back to the thread. Make it look like it called _Thread_Dispatch with >>>>>> sufficient saved registers (e.g. callee destroyed). This is usually >>>>>> called >>>>>> _ISR_Dispatch. When the call from _ISR_Dispatch to _Thread_Dispatch >>>>>> returns, you do the magic needed to return tot he interrupted thread >>>>>> (IDLE in this case) as if nothing happened. > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel