Re: [riot-devel] native target, adc and encx24j600

[Martine Lenders]

Hi Temmu,

actually, there is no `periph_adc` implementation on native. But if you
don't care about the return value, a simple mock-up should be easily
ported. Just adapt the `periph_conf.h` of native accordingly and add the
implementation to `cpu/native/periph/adc.c`. For the encxj600 problem: just
use netdev_tap instead. It's also a (virtual) Ethernet device and can
communicate with other native instances and the host system via TAP.

Cheers,
Martine

2017-09-08 11:54 GMT+02:00 temmi...@gmail.com :

> Hi
>
> I have a small application that uses gcoap as server, which I'd like to
> debug the network traffic with BOARD=native. Currently it fails to compile
> because of periph/adc and likely will fail also because of encxj600.
>
> How to modify the program so that it compiles to BOARD=native and
> BOARD=nucleo-f401 using proper hardware on the nucleo-f401 and something
> fake on native? I'm not worried about what the native-adc reads.
>
>  - t
> ___
> 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] native target, adc and encx24j600

[temmi...@gmail.com]

Hi

I have a small application that uses gcoap as server, which I'd like to debug 
the network traffic with BOARD=native. Currently it fails to compile because of 
periph/adc and likely will fail also because of encxj600.

How to modify the program so that it compiles to BOARD=native and 
BOARD=nucleo-f401 using proper hardware on the nucleo-f401 and something fake 
on native? I'm not worried about what the native-adc reads.

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

Re: [riot-devel] pm_reboot

[Robert Hartung]

Looks like it's not that easy. Many platforms define pm_reboot in the
board's file(s).
Additionally pm_layered does not define pm_reboot, the same applies for
pm_off (pm_off can be modeled as pm_set_lowest(); irq_disable();
while(1) in pm_layered I guess ?).

Therefore I will work on removing pm_reboot() from pm_fallback
implementation and create additional modules if needed (at some points
pm_reboot is defined outside of pm anyway).

- Robert

On 08.09.2017 11:03, Robert Hartung wrote:
> After a short discussion offline we decided to keep it as it is. As the
> nucleo board for example, supports saving reigsters across the reset.
> Therefor when entering low power modes or making a reboot, it might be
> required to perform some more stuff.
> 
> The pm_* functions will now all be combined in a single module to make
> it easier to develop PM for other cpus.
> 
> - Robert
> 
> On 08.09.2017 10:20, Robert Hartung wrote:
>> Hi *,
>>
>> I am working on the pm (power management) module of RIOT. Can anyone
>> tell me why pm_reboot is (often) part of this module?
>>
>> If no one votes against it, I woud like to move *pm_reboot()* to a
>> dedicated module, in order to have a reboot_fallback module as we have
>> planned for pm_fallback and additionally common CPUs can implement
>> specific reboot functions if required.
>>
>> Is 'reboot' a good module name? Or should we name it pm_reboot_fallback
>> (prefix it with pm)?
>>
>> Background: atmega_common defines a pm_reboot, but no power management
>> by default. Therefore using pm_fallback is not possible and we would
>> have to duplicate existing code (bad idea!).
>>
>> Best,
>> Robert
>>
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] pm_reboot

[Robert Hartung]

After a short discussion offline we decided to keep it as it is. As the
nucleo board for example, supports saving reigsters across the reset.
Therefor when entering low power modes or making a reboot, it might be
required to perform some more stuff.

The pm_* functions will now all be combined in a single module to make
it easier to develop PM for other cpus.

- Robert

On 08.09.2017 10:20, Robert Hartung wrote:
> Hi *,
> 
> I am working on the pm (power management) module of RIOT. Can anyone
> tell me why pm_reboot is (often) part of this module?
> 
> If no one votes against it, I woud like to move *pm_reboot()* to a
> dedicated module, in order to have a reboot_fallback module as we have
> planned for pm_fallback and additionally common CPUs can implement
> specific reboot functions if required.
> 
> Is 'reboot' a good module name? Or should we name it pm_reboot_fallback
> (prefix it with pm)?
> 
> Background: atmega_common defines a pm_reboot, but no power management
> by default. Therefore using pm_fallback is not possible and we would
> have to duplicate existing code (bad idea!).
> 
> Best,
> Robert
> 

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] pm_reboot

[Robert Hartung]

Hi *,

I am working on the pm (power management) module of RIOT. Can anyone
tell me why pm_reboot is (often) part of this module?

If no one votes against it, I woud like to move *pm_reboot()* to a
dedicated module, in order to have a reboot_fallback module as we have
planned for pm_fallback and additionally common CPUs can implement
specific reboot functions if required.

Is 'reboot' a good module name? Or should we name it pm_reboot_fallback
(prefix it with pm)?

Background: atmega_common defines a pm_reboot, but no power management
by default. Therefore using pm_fallback is not possible and we would
have to duplicate existing code (bad idea!).

Best,
Robert

-- 
Robert Hartung, M.Sc.

Technische Universität Braunschweig
Institut für Betriebssysteme und Rechnerverbund
Mühlenpfordtstr. 23, Raum 115
38106 Braunschweig

Fon: +49 (531) 391 - 3264
Fax: +49 (531) 391 - 5936
E-Mail: hart...@ibr.cs.tu-bs.de
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel