date:20190527

Re: [riot-devel] How to properly use cortexm_sleep

2019-05-27 Thread Kees Bakker


Thanks Juan,

That's a lot of information to digest. It will take me a bit of time
to go through.
-- Kees

On 27-05-19 14:17, Juan Ignacio Carrano wrote:

Hi Kees,

Some observations:

1- WFI will not send you to the deepest sleep states- clocks are 
gated, but many things remain powered.


2- If you are using the timer module and depending on you clock 
configuration you may experience more or less frequent wake ups. 
Whether this is acceptable is up to you.


3- Normally, if no thread is runnable (i.e. all are waiting/blocked) the
idle thread is run and that has a loop which sends the MCU to the 
deepest state possible (considering the currently-enabled 
peripherals). This means that in many cases the explicit WFI is not 
needed if in your
"while(forever)" loop you put some call that blocks waiting for the 
events you are interested in.


The interaction between (1) and (3) means that by doing a WFI in a 
thread it is possible that you don't sleep as deep as you could:


- The current thread will be blocked on the WFI instruction until an
  event arrives.
- In the meantime, control will not go back to the kernel.
- This means the idle thread will not run (from the schedulers point of
  view, you thread is still running).
- The pm_whatever() call in the idle thread will not run.

In conclusion, try to use the default mechanism if you can.

Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to properly use cortexm_sleep

2019-05-27 Thread Kees Bakker


Hey Oleg,

Are you using the watchdog?

On 27-05-19 07:30, Oleg Artamonov wrote:

Hi
We do. On STM32L0, STM32L1, nRF52, etc.
Checking for interrupt flags is absolutely useless here - 1) WFI 
checks for any relevant interrupt flags, 2) interrupt still can happen 
between check and WFI.

--
/Sincerely yours,/
/Oleg Artamonov/
/+7 (916) 631-34-90/
/www.unwds.com/ 
26.05.2019, 18:40, "Kees Bakker" :

Hey

Is there anyone using cortexm_sleep for a real application? And if
yes, would you want to share how exactly that's done?

Let me say that I've never written a real application with RIOT, but
I would like to. One of the important requirements is that the app
must be in sleep (deep sleep) and only wake up to do some work.
And another requirement is to use the watchdog.

That said, I'm familiar with the following Arduino pseudo code.

 while (forever) {
 do stuff

 disable interrupts
 if !certain condition
 __WFI();
 enable interrupts
 }

That "certain condition" is mostly checking that no WDT or RTC
interrupt
occurred before disabling the interrupts. These interrupts are handled
by ISR's and they set a flag. This is a fairly common thing to do,
I think.

I don't see (or understand) how this can be achieved with RIOT-OS and
cortexm_sleep. It is essential to check the condition AFTER
disabling the
interrupts.

--
Kees Bakker
___
devel mailing list
devel@riot-os.org 
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Notification: Hack'n'ACK @ Tue May 28, 2019 5pm - 10pm (CEST) (RIOT Events)

2019-05-27 Thread Martine Lenders

Hi,

this is a reminder or maybe new information for some: The Hack'n'ACK this
month will start in Berlin (and Paris?) tomorrow already at 3pm. If we see
a success in the number of attendance, this might become a regular thing.

Kind regards,
Martine

Am Mo., 27. Mai 2019 um 17:01 Uhr schrieb Google Calendar <
calendar-notificat...@google.com>:

> more details »
> 
> Hack'n'ACK
> https://meet.jit.si/riot-hacknack
> 
> *When*
> Tue May 28, 2019 5pm – 10pm Central European Time - Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> )
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> Invitation from Google Calendar 
>
> You are receiving this email at the account peterschme...@gmail.com
> because you are subscribed for notifications on calendar RIOT Events.
>
> To stop receiving these emails, please log in to
> https://www.google.com/calendar/ and change your notification settings
> for this calendar.
>
> Forwarding this invitation could allow any recipient to send a response to
> the organizer and be added to the guest list, or invite others regardless
> of their own invitation status, or to modify your RSVP. Learn More
> .
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Notification: Hack'n'ACK @ Tue May 28, 2019 5pm - 10pm (CEST) (RIOT Events)

2019-05-27 Thread Google Calendar


This is a notification for:

