ARMv7M Exception Handler
Hey guys, I was working on the exception handler for the CPU hard fault. Managed to register the fatal error user extension to RTEMS and call the user defined function when an exception occurs. But the pointer to the stacked frame didn't have the correct register values(esp. the PC register). So I looked into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c, where it decides which stack pointer was used (MSP or PSP) before the exception occurred depending on the error code returned in the Link Register. After carefully examining all the assembly instructions, I guess theres a little bug in the code. The instruction "cmn r2, #3\n" in line 31 basically compares the Link Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS and compares with LHS) and chooses MSP or PSP in the following IT block. This is pretty cool! But, it will not work if you have the floating-point unit (FPU) enabled in your processor, which is enabled in mine. With FPU enabled, the error code returned is either 0xFFE9 or 0xFFED, for which the above assembly instruction will not work out and MSP will be selected always. Better way to do is to check the 2nd bit of the error code to determine which stack pointer was used before the exception happened - "tst lr, #4\n" and change the IT block from "itt ne" to "itt eq" and the "mov" and "add" within this IT block. Have tested this with the above changes and it works. I have sent the patch "0001-Fix-exception-handler-for-supporting-FPU.patch" to the devel mailing list that fixes this problem. :) Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix exception handler for supporting FPU
Patch attached here for ARMv7M Exception Handler. [1] Looks like git
send-email didn't deliver the mail. Something is not quite right with
our mail server here. Avoid this email if patch delivered through git.
Thanks and Regards,
Sudarshan
Links:
--
[1] https://lists.rtems.org/pipermail/devel/2015-August/012381.html
From e7674a2c26a3db26e3019f3c6ee94c9ea88d5a3c Mon Sep 17 00:00:00 2001
From: Sudarshan Rajagopalan
Date: Thu, 27 Aug 2015 14:19:24 -0400
Subject: [PATCH] Fix exception handler for supporting FPU
---
cpukit/score/cpu/arm/armv7m-exception-default.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c
b/cpukit/score/cpu/arm/armv7m-exception-default.c
index e890cdf..2ddc6fc 100644
--- a/cpukit/score/cpu/arm/armv7m-exception-default.c
+++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
@@ -28,10 +28,10 @@ void __attribute__((naked)) _ARMV7M_Exception_default( void
)
"mov r2, lr\n"
"mrs r1, msp\n"
"mrs r0, psp\n"
-"cmn r2, #3\n"
-"itt ne\n"
-"movne r0, r1\n"
-"addne r0, %[cpufsz]\n"
+"tst lr, #4\n"
+"itt eq\n"
+"moveq r0, r1\n"
+"addeq r0, %[cpufsz]\n"
"add r2, r0, %[v7mlroff]\n"
"add r1, sp, %[cpulroff]\n"
"ldm r2, {r3-r5}\n"
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: ARMv7M Exception Handler
On 2015-08-27 17:06, Joel Sherrill wrote: On 8/27/2015 3:58 PM, Daniel Gutson wrote: On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan wrote: Hey guys, I was working on the exception handler for the CPU hard fault. Managed to register the fatal error user extension to RTEMS and call the user defined function when an exception occurs. But the pointer to the stacked frame didn't have the correct register values(esp. the PC register). So I looked into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c, where it decides which stack pointer was used (MSP or PSP) before the exception occurred depending on the error code returned in the Link Register. After carefully examining all the assembly instructions, I guess theres a little bug in the code. The instruction "cmn r2, #3\n" in line 31 basically compares the Link Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS and compares with LHS) and chooses MSP or PSP in the following IT block. This is pretty cool! But, it will not work if you have the floating-point unit (FPU) enabled in your processor, which is enabled in mine. With FPU enabled, the error code returned is either 0xFFE9 or 0xFFED, for which the above assembly instruction will not work out and MSP will be selected always. Better way to do is to check the 2nd bit of the error code to determine which stack pointer was used before the exception happened - "tst lr, #4\n" and change the IT block from "itt ne" to "itt eq" and the "mov" and "add" within this IT block. Have tested this with the above changes and it works. I have sent the patch "0001-Fix-exception-handler-for-supporting-FPU.patch" to the devel mailing list that fixes this problem. :) Nice. Have you tested this without FPU support too? Hi Daniel, Just tested the fix with FPU disabled in my processor and it works fine. This patch can be pushed! Daniel .. when you are happy, we can push it. Should this go on the 4.11 branch and master? If so, it needs a ticket. Joel, I think this fix is vital and should be pushed to master. Will make a ticket for this. Thanks and Regards, Sudarshan -- Sudarshan Rajagopalan sudarshan.rajagopalan at vecna.com www.vecna.com Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix exception handler for supporting FPU
On 2015-08-28 11:30, Daniel Gutson wrote: On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom wrote: Could you please open a ticket on our trac to describe the problem this fixes, and add "closes #." to your patch commit message? Hi Gedare, Sure will do! Additionally, please clarify which architecture this applies to. I suspect this is for cortex-m4. In any case, please clarify which architectures you tested on. We can analyze and test cortex-m3 if you don't have one. Daniel, I've tested it on Cortex-M4 but this patch should also apply to Cortex-M3 or all ARMv7M based processor (including M7). But please feel free to test it on Cortex-M3 since I don't have it with me now. Am also attaching the links to ARM Cortex-M3, M4 and M7 Exception entry and return referenece documents for a quick reference, where the table gives all the possible exception error codes returned and which SP to pick depending on the error code. The only tricky part would be error code: 0xFFE1. But the asm "tst.w lr, #4" with lr=0xFFE1 will result into zero and will set the Zero flag, which will make the ITT EQ block execute, which will choose MSP, which it should for the return code 0xFFE1 (or even 0xFFF1) in all M3, M4 and M7. But please feel free to test it on real M3 an M7 processor. I have tested it by manually giving all the return error codes for M3 and M7 to LR and and it chooses the right SP value. ARM Reference Docs - Exception Entry and Return: C-3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Babefdjc.html C-4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html C-7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/Babefdjc.html Thanks and Regards, Sudarshan Thanks, Gedare On Thu, Aug 27, 2015 at 4:33 PM, sudarshan.rajagopalan wrote: Patch attached here for ARMv7M Exception Handler. Looks like git send-email didn't deliver the mail. Something is not quite right with our mail server here. Avoid this email if patch delivered through git. Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: ARMv7M Exception Handler
On 2015-08-28 11:37, Daniel Gutson wrote: On Fri, Aug 28, 2015 at 12:33 PM, sudarshan.rajagopalan wrote: On 2015-08-27 17:06, Joel Sherrill wrote: On 8/27/2015 3:58 PM, Daniel Gutson wrote: On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan wrote: Hey guys, I was working on the exception handler for the CPU hard fault. Managed to register the fatal error user extension to RTEMS and call the user defined function when an exception occurs. But the pointer to the stacked frame didn't have the correct register values(esp. the PC register). So I looked into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c, where it decides which stack pointer was used (MSP or PSP) before the exception occurred depending on the error code returned in the Link Register. After carefully examining all the assembly instructions, I guess theres a little bug in the code. The instruction "cmn r2, #3\n" in line 31 basically compares the Link Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS and compares with LHS) and chooses MSP or PSP in the following IT block. This is pretty cool! But, it will not work if you have the floating-point unit (FPU) enabled in your processor, which is enabled in mine. With FPU enabled, the error code returned is either 0xFFE9 or 0xFFED, for which the above assembly instruction will not work out and MSP will be selected always. Better way to do is to check the 2nd bit of the error code to determine which stack pointer was used before the exception happened - "tst lr, #4\n" and change the IT block from "itt ne" to "itt eq" and the "mov" and "add" within this IT block. Have tested this with the above changes and it works. I have sent the patch "0001-Fix-exception-handler-for-supporting-FPU.patch" to the devel mailing list that fixes this problem. :) Nice. Have you tested this without FPU support too? Hi Daniel, Just tested the fix with FPU disabled in my processor and it works fine. This patch can be pushed! As I mentioned before, please mention what architecture you tested (what use cases) and which you didn't. Hi Daniel, I have replied to the same question in the thread containing the patch. Daniel .. when you are happy, we can push it. Should this go on the 4.11 branch and master? If so, it needs a ticket. Joel, I think this fix is vital and should be pushed to master. Will make a ticket for this. Thanks and Regards, Sudarshan -- Sudarshan Rajagopalan sudarshan.rajagopalan at vecna.com www.vecna.com Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix exception handler for supporting FPU
On 2015-08-28 12:18, sudarshan.rajagopalan wrote: On 2015-08-28 11:30, Daniel Gutson wrote: On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom wrote: Could you please open a ticket on our trac to describe the problem this fixes, and add "closes #." to your patch commit message? Hi Gedare, Sure will do! Additionally, please clarify which architecture this applies to. I suspect this is for cortex-m4. In any case, please clarify which architectures you tested on. We can analyze and test cortex-m3 if you don't have one. Daniel, I've tested it on Cortex-M4 but this patch should also apply to Cortex-M3 or all ARMv7M based processor (including M7). But please feel free to test it on Cortex-M3 since I don't have it with me now. Am also attaching the links to ARM Cortex-M3, M4 and M7 Exception entry and return referenece documents for a quick reference, where the table gives all the possible exception error codes returned and which SP to pick depending on the error code. The only tricky part would be error code: 0xFFE1. But the asm "tst.w lr, #4" with lr=0xFFE1 will result into zero and will set the Zero flag, which will make the ITT EQ block execute, which will choose MSP, which it should for the return code 0xFFE1 (or even 0xFFF1) in all M3, M4 and M7. But please feel free to test it on real M3 an M7 processor. I have tested it by manually giving all the return error codes for M3 and M7 to LR and and it chooses the right SP value. ARM Reference Docs - Exception Entry and Return: C-3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Babefdjc.html C-4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html C-7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/Babefdjc.html Thanks and Regards, Sudarshan Ok, so we tested the fix on Cortex-M7 processor. The error codes for C-4 and C-7 are all pretty much the same. This leaves with C-3, which I believe should work too, becasue non-FPU error codes are same for C-3, C-4 and C-7. Thanks, Sudarshan Thanks, Gedare On Thu, Aug 27, 2015 at 4:33 PM, sudarshan.rajagopalan wrote: Patch attached here for ARMv7M Exception Handler. Looks like git send-email didn't deliver the mail. Something is not quite right with our mail server here. Avoid this email if patch delivered through git. Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix exception handler for supporting FPU
On 2015-08-28 13:44, Daniel Gutson wrote: On Fri, Aug 28, 2015 at 2:31 PM, sudarshan.rajagopalan wrote: On 2015-08-28 12:18, sudarshan.rajagopalan wrote: On 2015-08-28 11:30, Daniel Gutson wrote: On Fri, Aug 28, 2015 at 12:20 PM, Gedare Bloom wrote: Could you please open a ticket on our trac to describe the problem this fixes, and add "closes #." to your patch commit message? Hi Gedare, Sure will do! Additionally, please clarify which architecture this applies to. I suspect this is for cortex-m4. In any case, please clarify which architectures you tested on. We can analyze and test cortex-m3 if you don't have one. Daniel, I've tested it on Cortex-M4 but this patch should also apply to Cortex-M3 or all ARMv7M based processor (including M7). But please feel free to test it on Cortex-M3 since I don't have it with me now. Am also attaching the links to ARM Cortex-M3, M4 and M7 Exception entry and return referenece documents for a quick reference, where the table gives all the possible exception error codes returned and which SP to pick depending on the error code. The only tricky part would be error code: 0xFFE1. But the asm "tst.w lr, #4" with lr=0xFFE1 will result into zero and will set the Zero flag, which will make the ITT EQ block execute, which will choose MSP, which it should for the return code 0xFFE1 (or even 0xFFF1) in all M3, M4 and M7. But please feel free to test it on real M3 an M7 processor. I have tested it by manually giving all the return error codes for M3 and M7 to LR and and it chooses the right SP value. ARM Reference Docs - Exception Entry and Return: C-3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Babefdjc.html C-4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html C-7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/Babefdjc.html Thanks and Regards, Sudarshan Ok, so we tested the fix on Cortex-M7 processor. The error codes for C-4 and C-7 are all pretty much the same. This leaves with C-3, which I believe should work too, becasue non-FPU error codes are same for C-3, C-4 and C-7. Hi Sudarshan, ok thanks. We will comment on Monday since we have a release today. Good job. Daniel. Sure, Daniel. This requires diving into the ARM architecture a little bit. Will catch up on Monday. Thanks, Sudarshan Thanks, Sudarshan Thanks, Gedare On Thu, Aug 27, 2015 at 4:33 PM, sudarshan.rajagopalan wrote: Patch attached here for ARMv7M Exception Handler. Looks like git send-email didn't deliver the mail. Something is not quite right with our mail server here. Avoid this email if patch delivered through git. Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix exception handler for supporting FPU
On 2015-08-28 17:18, Martin Galvan wrote:
On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
wrote:
The instruction "cmn r2, #3\n" in line 31 basically compares the Link
Register(lr) to value 0xFFFD (negative #3, because CMN negates the
RHS
and compares with LHS) and chooses MSP or PSP in the following IT
block.
This is pretty cool! But, it will not work if you have the
floating-point
unit (FPU) enabled in your processor, which is enabled in mine. With
FPU
enabled, the error code returned is either 0xFFE9 or 0xFFED,
for
which the above assembly instruction will not work out and MSP will be
selected always.
Better way to do is to check the 2nd bit of the error code to
determine
which stack pointer was used before the exception happened - "tst lr,
#4\n"
and change the IT block from "itt ne" to "itt eq" and the "mov" and
"add"
within this IT block.
Hi Sudarshan! First of all, great catch. It looks like there's indeed a
bug
on certain conditions.
While your method is indeed way less convoluted than the clever
"compare to -3"
the old code did, I think we can actually make it even simpler
(and save a couple of instructions) by doing the following:
"tst lr, #4\n" /* Check if bit 2 of LR is zero */
"itte eq\n" /* IF bit 2 of LR is zero... */
"mrseq r0, msp\n" /* THEN we were using MSP */
"addeq r0, %[cpufsz]\n" /* THEN revert the previous 'sub sp,
%[cpufsz]' */
"mrsne r0, psp\n" /* ELSE it's not zero; we were using PSP */
What do you think?
Hi Martin,
Yup, we could definitely save 2 cycles and make it look simpler and
understandable. Thumps up for the comments explaining LR decoding!
Thanks and Regards,
Sudarshan
-
Sudarshan Rajagopalan
sudarshan.rajagopalan at vecna.com
www.vecna.com
Also, I must admit it took me quite a while to understand what was
going on there.
If you don't mind, I'd also like to add a brief comment explaining how
to decode LR
after taking an exception. The patch would end up looking like this:
---
cpukit/score/cpu/arm/armv7m-exception-default.c | 27
+
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c
b/cpukit/score/cpu/arm/armv7m-exception-default.c
index e890cdf..d04dbea 100644
--- a/cpukit/score/cpu/arm/armv7m-exception-default.c
+++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
@@ -22,16 +22,27 @@
void __attribute__((naked)) _ARMV7M_Exception_default( void )
{
+/* On exception entry, ARMv7M saves context state onto a stack
pointed to
+ * by either MSP or PSP. The value stored in LR indicates whether
we were
+ * in Thread or Handler mode, whether we were using the FPU (if
any),
+ * and which stack pointer we were using.
+ * In particular, bit 2 of LR will be 0 if we were using MSP.
+ *
+ * For a more detailed explanation, see the Exception Entry
Behavior
+ * section of the ARMv7M Architecture Reference Manual.
+ */
+
+/* As we're in Handler mode here, we'll always operate on MSP.
+ * However, we need to store the right SP in our
CPU_Exception_frame.
+ */
__asm__ volatile (
-"sub sp, %[cpufsz]\n"
+"sub sp, %[cpufsz]\n" /* Allocate space for a CPU_Exception_frame.
*/
"stm sp, {r0-r12}\n"
-"mov r2, lr\n"
-"mrs r1, msp\n"
-"mrs r0, psp\n"
-"cmn r2, #3\n"
-"itt ne\n"
-"movne r0, r1\n"
-"addne r0, %[cpufsz]\n"
+"tst lr, #4\n" /* Check if bit 2 of LR is zero. (If so, PSR.Z = 1)
*/
+"itte eq\n" /* IF bit 2 of LR is zero... (PSR.Z == 1) */
+"mrseq r0, msp\n" /* THEN we were using MSP. */
+"addeq r0, %[cpufsz]\n" /* THEN, set r0 = old MSP. */
+"mrsne r0, psp\n" /* ELSE it's not zero; we were using PSP. */
"add r2, r0, %[v7mlroff]\n"
"add r1, sp, %[cpulroff]\n"
"ldm r2, {r3-r5}\n"
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3] ARMv7M: Fix exception handler for supporting FPU
On 2015-08-31 13:39, Daniel Gutson wrote:
On Mon, Aug 31, 2015 at 2:34 PM, Gedare Bloom wrote:
I'd approve 2 patches in case you want to give credit. First patch
with Sudarshan's fix, and Martin's improvement second.
+1
Sounds fair enough! :) Thanks for the support, Daniel. Should I make a
separate ticket for committing the initial patch or Martin's ticket
works out well for this?
Thanks and Regards,
Sudarshan
On Mon, Aug 31, 2015 at 1:28 PM, Daniel Gutson
wrote:
Side question to Joel and others: is this enough to credit Sudarshan?
He did an amazing job for finding the bug and proposing an initial
solution.
On Mon, Aug 31, 2015 at 11:37 AM, Martin Galvan
wrote:
On exception entry, _ARMV7M_Exception_default stores the previous
Stack Pointer
in a CPU_Exception_frame. The SP can be MSP or PSP, depending on the
mode
in which the exception was taken. To know this, we must check the
value of LR.
Right now the code checks whether it should store MSP or PSP by
comparing LR to
-3. However, this doesn't work if we're using an FPU. This patch
fixes that
by checking bit 2 of LR, which indicates which SP we were using.
Thanks to Sudarshan Rajagopalan for finding the bug and proposing a
first
version of the fix.
Closes #2401.
---
cpukit/score/cpu/arm/armv7m-exception-default.c | 27
+
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c
b/cpukit/score/cpu/arm/armv7m-exception-default.c
index e890cdf..d04dbea 100644
--- a/cpukit/score/cpu/arm/armv7m-exception-default.c
+++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
@@ -22,16 +22,27 @@
void __attribute__((naked)) _ARMV7M_Exception_default( void )
{
+/* On exception entry, ARMv7M saves context state onto a stack
pointed to
+ * by either MSP or PSP. The value stored in LR indicates
whether we were
+ * in Thread or Handler mode, whether we were using the FPU (if
any),
+ * and which stack pointer we were using.
+ * In particular, bit 2 of LR will be 0 if we were using MSP.
+ *
+ * For a more detailed explanation, see the Exception Entry
Behavior
+ * section of the ARMv7M Architecture Reference Manual.
+ */
+
+/* As we're in Handler mode here, we'll always operate on MSP.
+ * However, we need to store the right SP in our
CPU_Exception_frame.
+ */
__asm__ volatile (
-"sub sp, %[cpufsz]\n"
+"sub sp, %[cpufsz]\n" /* Allocate space for a
CPU_Exception_frame. */
"stm sp, {r0-r12}\n"
-"mov r2, lr\n"
-"mrs r1, msp\n"
-"mrs r0, psp\n"
-"cmn r2, #3\n"
-"itt ne\n"
-"movne r0, r1\n"
-"addne r0, %[cpufsz]\n"
+"tst lr, #4\n" /* Check if bit 2 of LR is zero. (If so,
PSR.Z = 1) */
+"itte eq\n" /* IF bit 2 of LR is zero... (PSR.Z == 1)
*/
+"mrseq r0, msp\n"/* THEN we were using MSP. */
+"addeq r0, %[cpufsz]\n" /* THEN, set r0 = old MSP. */
+"mrsne r0, psp\n"/* ELSE it's not zero; we were using PSP.
*/
"add r2, r0, %[v7mlroff]\n"
"add r1, sp, %[cpulroff]\n"
"ldm r2, {r3-r5}\n"
--
1.9.1
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Adding RTEMS shell commands in BSP and application
Hey guys,
I was working on adding user shell commands in RTEMS. Was able to
successfully do it. Right now, we want to add few BSP specific shell
commands and few application specific shell commands. The BSP shell
commands will be added to the BSP, compiled and built. And also give the
flexibility to user application to add application specific commands
later on. One way to do it:
int bsp1(int argc, char **argv){
}
int bsp2(int argc, char **argv){
}
rtems_shell_cmd_t BSP1_Command = {
"test1", /* name */
"test1", /* usage */
"user", /* topic */
bsp1, /* command */
NULL, /* alias */
NULL /* next */
};
rtems_shell_cmd_t BSP2_Command = {
"test2", /* name */
"test2", /* usage */
"user", /* topic */
bsp2, /* command */
NULL, /* alias */
NULL /* next */
};
#define SHELL_USER_COMMANDS \
&BSP2_Command, \
&BSP1_Command
and the same in application code for APP1_Command and APP2_Command. And
initialize the shell in the application code:
#define CONFIGURE_SHELL_USER_COMMANDS \
SHELL_USER_COMMANDS, \
&APP1_Command, \
&APP2_Command
#define CONFIGURE_SHELL_COMMANDS_INIT
...
#include
Would this be the right way or are there any better ways to do it?
Please let me know I didn't make myself clear on this.
Thanks and Regards,
Sudarshan Rajagopalan
sudarshan.rajagopa...@vecna.com
Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
http://vecna.com [1]
Better Technology, Better World (TM)
Links:
--
[1] http://vecna.com
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Adding RTEMS shell commands in BSP and application
On 2015-09-18 00:10, Chris Johns wrote:
On 18/09/2015 11:01 am, Ian Caddy wrote:
We use 4.10 and add our application shell commands programmatically.
For
example:
rtems_shell_add_cmd("findnb", "nameblock", "findnb# list
nameblocks", main_findnb);
I do the same thing on 4.11.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Sweet. Works fine. Thanks!
Thanks and Regards,
Sudarshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Math lib inclusion in BSP
Hey all, We are developing a new BSP that uses math.h in few of the BSP files. I do understand that the math library functions are not part of standard C library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in the custom .cgf config file but this doesn't seem to work. I think this has to be linked in a proper order. Could someone help with this? Heres the custom config file: include $(RTEMS_ROOT)/make/custom/default.cfg RTEMS_CPU = arm LD_LIBS += -lm CPU_CFLAGS = -march=armv7-m -mthumb CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16 Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Math lib inclusion in BSP
On 2015-09-25 11:06, Daniel Gutson wrote: On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan wrote: Hey all, We are developing a new BSP that uses math.h in few of the BSP files. I do May I ask why do you need floating point operations in a kernel? At least, what sort of operations and why not move them upwards. We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). understand that the math library functions are not part of standard C library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in the custom .cgf config file but this doesn't seem to work. I think this has to be linked in a proper order. Could someone help with this? Heres the custom config file: include $(RTEMS_ROOT)/make/custom/default.cfg RTEMS_CPU = arm LD_LIBS += -lm CPU_CFLAGS = -march=armv7-m -mthumb CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16 Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Math lib inclusion in BSP
On 2015-09-25 01:33, Sebastian Huber wrote: On 24/09/15 21:49, sudarshan.rajagopalan wrote: We are developing a new BSP that uses math.h in few of the BSP files. I do understand that the math library functions are not part of standard C library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in the custom .cgf config file but this doesn't seem to work. I think this has to be linked in a proper order. Could someone help with this? This seems to be a candidate for a FAQ: https://lists.rtems.org/pipermail/devel/2014-October/008322.html This patch would solve the problem: https://lists.rtems.org/pipermail/devel/2014-September/008191.html Is the above patch committed to the master? I applied the above patch to the "bsp_specs" file specific to the BSP processor and it worked, but couldn't find the gcc/config/rtems.h file mentioned. Is the file moved or changed? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Math lib inclusion in BSP
On 2015-09-25 12:21, Daniel Gutson wrote: El 25/9/2015 13:17, "sudarshan.rajagopalan" escribió: > > On 2015-09-25 11:06, Daniel Gutson wrote: >> >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan >> wrote: >>> >>> Hey all, >>> >>> We are developing a new BSP that uses math.h in few of the BSP files. I do >> >> >> May I ask why do you need floating point operations in a kernel? At >> least, what sort of operations and why not move them upwards. > > > We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). How will you handle fp exceptions? Did you consider using fixed point? We haven't implemented any error handling yet. We will do so in our next phase. And I think we decided to use floating-point due to the available FPU hardware support in the processor( ARM Cortex-M4 and M7) to make these operations faster. Are there any concerns that we should be aware of while using floating-point operations in the BSP? > > >> >>> understand that the math library functions are not part of standard C >>> library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in >>> the custom .cgf config file but this doesn't seem to work. I think this has >>> to be linked in a proper order. Could someone help with this? >>> >>> Heres the custom config file: >>> >>> include $(RTEMS_ROOT)/make/custom/default.cfg >>> >>> RTEMS_CPU = arm >>> >>> LD_LIBS += -lm >>> >>> CPU_CFLAGS = -march=armv7-m -mthumb >>> >>> CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16 >>> >>> Thanks and Regards, >>> Sudarshan >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel [1] > > Links: -- [1] http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Math lib inclusion in BSP not required if CAN drivers are considered
+1. - Sudarshan On 2015-10-01 11:06, Isaac Gutekunst wrote: Hi Pavel, Thanks for the detailed reply. I guess you aren't as "horribly out of time" as you said, or perhaps are no even more out of time :) We will definitely take a good look at the LinCAN source for baud rate calculations. The more I think about it, the more I think it's worth to port LinCAN to RTEMS, even though it wouldn't be the most trivial. Then we wouldn't have yet another CAN implementation that is subtly different than LinCAN. Here is the file in question: https://github.com/vecnatechnologies/rtems/blob/stm32-bsp-rebase-fixes/c/src/lib/libbsp/arm/shared/stm32f/can/hal-can.c Since I wrote it, I think it makes a lot of sense. However, I'll take a look at the LinCAN code some more and see if I can understand it. Again, thanks for the email. Isaac On 09/30/2015 06:08 PM, Pavel Pisa wrote: Hello Sudarshan, On Friday 25 of September 2015 19:13:53 sudarshan.rajagopalan wrote: On 2015-09-25 12:21, Daniel Gutson wrote: El 25/9/2015 13:17, "sudarshan.rajagopalan" escribió: > On 2015-09-25 11:06, Daniel Gutson wrote: >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan >> >> wrote: >>> Hey all, >>> >>> We are developing a new BSP that uses math.h in few of the BSP files. I do >> May I ask why do you need floating point operations in a kernel? At >> least, what sort of operations and why not move them upwards. > > We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). If this is part of CAN driver baudrate calculation then floating point is usually not required and can be sometimes harmfull because you need to find best matching ratio of integer numbers which are send to controller registers. See Linux SocketCAN implementation https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/dev.c?id=refs/tags/v4.3-rc3#n74 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/can/netlink.h?id=refs/tags/v4.3-rc3#n46 I have proposed it with structures defining CAN controller parameters many years ago and it seems that it has been enough for all controllers supported by Linux drivers. I suggest to not reinvent the wheel and use solution compatible with this one because you can use values already tested in the Linux kernel. As for the License, actual Linux code has been updated and enhanced by more people and is strict GPLv2 only. The main change is movement of sample point computation to the separate function can_update_spt() and change of sample point specification from 1/100 (%) to 1/1000 fractions. You can find simpler version in LinCAN driver code http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/lpc17xx_can.c#l90 http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/can/can_bittiming.h where LinCAN is released under license crated specially to be compatible with RTEMS as well. Generally, Volkswagen SocketCAN is intended to be available under BSD license in these parts where it does not directly interact with Linux kernel structures so I expect that there is no problem when some of Linux specific enhancements for bitrate calculation are reintroduced in our code. I check that directly with Linux CAN maintainers (Oliver Hartkopp, etc.). I have even userspace test code for these computations and some examples. I am horribly out of time this and next week but I can clean a dust from my memory and prepared files after this time and send the utility sources. But please, if you intend to have generic RTEMS CAN infrastructure, do not introduce floating point computation to CAN drivers and try to check if computations introduced by us initially for embedded system less applications and then selected by Linux kernel community can be used in RTEMS. It would really simplify new drivers and CAN HW introduction because you can use already elaborated values instead to reading complex chip manuals. Unfortuantelly, I cannot allocate time to RTEMS CAN as I would like. We have no project at university or company which would backup the work and there are still even higher priority "hobby" projects investments on my list - i.e. move forward (with my student) TMS570 BSP networking, QEMU CAN support and some motion control experimental stuff on RPi, Linux and our conceptually new solution for motor control current sensing, FPGA D-Q vector control and its combination with predictive control algorithms. Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___
[PATCH] Fixes GPIO APIs Naming Convention and Comments
Just found few function names to be inconsistent towards the naming
convention, and also few API documentation in the RTEMS GPIO files.
Please commit this if required.
Thanks and Regards,
Sudarshan Rajagopalan
From e17ce266ba4cfaec0159c5477697847629946ced Mon Sep 17 00:00:00 2001
From: Sudarshan Rajagopalan
Date: Mon, 12 Oct 2015 12:47:35 -0400
Subject: [PATCH] Fixes GPIO APIs Naming Convention and Comments
---
c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 8
c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c | 4 ++--
c/src/lib/libbsp/shared/gpio.c | 6 +++---
c/src/lib/libbsp/shared/include/gpio.h | 20
4 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
index 8cf690f..9737dec 100644
--- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
+++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
@@ -299,7 +299,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -354,7 +354,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -528,7 +528,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return -1;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -536,7 +536,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_NOT_DEFINED;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
index a782d11..4fb2c93 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
@@ -183,7 +183,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -227,7 +227,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/shared/gpio.c
b/c/src/lib/libbsp/shared/gpio.c
index 80e2727..b806556 100644
--- a/c/src/lib/libbsp/shared/gpio.c
+++ b/c/src/lib/libbsp/shared/gpio.c
@@ -1341,7 +1341,7 @@ rtems_status_code rtems_gpio_request_pin(
return RTEMS_UNSATISFIED;
}
- sc = rtems_bsp_select_specific_io(
+ sc = rtems_gpio_bsp_select_specific_io(
bank,
pin,
bsp_data->io_function,
@@ -1805,7 +1805,7 @@ rtems_status_code rtems_gpio_enable_interrupt(
}
}
- sc = rtems_bsp_enable_interrupt(bank, pin, interrupt);
+ sc = rtems_gpio_bsp_enable_interrupt(bank, pin, interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
@@ -1919,7 +1919,7 @@ rtems_status_code
rtems_gpio_disable_interrupt(uint32_t pin_number)
return RTEMS_NOT_CONFIGURED;
}
- sc = rtems_bsp_disable_interrupt(bank, pin,
interrupt_state->active_interrupt);
+ sc = rtems_gpio_bsp_disable_interrupt(bank, pin,
interrupt_state->active_interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
diff --git a/c/src/lib/libbsp/shared/include/gpio.h
b/c/src/lib/libbsp/shared/include/gpio.h
index 54de5f1..7d8f67b 100644
--- a/c/src/lib/libbsp/shared/include/gpio.h
+++ b/c/src/lib/libbsp/shared/include/gpio.h
@@ -736,12 +736,16 @@ extern uint32_t rtems_gpio_bsp_multi_read(uint32_t
bank, uint32_t bitmask);
*does not support the feature, by returning RTEMS_NOT_DEFINED.
*
* @param[in] bank GPIO bank number.
- * @param[in] bitmask Bitmask of GPIO pins to clear in the given bank.
+ * @param[in] pins Array filled with BSP specific pin numbers. All pins
belong
+ * to the same select bank.
+ * @param[in] pin_count Number of pin configurations in the @var pins
array.
+ * @param[in] arg Pointer to a BSP defined structure with BSP-specific
+ *data. This field is handled by the BSP.
*
- * @retval RTEMS_SUCCESSFUL All pins were cleared successfully.
- * @retval RTEMS_NOT_DEFINED The BSP does not support BSP specific
operatio
Re: [PATCH] Fixes GPIO APIs Naming Convention and Comments
Sure, André. Me too released when I started working on the GPIO driver.
Although, great work with the generic GPIO API implementation for RTEMS.
:) Really like the way it uses chained linked list to call the user ISR
when a gpio bank(or port) interrupt is generated.
I do have few other questions/queries to ask about the RTEMS GPIO API
implementations. Will make a new post for this.
Thanks and Regards,
Sudarshan
On 2015-10-12 16:07, André Marques wrote:
Hello Sudarshan,
Às 18:37 de 12-10-2015, sudarshan.rajagopalan escreveu:
Just found few function names to be inconsistent towards the naming
convention, and also few API documentation in the RTEMS GPIO files.
Please commit this if required.
Thanks for the patch! I noticed that some functions were missing the
_gpio_ before but forgot about it completely.
I will also update my GSOC documentation wiki page and test cases
when someone commits this.
On another note (speaking to the community) maybe my GPIO
documentation could be moved (and improved in the way) to the user
manual?
Thanks and Regards,
Sudarshan Rajagopalan
From e17ce266ba4cfaec0159c5477697847629946ced Mon Sep 17 00:00:00
2001
From: Sudarshan Rajagopalan
Date: Mon, 12 Oct 2015 12:47:35 -0400
Subject: [PATCH] Fixes GPIO APIs Naming Convention and Comments
---
c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 8
c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c | 4 ++--
c/src/lib/libbsp/shared/gpio.c | 6 +++---
c/src/lib/libbsp/shared/include/gpio.h | 20
4 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
index 8cf690f..9737dec 100644
--- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
+++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
@@ -299,7 +299,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -354,7 +354,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -528,7 +528,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return -1;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -536,7 +536,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_NOT_DEFINED;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
index a782d11..4fb2c93 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
@@ -183,7 +183,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -227,7 +227,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/shared/gpio.c
b/c/src/lib/libbsp/shared/gpio.c
index 80e2727..b806556 100644
--- a/c/src/lib/libbsp/shared/gpio.c
+++ b/c/src/lib/libbsp/shared/gpio.c
@@ -1341,7 +1341,7 @@ rtems_status_code rtems_gpio_request_pin(
return RTEMS_UNSATISFIED;
}
- sc = rtems_bsp_select_specific_io(
+ sc = rtems_gpio_bsp_select_specific_io(
bank,
pin,
bsp_data->io_function,
@@ -1805,7 +1805,7 @@ rtems_status_code
rtems_gpio_enable_interrupt(
}
}
- sc = rtems_bsp_enable_interrupt(bank, pin, interrupt);
+ sc = rtems_gpio_bsp_enable_interrupt(bank, pin, interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
@@ -1919,7 +1919,7 @@ rtems_status_code
rtems_gpio_disable_interrupt(uint32_t pin_number)
return RTEMS_NOT_CONFIGURED;
}
- sc = rtems_bsp_disable_interrupt(bank, pin,
interrupt_state->active_interrupt);
+ sc = rtems_gpio_bsp_disable_interrupt(bank, pin,
interrupt_state->active_interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
diff --git a/c/src/lib/libbsp/shared/include/gpio.h
b/c/src/lib/libbsp/shared/include/gpio.h
index 54de5f1..7d8f67b 100644
--- a/c/src/lib/libbsp/shared/include/gpio.h
+++ b/c/src/lib/libbsp/shared/include/gpio.h
@@ -736,12 +736,16 @@ extern uint32_t
rtems_gpio_bsp_multi_read(uint32_t bank, uint32_t bitmask);
* does not su
Re: [PATCH] Fixes GPIO APIs Naming Convention and Comments
On 2015-10-14 16:28, Gedare Bloom wrote:
OK to commit, but the patch did not apply cleanly for me, something
wrong with the mail message.
Hi Gedare,
The mail message was not sent using git send-email (this is not working
for us currently), so I copied the contents of the patch to this mail
message. Could you try using the patch attached in my first mail?
Also, does this require a ticket?
Thanks and Regards,
Sudarshan
On Tue, Oct 13, 2015 at 3:11 AM, Ben Gras
wrote:
All,
This change renames these gpio-specific functions:
rtems_bsp_enable_interrupt
rtems_bsp_disable_interrupt
rtems_bsp_select_specific_io
to
rtems_gpio_bsp_enable_interrupt
rtems_gpio_bsp_disable_interrupt
rtems_gpio_bsp_select_specific_io
+1, Definitely an improvement.
On Mon, Oct 12, 2015 at 7:37 PM, sudarshan.rajagopalan
wrote:
Just found few function names to be inconsistent towards the naming
convention, and also few API documentation in the RTEMS GPIO files.
Please
commit this if required.
Thanks and Regards,
Sudarshan Rajagopalan
From e17ce266ba4cfaec0159c5477697847629946ced Mon Sep 17 00:00:00
2001
From: Sudarshan Rajagopalan
Date: Mon, 12 Oct 2015 12:47:35 -0400
Subject: [PATCH] Fixes GPIO APIs Naming Convention and Comments
---
c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 8
c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c | 4 ++--
c/src/lib/libbsp/shared/gpio.c | 6 +++---
c/src/lib/libbsp/shared/include/gpio.h | 20
4 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
index 8cf690f..9737dec 100644
--- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
+++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
@@ -299,7 +299,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -354,7 +354,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -528,7 +528,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return -1;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -536,7 +536,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_NOT_DEFINED;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
index a782d11..4fb2c93 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
@@ -183,7 +183,7 @@ uint32_t
rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -227,7 +227,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/shared/gpio.c
b/c/src/lib/libbsp/shared/gpio.c
index 80e2727..b806556 100644
--- a/c/src/lib/libbsp/shared/gpio.c
+++ b/c/src/lib/libbsp/shared/gpio.c
@@ -1341,7 +1341,7 @@ rtems_status_code rtems_gpio_request_pin(
return RTEMS_UNSATISFIED;
}
- sc = rtems_bsp_select_specific_io(
+ sc = rtems_gpio_bsp_select_specific_io(
bank,
pin,
bsp_data->io_function,
@@ -1805,7 +1805,7 @@ rtems_status_code rtems_gpio_enable_interrupt(
}
}
- sc = rtems_bsp_enable_interrupt(bank, pin, interrupt);
+ sc = rtems_gpio_bsp_enable_interrupt(bank, pin, interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
@@ -1919,7 +1919,7 @@ rtems_status_code
rtems_gpio_disable_interrupt(uint32_t pin_number)
return RTEMS_NOT_CONFIGURED;
}
- sc = rtems_bsp_disable_interrupt(bank, pin,
interrupt_state->active_interrupt);
+ sc = rtems_gpio_bsp_disable_interrupt(bank, pin,
interrupt_state->active_interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
diff --git a/c/src/lib/libbsp/shared/include/gpio.h
b/c/src/lib/libbsp/shared/include/gpio.h
index 54de5f1..7d8f67b 100644
--- a/c/src/lib/libbsp/shared/inclu
[PATCH v2] Fixes GPIO APIs Naming Convention and Comments
This patch renames the GPIO specific functions:
from
rtems_bsp_enable_interrupt
rtems_bsp_disable_interrupt
rtems_bsp_select_specific_io
to
rtems_gpio_bsp_enable_interrupt
rtems_gpio_bsp_disable_interrupt
rtems_gpio_bsp_select_specific_io
And also minor changes to the function description in the gpio.h header
file.
Patch attached in this mail. Fixes #2429.
Thanks and Regards,
Sudarshan RajagopalanFrom e17ce266ba4cfaec0159c5477697847629946ced Mon Sep 17 00:00:00 2001
From: Sudarshan Rajagopalan
Date: Mon, 12 Oct 2015 12:47:35 -0400
Subject: [PATCH] Fixes GPIO APIs Naming Convention and Comments
---
c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 8
c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c | 4 ++--
c/src/lib/libbsp/shared/gpio.c | 6 +++---
c/src/lib/libbsp/shared/include/gpio.h | 20
4 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
index 8cf690f..9737dec 100644
--- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
+++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
@@ -299,7 +299,7 @@ uint32_t rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -354,7 +354,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -528,7 +528,7 @@ uint32_t rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return -1;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -536,7 +536,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_NOT_DEFINED;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
index a782d11..4fb2c93 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
@@ -183,7 +183,7 @@ uint32_t rtems_gpio_bsp_interrupt_line(rtems_vector_number vector)
return event_status;
}
-rtems_status_code rtems_bsp_enable_interrupt(
+rtems_status_code rtems_gpio_bsp_enable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
@@ -227,7 +227,7 @@ rtems_status_code rtems_bsp_enable_interrupt(
return RTEMS_SUCCESSFUL;
}
-rtems_status_code rtems_bsp_disable_interrupt(
+rtems_status_code rtems_gpio_bsp_disable_interrupt(
uint32_t bank,
uint32_t pin,
rtems_gpio_interrupt interrupt
diff --git a/c/src/lib/libbsp/shared/gpio.c b/c/src/lib/libbsp/shared/gpio.c
index 80e2727..b806556 100644
--- a/c/src/lib/libbsp/shared/gpio.c
+++ b/c/src/lib/libbsp/shared/gpio.c
@@ -1341,7 +1341,7 @@ rtems_status_code rtems_gpio_request_pin(
return RTEMS_UNSATISFIED;
}
- sc = rtems_bsp_select_specific_io(
+ sc = rtems_gpio_bsp_select_specific_io(
bank,
pin,
bsp_data->io_function,
@@ -1805,7 +1805,7 @@ rtems_status_code rtems_gpio_enable_interrupt(
}
}
- sc = rtems_bsp_enable_interrupt(bank, pin, interrupt);
+ sc = rtems_gpio_bsp_enable_interrupt(bank, pin, interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
@@ -1919,7 +1919,7 @@ rtems_status_code rtems_gpio_disable_interrupt(uint32_t pin_number)
return RTEMS_NOT_CONFIGURED;
}
- sc = rtems_bsp_disable_interrupt(bank, pin, interrupt_state->active_interrupt);
+ sc = rtems_gpio_bsp_disable_interrupt(bank, pin, interrupt_state->active_interrupt);
if ( sc != RTEMS_SUCCESSFUL ) {
RELEASE_LOCK(gpio_bank_state[bank].lock);
diff --git a/c/src/lib/libbsp/shared/include/gpio.h b/c/src/lib/libbsp/shared/include/gpio.h
index 54de5f1..7d8f67b 100644
--- a/c/src/lib/libbsp/shared/include/gpio.h
+++ b/c/src/lib/libbsp/shared/include/gpio.h
@@ -736,12 +736,16 @@ extern uint32_t rtems_gpio_bsp_multi_read(uint32_t bank, uint32_t bitmask);
*does not support the feature, by returning RTEMS_NOT_DEFINED.
*
* @param[in] bank GPIO bank number.
- * @param[in] bitmask Bitmask of GPIO pins to clear in the given bank.
+ * @param[in] pins Array filled with BSP specific pin numbers. All pins belong
+ * to the same select bank.
+ * @param[in] pin_count Number of pin configurations in the @var pins array.
+ * @param[in] arg Pointer to a BSP defined structure with BSP-specific
+ *data. Thi
GPIO Pin Release and Pin Specific Interrupts
Hey guys, I have few questions/comments on the GPIO APIs, maybe to André: 1.) Most of the APIs has a way to call the BSP specific functions: pin input/output initialize, pin read/write, enable/disable interrupts etc, but I couldn't find a way to call a BSP specific pin release (or de-init). The rtems_gpio_release_pin() disables the interrupt for that pin and updates the pin state global variable, but does not allows to do a bsp specific pin de-initialize. While if I want to change the mode of the pin (say from input to output), I can reinitialize the pin and it works. But its important to bring back the state of the pin to its default reset state, deactivating the pull resistors, if the pin is to be released and not used. Was wondering why this wasn't added. What are your comments on this? If this is OK I have a patch for this. 2.) Second, the interrupts are registered based on ports (which it is in most of the processors) and the pin that caused the interrupt is found as a node in the chained list. But, unfortunately the processor that we are using (STM32F4/F7) has pin based interrupts :(. The link below tells in brief: http://stm32f4-discovery.com/2014/08/stm32f4-external-interrupts-tutorial/ There are interrupt vectors defined for each pin in STM32F4/F7 but RTEMS GPIO expects vector numbers for gpio banks using rtems_gpio_bsp_get_vector(), which would not work for this processor. I'm been trying to break my head to figure out a way to make the interrupts work, without any modification to the GPIO APIs. One way would be to send the enumerated pin_number as the argument to rtems_gpio_bsp_get_vector(), decode pin number ( pin = PIN_NUMBER(pin_number) ) and return the vector number for this pin and install the interrupt handler. But based on the whole interrupt service architecture in generic_bank_isr(), this would not work out. Everything is based on bank interrupts. Any possible solution for this? Thanks and Regards, Sudarshan Rajagopalan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BBB GPIO api interrupt handler problem
On 2015-11-09 13:11, Federico Garcia Cruz wrote:
Hi everyone,
I'm using the GPIO api for the BBB but I'm having problems with the
interrupt handling.
I'm blinking two leds in the main thread and I have a GPIO input with
an interrupt attached that uses printk to print a message. The problem
is that the interrupt handler prints the message but never returns
(main thread leds stop blinking after that).
Any suggestion?
Here's my code:
rtems_gpio_irq_state gpio_handler(void* /*arg*/)
{
printk("interrupt handler\n");
return IRQ_HANDLED;
}
A return statement inside an interrupt handler?? Where does it return
back to?
- Sudarshan
void* POSIX_Init(void*)
{
rtems_mode previous_mode_set;
rtems_task_mode(RTEMS_TIMESLICE | RTEMS_PREEMPT,
RTEMS_TIMESLICE_MASK | RTEMS_PREEMPT_MASK, &previous_mode_set);
rtems_status_code sc = rtems_gpio_initialize();
printk("%d\n", sc);
sc = rtems_gpio_request_pin(BBB_LED_USR0, DIGITAL_OUTPUT, true,
false, NULL);
printk("DIGITAL_OUTPUT: %d\n", sc);
sc = rtems_gpio_request_pin(BBB_LED_USR3, DIGITAL_OUTPUT, true,
false, NULL);
printk("DIGITAL_OUTPUT: %d\n", sc);
sc = rtems_gpio_request_pin(BBB_P8_7, DIGITAL_INPUT, false, false,
NULL);
printk("DIGITAL_INPUT: %d\n", sc);
sc = rtems_gpio_enable_interrupt(BBB_P8_7, FALLING_EDGE,
UNIQUE_HANDLER, false, gpio_handler, NULL);
printk("interrupt install: %d\n", sc);
while(1)
{
sleep(1);
rtems_gpio_clear(BBB_LED_USR3);
rtems_gpio_set(BBB_LED_USR0);
sleep(1);
rtems_gpio_set(BBB_LED_USR3);
rtems_gpio_clear(BBB_LED_USR0);
}
return NULL;
}
Thanks in advance!--
[1]
Federico Garcia Cruz
Software Engineer
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
[2] [3]
Links:
--
[1] http://www.tallertechnologies.com
[2] http://www.linkedin.com/company/taller-technologies
[3] https://www.facebook.com/tallertechnologies
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
