Date   

Re: OS abstraction

Jon Mason <jon.mason@...>
 

Stated alternatively, Would it be acceptable usptream to have a
HAL-like layer that would abstract the OS dependent calls in a driver
(thus allowing for the drivers to be used in other RTOSes)?

Thanks,
Jon

On Sun, Jun 4, 2017 at 11:52 PM, Prasad Hegde Nagapati via
Zephyr-devel <zephyr-devel@lists.zephyrproject.org> wrote:
Guys,



I would like to know, how easily I can port any other OS(If we have any
other proprietary OS) into this architecture.



Best Regards

Prasad


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: [devel] STM32F7 Port

Lucas Tanure <tanure@...>
 

Would you like my review on this ? I can test on my board.

Thanks

On Mon, Jun 5, 2017 at 2:30 AM, Fabien Parent <fparent@baylibre.com> wrote:
Hi Lucas,

There is a pull request that adds support for STM32F7 + STM32F723E
Discovery board: https://github.com/zephyrproject-rtos/zephyr/pull/187
. I plan to finish upstreaming it in a week when I will be back from
vacation. This should easier your work for the STM32F746G-DISCO.

Fabien

On Sat, Jun 3, 2017 at 4:07 AM, Lucas Tanure <tanure@linux.com> wrote:
Hi,

I would like to develop the port for stm32f7, in order to use zephyr
in my STM32F746G-DISCO.
I saw some code related to stm32f7 under "ex" folder, and one thread
in november of 2016 : "Porting to ARM Cortex-M7 / Atmel SAM E70
support"

How is the status for that ?

I was thinking write the source for the CPU first, like copy
arch/arm/soc/st_stm32/stm32f4 to arch/arm/soc/st_stm32/stm32f7
and modify it acording to :
RM0385 Reference manual STM32F75xxx and STM32F74xxx advanced ARM ®
-based 32-bit MCUs

Can I work on it ? Or already there is someone working on that ?

Thanks

--
Lucas Tanure
Embedded Developer
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
--
Lucas Tanure
Embedded Developer
+55 19 988176559


OS abstraction

Prasad Hegde
 

Guys,

 

I would like to know, how easily I can port any other OS(If we have any other proprietary OS) into this architecture.

 

Best Regards

Prasad


Re: [devel] STM32F7 Port

Fabien Parent <fparent@...>
 

Hi Lucas,

There is a pull request that adds support for STM32F7 + STM32F723E
Discovery board: https://github.com/zephyrproject-rtos/zephyr/pull/187
. I plan to finish upstreaming it in a week when I will be back from
vacation. This should easier your work for the STM32F746G-DISCO.

Fabien

On Sat, Jun 3, 2017 at 4:07 AM, Lucas Tanure <tanure@linux.com> wrote:
Hi,

I would like to develop the port for stm32f7, in order to use zephyr
in my STM32F746G-DISCO.
I saw some code related to stm32f7 under "ex" folder, and one thread
in november of 2016 : "Porting to ARM Cortex-M7 / Atmel SAM E70
support"

How is the status for that ?

I was thinking write the source for the CPU first, like copy
arch/arm/soc/st_stm32/stm32f4 to arch/arm/soc/st_stm32/stm32f7
and modify it acording to :
RM0385 Reference manual STM32F75xxx and STM32F74xxx advanced ARM ®
-based 32-bit MCUs

Can I work on it ? Or already there is someone working on that ?

Thanks

--
Lucas Tanure
Embedded Developer
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


RFC on STM32 Ethernet driver

Erwin Rol
 

Hello,

I made an initial STM32F4 Ethernet driver. It is based on the HAL
version, and doesn't try to be smart with DMA and packet buffer memory,
it just does memcpy to/from the DMA buffers. But it works.

It can be found at github;

https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54
Since it is for the olimex_stm32_e407 board (which is still pending to
be merged) I didn't want to create a pull request yet.

The driver use the STM32 HAL (or at least parts of it), and as I
mentioned "it works" but I am very uncertain about if I like the HAL
thing or not.

For example the ISR uses this __weak callbacks, but you will not have
access to your device structure anymore, and it is very unclear what is
happening. So I pretty much copied the whole ISR to only have the
possibility to access my network device structure passed to the ISR.

With the use of macros like "ETH" naming collisions are bound to happen
sooner or later.