Title: Hack'n'ACK
https://meet.jit.si/riot-hacknack
When: Tue May 28, 2019 5pm – 10pm Central European Time - Berlin
Where: FU Berlin; HAW Hamburg
Calendar: RIOT Events
Who:
* Martine Lenders - creator

Event details:  
https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxOTA1MjhUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1


Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this email at the account peterschme...@gmail.com because  
you are subscribed for notifications on calendar RIOT Events.


To stop receiving these emails, please log in to  
https://www.google.com/calendar/ and change your notification settings for  
this calendar.


Forwarding this invitation could allow any recipient to send a response to  
the organizer and be added to the guest list, or invite others regardless  
of their own invitation status, or to modify your RSVP. Learn more at  
https://support.google.com/calendar/answer/37135#forwarding
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] CC2538dk Riotboot support

2019-05-27 Thread Gaëtan Harter

On 5/27/19 2:36 PM, Emmanuel Baccelli wrote:

Seems to me that a quick riotboot porting guide could be useful somewhere
in the wiki.

More in the `riotboot` documentation in the repository I would say.

On Mon, May 27, 2019 at 2:30 PM Gaëtan Harter
wrote:

Hi Brenton,

if you only use the default `riotboot/flash` or `flash` in
`tests/riotboot` targets, you do not need flasher changes.
But you should not use `riotboot/flash-slot0` and `riotboot/flash-slot1`
targets for the moment.

To have the support declared and merged in RIOT, it also needs to
support flashing the `slot-` firmwares alone. These require having
flasher that can flash with an offset`.

For `cc2538-bsl.py` it looks like there is the `-a` option for this.

Maybe changing it to use `IMAGE_OFFSET` if set would be enough.
An example is in

https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15

The `flash.sh` is currently using `jlink` without using the common
`jlink` scripts thing, it is in my todo list after
https://github.com/RIOT-OS/RIOT/pull/11554 to migrate to use the common
one where applicable.

Cheers,
Gaëtan

On 5/24/19 2:32 PM, Francisco Acosta wrote:

Hi Brenton!

So far I remember we didn't take it into account, and I don't know if
someone is taking care of it.

As far as I know, there are two ways of supporting that CPU:

1. The way we do it now, which is linking the image in another start
address so the bootloader can recognise it and boot it.

2. Modify the start address on the CC2538 register dedicated to this.
This might be a bit tricky but also interesting for the sake of research
and compatibility.

However, I'd advice the first option to have the full benefits of the
bootloader and struggling less with the particular settings on that
chip.

Overall, the steps would be the following:

1. Adapt the linker scripts to succeed tests/cortexm_common_ldscript.
This consists on making the linker scripts on cpu/cc2838/ldscripts
comply with cpu/cortexm_common/ldscrpts/cortexm.ld. You might take a
look how is it done for stm32 or sam0 families.

2. Provide the length and start variables to link slots correctly:
- ROM_LEN
- RAM_LEN
- ROM_START_ADDR
- RAM_START_ADDR

Again, take a look on the supported CPUs as examples.

3. Make tests/riotboot pass

4. Perform a firmware update or flash different firmwares with different
versions so the bootloader choses the newest.

Optionally you might want to test if the WIP SUIT update format works.

Don't hesitate to make more questions if you have some!

Cheers,

Paco.

On 24/05/2019 13:43, Brenton Chetty wrote:

Hey guys, has anyone succeeded in providing riotboot support for the
cc2538dk board as yet?

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Lightweight Syslog Implementation

2019-05-27 Thread Juan Ignacio Carrano


On 24/5/19 11:40, Kaspar Schleiser wrote:

> IMO the syslog API itself should not be used for new or RIOT-targeting

applications...


Except it already is:


#define log_write(level, ...) printf(__VA_ARGS__)


and


static inline void log_write(unsigned level, const char *format, ...) {


While syslog has


void syslog(int priority, const char *format, ...);


So the existing log framework is almost the same as syslog, but with 
different names (it makes sense, there are not that many ways of doing 
logging.)


BTW, this thing can be quite useful when logging to serial: by having a 
backend that sends logs as messages in a queue one can prevent messages 
sent simultaneously from stepping over each other.


Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] CC2538dk Riotboot support

2019-05-27 Thread Emmanuel Baccelli

Seems to me that a quick riotboot porting guide could be useful somewhere
in the wiki.


On Mon, May 27, 2019 at 2:30 PM Gaëtan Harter 
wrote:

> Hi Brenton,
>
> if you only use the default `riotboot/flash` or `flash` in
> `tests/riotboot` targets, you do not need flasher changes.
> But you should not use `riotboot/flash-slot0` and `riotboot/flash-slot1`
> targets for the moment.
>
> To have the support declared and merged in RIOT, it also needs to
> support flashing the `slot-` firmwares alone. These require having
> flasher that can flash with an offset`.
>
> For `cc2538-bsl.py` it looks like there is the `-a` option for this.
>
> Maybe changing it to use `IMAGE_OFFSET` if set would be enough.
> An example is in
>
> https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15
>
> The `flash.sh` is currently using `jlink` without using the common
> `jlink` scripts thing, it is in my todo list after
> https://github.com/RIOT-OS/RIOT/pull/11554 to migrate to use the common
> one where applicable.
>
> Cheers,
> Gaëtan
>
> On 5/24/19 2:32 PM, Francisco Acosta wrote:
> > Hi Brenton!
> >
> > So far I remember we didn't take it into account, and I don't know if
> > someone is taking care of it.
> >
> > As far as I know, there are two ways of supporting that CPU:
> >
> > 1. The way we do it now, which is linking the image in another start
> > address so the bootloader can recognise it and boot it.
> >
> > 2. Modify the start address on the CC2538 register dedicated to this.
> > This might be a bit tricky but also interesting for the sake of research
> > and compatibility.
> >
> > However, I'd advice the first option to have the full benefits of the
> > bootloader and struggling less with the particular settings on that
> > chip.
> >
> > Overall, the steps would be the following:
> >
> > 1. Adapt the linker scripts to succeed tests/cortexm_common_ldscript.
> > This consists on making the linker scripts on cpu/cc2838/ldscripts
> > comply with cpu/cortexm_common/ldscrpts/cortexm.ld. You might take a
> > look how is it done for stm32 or sam0 families.
> >
> > 2. Provide the length and start variables to link slots correctly:
> >- ROM_LEN
> >- RAM_LEN
> >- ROM_START_ADDR
> >- RAM_START_ADDR
> >
> > Again, take a look on the supported CPUs as examples.
> >
> > 3. Make tests/riotboot pass
> >
> > 4. Perform a firmware update or flash different firmwares with different
> > versions so the bootloader choses the newest.
> >
> > Optionally you might want to test if the WIP SUIT update format works.
> >
> > Don't hesitate to make more questions if you have some!
> >
> > Cheers,
> >
> > Paco.
> >
> >
> > On 24/05/2019 13:43, Brenton Chetty wrote:
> >> Hey guys, has anyone succeeded in providing riotboot support for the
> >> cc2538dk board as yet?
> >>
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> >>
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] CC2538dk Riotboot support

