|
96Boards GPIO standard names?
Hi Lawrence, FYI: I have just created a github issue [1] for tracking this. Please take a look and share your thoughts. Thanks, Mani [1] https://github.com/zephyrproject-rtos/zephyr/issues/15598
Hi Lawrence, FYI: I have just created a github issue [1] for tracking this. Please take a look and share your thoughts. Thanks, Mani [1] https://github.com/zephyrproject-rtos/zephyr/issues/15598
|
By
Mani Sadhasivam
· #1433
·
|
|
96Boards GPIO standard names?
---------- Forwarded message --------- From: Mani Sadhasivam <manivannanece23@...> Date: Tue, 5 Mar, 2019, 12:11 AM Subject: Re: [Zephyr-users] 96Boards GPIO standard names? To: Lawrence King <l
---------- Forwarded message --------- From: Mani Sadhasivam <manivannanece23@...> Date: Tue, 5 Mar, 2019, 12:11 AM Subject: Re: [Zephyr-users] 96Boards GPIO standard names? To: Lawrence King <l
|
By
Mani Sadhasivam
· #1329
·
|
|
#customboard #defconfig #supervisormode
#customboard
#defconfig
#supervisormode
That's right! In RISC-V terms, Machine mode has access to all system resources and is the mandatory mode to implement. Supervisor mode has a different usage model, which I guess used for virtualizatio
That's right! In RISC-V terms, Machine mode has access to all system resources and is the mandatory mode to implement. Supervisor mode has a different usage model, which I guess used for virtualizatio
|
By
Mani Sadhasivam
· #1148
·
|
|
#customboard #defconfig #supervisormode
#customboard
#defconfig
#supervisormode
Where did you find this information? For RISC-V SoCs, the supervisor mode is only used when the base architecture has the 'S' extension. Since there is no Supervisor enabled SoCs supported by Zephyr s
Where did you find this information? For RISC-V SoCs, the supervisor mode is only used when the base architecture has the 'S' extension. Since there is no Supervisor enabled SoCs supported by Zephyr s
|
By
Mani Sadhasivam
· #1143
·
|
|
#customboard #defconfig #supervisormode
#customboard
#defconfig
#supervisormode
Hi Sathya, Which SoC are you trying with? AFAIK all supported SoC's only incorporate Machine mode access, not even User mode. Supervisor mode is meant for a full-fledged operating system. Thanks, Mani
Hi Sathya, Which SoC are you trying with? AFAIK all supported SoC's only incorporate Machine mode access, not even User mode. Supervisor mode is meant for a full-fledged operating system. Thanks, Mani
|
By
Mani Sadhasivam
· #1141
·
|
|
Unable to set Appkey for generic server model
Hi Johan, You are right... Mistakenly specified the cfg_srv model. It is working fine now :) Sure, will make use of it. Thanks for the clarification! Regards, Mani
Hi Johan, You are right... Mistakenly specified the cfg_srv model. It is working fine now :) Sure, will make use of it. Thanks for the clarification! Regards, Mani
|
By
Mani Sadhasivam
· #414
·
|
|
Unable to set Appkey for generic server model
Hello, My objective is to use 96Boards carbons running Zephyr to form a mesh network for publishing sensor data. For testing purposes, I am using Generic ON/OFF server model for sending the sensor dat
Hello, My objective is to use 96Boards carbons running Zephyr to form a mesh network for publishing sensor data. For testing purposes, I am using Generic ON/OFF server model for sending the sensor dat
|
By
Mani Sadhasivam
· #412
·
|
|
I2c problem on 96b Carbon.
yikes... I was connecting to PB8/PB9 by looking at the pinout. But the default pinmux is configured for PB6/PB7 and it works with the same. It looks confusing with having two different I2C_1 labels in
yikes... I was connecting to PB8/PB9 by looking at the pinout. But the default pinmux is configured for PB6/PB7 and it works with the same. It looks confusing with having two different I2C_1 labels in
|
By
Mani Sadhasivam
· #129
·
|
|
I2c problem on 96b Carbon.
Hello, I've observed the same issue on 96b_carbon while trying to communicate over I2C_1. In polling mode, it looks like carbon sends slave address and waits forever for the status of address sent in
Hello, I've observed the same issue on 96b_carbon while trying to communicate over I2C_1. In polling mode, it looks like carbon sends slave address and waits forever for the status of address sent in
|
By
Mani Sadhasivam
· #127
·
|