The CamelCase naming convention of the HAL just gives me a headache, but
that's a matter of taste I guess.

I know I am opening a can of worms, but I really could use some guidance
on if using the HAL for more complex drivers like Ethernet is the way to
go or if just making a clean implementation is better.

- Erwin


[devel] STM32F7 Port

Lucas Tanure <tanure@...>
 

Hi,

I would like to develop the port for stm32f7, in order to use zephyr
in my STM32F746G-DISCO.
I saw some code related to stm32f7 under "ex" folder, and one thread
in november of 2016 : "Porting to ARM Cortex-M7 / Atmel SAM E70
support"

How is the status for that ?

I was thinking write the source for the CPU first, like copy
arch/arm/soc/st_stm32/stm32f4 to arch/arm/soc/st_stm32/stm32f7
and modify it acording to :
RM0385 Reference manual STM32F75xxx and STM32F74xxx advanced ARM ®
-based 32-bit MCUs

Can I work on it ? Or already there is someone working on that ?

Thanks

--
Lucas Tanure
Embedded Developer


Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Andy Gross
 

+1


On 2 June 2017 at 04:02, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:
Hi Neil,

+1 for me too. This would really be handy in long range.

Obviously, one point to solve is how to deal with pinmuxing. I see at least
3 options:
a) Keep board independant pinmuxing, and up to each board to present
pinmuxing(s)
compatible with required shield(s)
b) Define generic pinmuxing profiles(arduino_pinmux for instance). Then
boards and
shields would include these profiles (when compatible)
c) Shield activation (with EXTBOARD=..) would configure board pinmux on the
fly
d) Use DTS overlays. If this requires multiple overlays, we can
extend that to provide the feature.


In any case, boards should provide a "compatible" field at some point to
document
the supported shields (or pinmux profiles).


Erwan

On 1 June 2017 at 22:41, Nashif, Anas <anas.nashif@intel.com> wrote:

Hi Neil,
I think this is a great idea to support another layer for shields and
extensions on top of existing boards. This will also allow usage for custom
test shields that can specified for testcases, i.e. to test IOs and
peripherals. Not sure about the naming and structure yet and if it should
go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil
Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the
Arduino or ST Morpho connectors for example, but there is no simple way to
explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and
config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with
Arduino Uno R3 connector, but a cfg for each supported board should be
supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like
SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Erwan Gouriou
 

Hi Neil,

+1 for me too. This would really be handy in long range.

Obviously, one point to solve is how to deal with pinmuxing. I see at least 3 options:
a) Keep board independant pinmuxing, and up to each board to present pinmuxing(s)
compatible with required shield(s)
b) Define generic pinmuxing profiles(arduino_pinmux for instance). Then boards and
shields would include these profiles (when compatible)
c) Shield activation (with EXTBOARD=..) would configure board pinmux on the fly

In any case, boards should provide a "compatible" field at some point to document
the supported shields (or pinmux profiles).


Erwan

On 1 June 2017 at 22:41, Nashif, Anas <anas.nashif@...> wrote:
Hi Neil,
I think this is a great idea to support another layer for shields and extensions on top of existing boards. This will also allow usage for custom test shields that can specified for testcases, i.e. to test IOs and peripherals.  Not sure about the naming and structure yet and if it should go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example, but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector, but a cfg for each supported board should be supplied :

boards/
      ext/
         x-nucleo-iks01a1/
                          Kconfig.ext
                          Kconfig.defconfig
                          ext.h
                          Makefile
                          x_nucleo_iks01a1.nucleo_f103rb_defconfig
                          x_nucleo_iks01a1.nucleo_f334r8_defconfig
                          x_nucleo_iks01a1.nucleo_f401re_defconfig
                          x_nucleo_iks01a1.nucleo_l476rg_defconfig
                          doc/
                              x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Nashif, Anas
 

Hi Neil,
I think this is a great idea to support another layer for shields and extensions on top of existing boards. This will also allow usage for custom test shields that can specified for testcases, i.e. to test IOs and peripherals. Not sure about the naming and structure yet and if it should go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example, but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector, but a cfg for each supported board should be supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


[RFC] Mezzanine/Hat/Extension/Shield board support

Neil Armstrong
 

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example,
but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector,
but a cfg for each supported board should be supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux
www.baylibre.com