2019-05-27 Thread Gaëtan Harter

Hi Brenton,

To have the support declared and merged in RIOT, it also needs to
support flashing the `slot-` firmwares alone. These require having
flasher that can flash with an offset`.

For `cc2538-bsl.py` it looks like there is the `-a` option for this.

Maybe changing it to use `IMAGE_OFFSET` if set would be enough.
An example is in
https://github.com/RIOT-OS/RIOT/blob/8fe12bc82cfbb83a90efd018e11c044d0a40696b/makefiles/tools/edbg.inc.mk#L14-L15

Cheers,
Gaëtan

On 5/24/19 2:32 PM, Francisco Acosta wrote:

Hi Brenton!

So far I remember we didn't take it into account, and I don't know if
someone is taking care of it.

As far as I know, there are two ways of supporting that CPU:

1. The way we do it now, which is linking the image in another start
address so the bootloader can recognise it and boot it.

2. Modify the start address on the CC2538 register dedicated to this.
This might be a bit tricky but also interesting for the sake of research
and compatibility.

However, I'd advice the first option to have the full benefits of the
bootloader and struggling less with the particular settings on that
chip.

Overall, the steps would be the following:

2. Provide the length and start variables to link slots correctly:
- ROM_LEN
- RAM_LEN
- ROM_START_ADDR
- RAM_START_ADDR

Again, take a look on the supported CPUs as examples.

3. Make tests/riotboot pass

4. Perform a firmware update or flash different firmwares with different
versions so the bootloader choses the newest.

Optionally you might want to test if the WIP SUIT update format works.

Don't hesitate to make more questions if you have some!

Cheers,

Paco.

On 24/05/2019 13:43, Brenton Chetty wrote:
Hey guys, has anyone succeeded in providing riotboot support for the
cc2538dk board as yet?

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to properly use cortexm_sleep

2019-05-27 Thread Juan Ignacio Carrano


Hi Kees,

Some observations:

1- WFI will not send you to the deepest sleep states- clocks are gated, 
but many things remain powered.


2- If you are using the timer module and depending on you clock 
configuration you may experience more or less frequent wake ups. Whether

this is acceptable is up to you.

3- Normally, if no thread is runnable (i.e. all are waiting/blocked) the
idle thread is run and that has a loop which sends the MCU to the 
deepest state possible (considering the currently-enabled peripherals). 
This means that in many cases the explicit WFI is not needed if in your
"while(forever)" loop you put some call that blocks waiting for the 
events you are interested in.


The interaction between (1) and (3) means that by doing a WFI in a 
thread it is possible that you don't sleep as deep as you could:


- The current thread will be blocked on the WFI instruction until an
  event arrives.
- In the meantime, control will not go back to the kernel.
- This means the idle thread will not run (from the schedulers point of
  view, you thread is still running).
- The pm_whatever() call in the idle thread will not run.

In conclusion, try to use the default mechanism if you can.

Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to properly use cortexm_sleep

2019-05-27 Thread Oleg Artamonov

Hi We do. On STM32L0, STM32L1, nRF52, etc. Checking for interrupt flags is absolutely useless here - 1) WFI checks for any relevant interrupt flags, 2) interrupt still can happen between check and WFI. -- Sincerely yours,Oleg Artamonov+7 (916) 631-34-90www.unwds.com   26.05.2019, 18:40, "Kees Bakker" :HeyIs there anyone using cortexm_sleep for a real application? And ifyes, would you want to share how exactly that's done?Let me say that I've never written a real application with RIOT, butI would like to. One of the important requirements is that the appmust be in sleep (deep sleep) and only wake up to do some work.And another requirement is to use the watchdog.That said, I'm familiar with the following Arduino pseudo code. while (forever) { do stuff disable interrupts if !certain condition __WFI(); enable interrupts }That "certain condition" is mostly checking that no WDT or RTC interruptoccurred before disabling the interrupts. These interrupts are handledby ISR's and they set a flag. This is a fairly common thing to do, I think.I don't see (or understand) how this can be achieved with RIOT-OS andcortexm_sleep. It is essential to check the condition AFTER disabling theinterrupts.--Kees Bakker___devel mailing listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Lightweight Syslog Implementation

2019-05-27 Thread Robin


Hi Kaspar,


IMO the syslog API itself should not be used for new or RIOT-targeting
applications. Having it available makes porting existing code easier,
thus I still think it is valid to have it available.
Having the syslog-over-udp functionality available is pretty awesome,
especially if it could be hooked up to the existing LOG_* framework.
Have you tried that?


That's a good point. It should be fairly easy to add additional wrapper 
functionality to use the LOG_* Framework. I will have a look into it.


I also thinking about moving the syslogd functionality directly into 
RIOT (and not as a pkg). This would enable the user to only use the 
outputs (UDP, File, Terminal etc.)  relevant for a specific application 
(and thus reducing binary sizes).


Maybe I can also fit the syslogd into the existing LOG_* API.


Robin



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to properly use cortexm_sleep

Re: [riot-devel] How to properly use cortexm_sleep

Re: [riot-devel] Notification: Hack'n'ACK @ Tue May 28, 2019 5pm - 10pm (CEST) (RIOT Events)

[riot-devel] Notification: Hack'n'ACK @ Tue May 28, 2019 5pm - 10pm (CEST) (RIOT Events)

Re: [riot-devel] CC2538dk Riotboot support

Re: [riot-devel] Lightweight Syslog Implementation

Re: [riot-devel] CC2538dk Riotboot support

Re: [riot-devel] CC2538dk Riotboot support

Re: [riot-devel] How to properly use cortexm_sleep

Re: [riot-devel] How to properly use cortexm_sleep

Re: [riot-devel] Lightweight Syslog Implementation

11 matches

Site Navigation

Mail list logo

Footer information