Zephyr 1.9 M0 milestone is quickly approaching; Need to wrap up 1.9 planning

Linkmeyer, Mark J <mark.j.linkmeyer@...>
 

Zephyr TSC Members and Zephyr Developers,
 
As we approach the M5 milestone for Zephyr 1.8 (the 1.8 release milestone planned for end of next week), we simultaneously approach the M0 milestone for Zephyr 1.9 where the goal is to have 1.9 fully planned.  By that I mean all stories and tasks that are planned to be delivered as part of 1.9 are specified properly in Jira, prioritized correctly, and have their Fix Version/s field set to v1.9.0 – which signifies they are planned to be part of the 1.9 release.  Also, as appropriate, they should be associated with any relevant epics.  The TSC met on Tuesday to finalize the list of high-level features to be delivered in 1.9.  They are:
 
  • Thread
  • BLE Mesh
  • BSD Sockets
  • POSIX API
  • Build System Enhancements (e.g. support for cmake)
  • MMU/MPU (including thread isolation)
       
You can see the current list of stories and tasks to be delivered in 1.9 (organized by epic) by looking at this Jira board:  https://jira.zephyrproject.org/secure/RapidBoard.jspa?rapidView=46
 
The TSC is meeting again next Tues or Wed to review progress towards getting 1.9 fully planned so if you notice any stories or tasks are missing in the list for 1.9, please add them before Tuesday morning.  Please help us to get the right list of feasible stories and tasks for 1.9 correctly captured in Jira.
 
As a reminder, here’s how the Zephyr project uses the different Jira issue types (epics, stories, tasks, and bugs):  https://wiki.zephyrproject.org/view/Jira_Usage_Help.  And here are the definitions used when setting the priority field:  https://wiki.zephyrproject.org/view/Jira_Usage_Help#Priority_Definitions.
 
If you have any questions, please let me know.
 
Thanks,
Mark
 
Mark Linkmeyer
Intel Corporation
Open Source Technology Centerà Zephyr™ Software Project Manager
 
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or attorney-client privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message.
 
 
 


Re: Zephyrjs ide with arduino 101

Poussa, Sakari
 

Hi Kevin,

 

Can you file an issue (hit green “New Issue” button) at:

 

https://github.com/01org/zephyr.js/issues

 

That is the proper forum to address this issue.

 

Add more details there like how did you build your A101 image and what JS code you are running.

 

Thanks, Sakari

 

On 5/30/17, 11:21 AM, "zephyr-devel-bounces@... on behalf of Kevin Stöckl" <zephyr-devel-bounces@... on behalf of k_stoeckl@...> wrote:

 

Thanks, now i can connect my board.

But there is another problem. When i try to run a Programm it comes an Error (Error: set transfer raw).

What could be the problem?

 


Von: Kinder, David B <david.b.kinder@...>
Gesendet: Donnerstag, 25. Mai 2017 17:18
An: Kevin Stöckl
Cc: devel@...
Betreff: Re: [Zephyr-devel] Zephyrjs ide with arduino 101

 

Hi Kevin,

Check out the web ide demo video (and companion doc) found here: https://www.zephyrproject.org/resources/videos

www.zephyrproject.org

Zephyr Project © 2017 is a Linux Foundation Project. All Rights Reserved. Linux Foundation is a registered trademark of The Linux Foundation. Linux is a registered ...

 

 

I suspect either the tip about Modem manager or setting up device rules may be the culprit for your problem.


-- david kinder


On May 25, 2017, at 10:48 AM, Kevin Stöckl <k_stoeckl@...> wrote:

Hi, 

I am trying to install the zephyr js like in the manual described. But when I try to connect my board in the IDE (https://01org.github.io/zephyrjs-ide/) there are no devices found.

 

I have Ubuntu 14.04 and the newest Version of Chrome.

What could be the problem?

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyrjs ide with arduino 101

Kevin Stöckl <k_stoeckl@...>
 

Thanks, now i can connect my board.

But there is another problem. When i try to run a Programm it comes an Error (Error: set transfer raw).

What could be the problem?




Von: Kinder, David B <david.b.kinder@...>
Gesendet: Donnerstag, 25. Mai 2017 17:18
An: Kevin Stöckl
Cc: devel@...
Betreff: Re: [Zephyr-devel] Zephyrjs ide with arduino 101
 
Hi Kevin,
Check out the web ide demo video (and companion doc) found here: https://www.zephyrproject.org/resources/videos
www.zephyrproject.org
Zephyr Project © 2017 is a Linux Foundation Project. All Rights Reserved. Linux Foundation is a registered trademark of The Linux Foundation. Linux is a registered ...


I suspect either the tip about Modem manager or setting up device rules may be the culprit for your problem.

-- david kinder

On May 25, 2017, at 10:48 AM, Kevin Stöckl <k_stoeckl@...> wrote:

Hi, 

I am trying to install the zephyr js like in the manual described. But when I try to connect my board in the IDE (https://01org.github.io/zephyrjs-ide/) there are no devices found.


I have Ubuntu 14.04 and the newest Version of Chrome.

What could be the problem?

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: CONFIG_FLASH_BASE_ADDRESS

Erwan Gouriou
 

Hi Erwin,


Indeed, make flash functionality has been lost when moving to dts description.
The issue is reported in JIRA:
https://jira.zephyrproject.org/browse/ZEP-2119
Andy proposed a PR to correct this:
https://github.com/zephyrproject-rtos/zephyr/pull/275

Can you have a try?

Erwan



On 30 May 2017 at 00:50, Erwin Rol <mailinglists@...> wrote:
Hello,

Several boards (mostly STM32) have the following lines;

OPENOCD_LOAD_CMD = "flash write_image erase ${O}/${KERNEL_BIN_NAME}
${CONFIG_FLASH_BASE_ADDRESS}"
OPENOCD_VERIFY_CMD = "verify_image ${O}/${KERNEL_BIN_NAME}
${CONFIG_FLASH_BASE_ADDRESS}"

in their Makefile.board file.

The CONFIG_FLASH_BASE_ADDRESS only seems to be a Kconfig variable for
the ARC architecture in arch/arc/Kconfig

For the other platforms it only seems to end up in the files generated
from the DTS, like;
.../outdir/olimex_stm32_e407/include/generated/generated_dts_board.h

The problem seems to be that when calling

make BOARD=olimex_stm32_e407 flash

the variable CONFIG_FLASH_BASE_ADDRESS is not defined in the Makefile
environment, because it doesn't come from Kbuild but from a C header
file. So the flashing goes wrong (because the
${CONFIG_FLASH_BASE_ADDRESS} is empty).

If I change the Makefile.board to;

OPENOCD_LOAD_CMD = "flash write_image erase ${O}/${KERNEL_BIN_NAME}
0x08000000"

Than flashing works (0x08000000 is the flash address on the STM32F4).

I don't have other hardware to test, but are the developers of the
nucleo_*, stm32* boards sure "make flash" works ?

- Erwin
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


CONFIG_FLASH_BASE_ADDRESS

Erwin Rol
 

Hello,

Several boards (mostly STM32) have the following lines;

OPENOCD_LOAD_CMD = "flash write_image erase ${O}/${KERNEL_BIN_NAME}
${CONFIG_FLASH_BASE_ADDRESS}"
OPENOCD_VERIFY_CMD = "verify_image ${O}/${KERNEL_BIN_NAME}
${CONFIG_FLASH_BASE_ADDRESS}"

in their Makefile.board file.

The CONFIG_FLASH_BASE_ADDRESS only seems to be a Kconfig variable for
the ARC architecture in arch/arc/Kconfig

For the other platforms it only seems to end up in the files generated
from the DTS, like;
.../outdir/olimex_stm32_e407/include/generated/generated_dts_board.h

The problem seems to be that when calling

make BOARD=olimex_stm32_e407 flash

the variable CONFIG_FLASH_BASE_ADDRESS is not defined in the Makefile
environment, because it doesn't come from Kbuild but from a C header
file. So the flashing goes wrong (because the
${CONFIG_FLASH_BASE_ADDRESS} is empty).

If I change the Makefile.board to;

OPENOCD_LOAD_CMD = "flash write_image erase ${O}/${KERNEL_BIN_NAME}
0x08000000"

Than flashing works (0x08000000 is the flash address on the STM32F4).

I don't have other hardware to test, but are the developers of the
nucleo_*, stm32* boards sure "make flash" works ?

- Erwin


Re: Shell add 'exit' command to leave current module

Siddharth Chandrasekaran
 

Hello Anas,

Thanks, already raised PR #320.

Siddharth.


---- On Mon, 29 May 2017 08:13:41 +0530 anas.nashif@... wrote ----

Submit a pull request please with the change below. Seems to be a reasonable enhancement.

Anas

On 26/05/2017, 02:08, "zephyr-devel-bounces@... on behalf of Siddharth Chandrasekaran" <zephyr-devel-bounces@... on behalf of siddharth@...> wrote:

Hello,

In shell, to select a module, we use 'select <module_name>'. When inside
a module, there is no indication on how one has to leave the module.
Would it be better to have an 'exit' ?

I know (after reading code) we can use 'select' without and argument to
go back to default module but having an exit will make things more
clear. Besides, people are used to hitting 'exit' or 'quit' to leave a
prompt so I thought it makes sense to have it here as well.

Proposed change listed below.

Thanks,
Siddharth.

---

diff --git a/subsys/shell/shell.c b/subsys/shell/shell.c
index 228f876..7e53aad 100644
--- a/subsys/shell/shell.c
+++ b/subsys/shell/shell.c
@@ -233,6 +233,7 @@ static int show_help(int argc, char *argv[])
        }

        print_module_commands(module);
+        printk("\nEnter 'exit' to leave current module.\n");
    } else { /* help for all entities */
        printk("Available modules:\n");
        for (module = 0; module < NUM_OF_SHELL_ENTITIES; module++) {
@@ -280,6 +281,15 @@ static int select_module(int argc, char *argv[])
    return 0;
}

+static int exit_module(int argc, char *argv[])
+{
+    if (argc == 1) {
+        default_module = -1;
+    }
+
+    return 0;
+}
+
static shell_cmd_function_t get_cb(int argc, char *argv[])
{
    const char *first_string = argv[0];
@@ -301,6 +311,10 @@ static shell_cmd_function_t get_cb(int argc, char *argv[])
        return select_module;
    }

+    if (!strcmp(first_string, "exit")) {
+        return exit_module;
+    }
+
    if ((argc == 1) && (default_module == -1)) {
        printk("Missing parameter\n");
        return NULL;

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: Shell add 'exit' command to leave current module

Nashif, Anas
 

Submit a pull request please with the change below. Seems to be a reasonable enhancement.

Anas

On 26/05/2017, 02:08, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Siddharth Chandrasekaran" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of siddharth@embedjournal.com> wrote:

Hello,

In shell, to select a module, we use 'select <module_name>'. When inside
a module, there is no indication on how one has to leave the module.
Would it be better to have an 'exit' ?

I know (after reading code) we can use 'select' without and argument to
go back to default module but having an exit will make things more
clear. Besides, people are used to hitting 'exit' or 'quit' to leave a
prompt so I thought it makes sense to have it here as well.

Proposed change listed below.

Thanks,
Siddharth.

---

diff --git a/subsys/shell/shell.c b/subsys/shell/shell.c
index 228f876..7e53aad 100644
--- a/subsys/shell/shell.c
+++ b/subsys/shell/shell.c
@@ -233,6 +233,7 @@ static int show_help(int argc, char *argv[])
}

print_module_commands(module);
+ printk("\nEnter 'exit' to leave current module.\n");
} else { /* help for all entities */
printk("Available modules:\n");
for (module = 0; module < NUM_OF_SHELL_ENTITIES; module++) {
@@ -280,6 +281,15 @@ static int select_module(int argc, char *argv[])
return 0;
}

+static int exit_module(int argc, char *argv[])
+{
+ if (argc == 1) {
+ default_module = -1;
+ }
+
+ return 0;
+}
+
static shell_cmd_function_t get_cb(int argc, char *argv[])
{
const char *first_string = argv[0];
@@ -301,6 +311,10 @@ static shell_cmd_function_t get_cb(int argc, char *argv[])
return select_module;
}

+ if (!strcmp(first_string, "exit")) {
+ return exit_module;
+ }
+
if ((argc == 1) && (default_module == -1)) {
printk("Missing parameter\n");
return NULL;

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Shell add 'exit' command to leave current module

Siddharth Chandrasekaran
 

Hello,

In shell, to select a module, we use 'select <module_name>'. When inside
a module, there is no indication on how one has to leave the module.
Would it be better to have an 'exit' ?

I know (after reading code) we can use 'select' without and argument to
go back to default module but having an exit will make things more
clear. Besides, people are used to hitting 'exit' or 'quit' to leave a
prompt so I thought it makes sense to have it here as well.

Proposed change listed below.

Thanks,
Siddharth.

---

diff --git a/subsys/shell/shell.c b/subsys/shell/shell.c
index 228f876..7e53aad 100644
--- a/subsys/shell/shell.c
+++ b/subsys/shell/shell.c
@@ -233,6 +233,7 @@ static int show_help(int argc, char *argv[])
}

print_module_commands(module);
+ printk("\nEnter 'exit' to leave current module.\n");
} else { /* help for all entities */
printk("Available modules:\n");
for (module = 0; module < NUM_OF_SHELL_ENTITIES; module++) {
@@ -280,6 +281,15 @@ static int select_module(int argc, char *argv[])
return 0;
}

+static int exit_module(int argc, char *argv[])
+{
+ if (argc == 1) {
+ default_module = -1;
+ }
+
+ return 0;
+}
+
static shell_cmd_function_t get_cb(int argc, char *argv[])
{
const char *first_string = argv[0];
@@ -301,6 +311,10 @@ static shell_cmd_function_t get_cb(int argc, char *argv[])
return select_module;
}

+ if (!strcmp(first_string, "exit")) {
+ return exit_module;
+ }
+
if ((argc == 1) && (default_module == -1)) {
printk("Missing parameter\n");
return NULL;


Re: Form submission from: Contact Us

Maureen Helm
 

I’ve had success debugging Zephyr on FRDM-K64F with Kinetis Design Studio (KDS). It’s not vanilla Eclipse, but it is Eclipse-based. You can set up an OpenOCD debug configuration. I’ve been meaning to try this with the next generation IDE, called MCUXpresso IDE, but haven’t gotten to it yet.

 

I’ve not tried building Zephyr in Eclipse.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Brett Preston
Sent: Wednesday, May 24, 2017 9:29 AM
To: devel@...
Cc: prasad-hegde.nagapati@...
Subject: [Zephyr-devel] Fwd: Form submission from: Contact Us

 

(redirecting to devel mail list)

 

"Is there any eclipse based SDK available for development and debugging?"

 

---------- Forwarded message ----------
From: Zephyr Project <donotreply@...>
Date: Wed, May 24, 2017 at 2:01 AM
Subject: Form submission from: Contact Us
To: info@...


Submitted on Wednesday, May 24, 2017 - 4:01am
Submitted by anonymous user: 192.19.237.250
Submitted values are:

Name: Prasad hegde
Email: prasad-hegde.nagapati@...
Comment:
Is there any eclipse based SDK available for development and debugging?

Prasad


The results of this submission may be viewed at:
https://www.zephyrproject.org/node/116/submission/18



 

--

Brett Preston

The Linux Foundation

+1 (971) 303-9030
bpreston@...

 

Google Talk: bpreston@...

Skype: bprestoncf


Re: Form submission from: Contact Us

Maureen Helm
 

No, just Cortex M’s currently.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Brett Preston
Sent: Wednesday, May 24, 2017 9:28 AM
To: devel@...
Cc: prasad-hegde.nagapati@...
Subject: [Zephyr-devel] Fwd: Form submission from: Contact Us

 

(redirecting to devel mail list)

 

"Does Zephyr support the ARM-A series, I mean application processors of ARM

like A7 and A9 series?"

 

---------- Forwarded message ----------
From: Zephyr Project <donotreply@...>
Date: Wed, May 24, 2017 at 1:44 AM
Subject: Form submission from: Contact Us
To: info@...


Submitted on Wednesday, May 24, 2017 - 3:44am
Submitted by anonymous user: 192.19.237.250
Submitted values are:

Name: Prasad hegde
Email: prasad-hegde.nagapati@...
Comment:
Does Zephyr support the ARM-A series, I mean application processors of ARM
like A7 and A9 series?

Thanks
Prasad


The results of this submission may be viewed at:
https://www.zephyrproject.org/node/116/submission/17



 

--

Brett Preston

The Linux Foundation

+1 (971) 303-9030
bpreston@...

 

Google Talk: bpreston@...

Skype: bprestoncf

5121 - 5140 of 8109