Re: [riot-devel] IEEEE 802.15.4 FCF Format in "RIOT/sys/net/link_layer/ieee802154/ieee802154.c"

[Joakim Nohlgård]

I think you are confusing byte ordering with bit ordering, the IEEE
802.15.4 frame format uses little-endian _byte_ ordering, so the least
significant byte comes first. But inside each byte, the least
significant bit has number 0, the most significant bit has number 7.
Therefore, a byte where only bit number 4 is set (written 1 << 4 in
C), is equal to 0x10.

/Joakim

On Wed, Nov 27, 2019 at 2:16 PM Aboodi Ahed Hussein Ali
 wrote:
>
> Thank you, Joakim, but I don't think it is correct.
>
> Starting from 0, bit No. 3 of the IEEE802154_FCF_VERS_V1 (Hex 0x10 or binary: 
> 0001 ) have the value 1, thus 0 to 3 represent 8 to 11 on buf[1]. 
> therefor, the bit No. 3, in 0x10, is set on bit No. 11 of the FCF.
>
> Not sure if the below illustration will be on a layout.
> ---buf[0] buf[1]
>         <-- FCF
> - 0001    <-- IEEE802154_FCF_VERS_V1
>
> This means that the Frame version is not really set probably or this file 
> "RIOT/sys/net/link_layer/ieee802154/ieee802154.c" follows a different FCF 
> format!!
>
> Am I correct or did I misunderstand that?
>
> Ahed
> 
> From: Aboodi Ahed Hussein Ali
> Sent: Wednesday, November 27, 2019 5:58 AM
> To: RIOT OS developers list 
> Subject: I 802.15.4 FCF Format in 
> "RIOT/sys/net/link_layer/ieee802154/ieee802154.c"
>
> Hi all,
>
> I am having a hard time understanding how the "ieee802154_set_frame_hdr" 
> function, found in this link, sets the Frame Control Field (FCF) for 802.15.4 
> frame header.
> Following the IEEE 802.15.4 FCF format, frame version should be at the 
> 12-13th bit of the 2-byte FCF, while in the function code, the frame version 
> was set at the 11th bit. Does it uses different FCF format or am I missing 
> something?
>
> This is the first part of the function:
>
> size_t ieee802154_set_frame_hdr(uint8_t *buf, const uint8_t *src, size_t 
> src_len,
> const uint8_t *dst, size_t dst_len,
> le_uint16_t src_pan, le_uint16_t dst_pan,
> uint8_t flags, uint8_t seq)
> {
> int pos = 3;/* 0-1: FCS, 2: seq */
> uint8_t type = (flags & IEEE802154_FCF_TYPE_MASK);
>
> buf[0] = flags;
> buf[1] = IEEE802154_FCF_VERS_V1;  // IEEE802154_FCF_VERS_V1 is 
> defined as 0x10
>
> if (((src_len != 0) && (src == NULL)) ||
> ((dst_len != 0) && (dst == NULL))) {
> return 0;
> }
> ...
> ...
>
> The first two bytes of the *buf represent the FCF. I would appreciate it if 
> someone explains or provides the FCF format that RIOT-OS uses.
>
> Thank you,
> Ahed
>
> ___
> 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] IEEEE 802.15.4 FCF Format in "RIOT/sys/net/link_layer/ieee802154/ieee802154.c"

[Joakim Nohlgård]

I think you must have made a mistake in your calculations. buf[1] contains
bits 8-15 of the fcf, bits 12-13 are the version bits. 12 - 8 = 4, 1 << 4 =
0x10, so the frame version is set to version 1, all other bits are zero at
the beginning of that function.

Best regards, Joakim

Den tis 26 nov. 2019 22:59Aboodi Ahed Hussein Ali 
skrev:

> Hi all,
>
> I am having a hard time understanding how the "ieee802154_set_frame_hdr"
> function, found in this link
> ,
> sets the Frame Control Field (FCF) for 802.15.4 frame header.
> Following the IEEE 802.15.4 FCF format, frame version should be at the
> 12-13th bit of the 2-byte FCF, while in the function code, the frame
> version was set at the 11th bit. Does it uses different FCF format or am I
> missing something?
>
> This is the first part of the function:
>
> size_t ieee802154_set_frame_hdr(uint8_t *buf, const uint8_t *src, size_t
> src_len,
> const uint8_t *dst, size_t dst_len,
> le_uint16_t src_pan, le_uint16_t dst_pan,
> uint8_t flags, uint8_t seq)
> {
> int pos = 3;/* 0-1: FCS, 2: seq */
> uint8_t type = (flags & IEEE802154_FCF_TYPE_MASK);
>
> buf[0] = flags;
> buf[1] = IEEE802154_FCF_VERS_V1;  // IEEE802154_FCF_VERS_V1 is
> defined as *0x10*
>
> if (((src_len != 0) && (src == NULL)) ||
> ((dst_len != 0) && (dst == NULL))) {
> return 0;
> }
> ...
> ...
>
> The first two bytes of the *buf represent the FCF. I would appreciate it
> if someone explains or provides the FCF format that RIOT-OS uses.
>
> Thank you,
> Ahed
>
> ___
> 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] just got my Vega

[Joakim Nohlgård]

There is a tracking issue for porting at
https://github.com/RIOT-OS/RIOT/issues/10575

/Joakim

Den tis 12 feb. 2019 13:35 skrev Alexandre Abadie :

>
>
> - Le 12 Fév 19, à 13:15, Robert Hartung hart...@ibr.cs.tu-bs.de a
> écrit :
>
> > Sounds great - where did you order yours from?
>
> From [1], but they are out of stock now.
>
> Alex
>
> [1] https://open-isa.org/order/
>
>
> >
> > On 12.02.19 12:53, Kaspar Schleiser wrote:
> >> Hey fellow RIOT'ers,
> >>
> >> I've just received a VEGAboard (rv32m1-vega).
> >>
> >> It's feature list is very promising. On-board BLE/802.15.4, plenty of
> >> RAM and flash, (apparently) specs & reference manuals for everything.
> >> I'm curious how it's power consumption will be.
> >>
> >> I think it'll be a challenge integrating the thing properly. It has five
> >> cores with different instruction sets, four of them on the same bus, if
> >> I read the datasheet correctly. I'm also very looking forward to see
> >> messages floating between the cores! ;)
> >>
> >> Who's interested in collaborating on bringing RIOT onto the thing?
> >>
> >> Kaspar
> >>
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> >>
> >
> > --
> > 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
> ___
> 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] Function declaration isn't a prototype

[Joakim Nohlgård]

The obvious workaround is to turn off the warning via -Wno-strict-prototypes
The alternative is to fix the function declarations in the headers. IIRC
this is what shows up when you forget to put void inside the argument list
of a function which takes no arguments in C (it is not a warning in C++).

Best regards, Joakim

Den tors 7 feb. 2019 19:00 skrev Gunar Schorcht :

> Hi,
>
> what would be the right way, if there is one, to use vendor code without
> modifications in case of bunch of following error messages?
>
> "error: function declaration isn't a prototype [-Werror=strict-prototypes]"
>
> Regards
> Gunar
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
> ___
> 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] Eliminating casts

[Joakim Nohlgård]

A controversial idea is to change the implementation to C++ and make the
driver a proper class with inheritance and utilize polymorphism with
dynamic casts.

/Joakim

Den tor 27 dec. 2018 21:51 skrev Kees Bakker :

> On 27-12-18 13:54, Kaspar Schleiser wrote:
> > Hi,
> >
> > On 12/26/18 11:16 PM, Kees Bakker wrote:
> >> Suppose I make a Pull Request to eliminate casts, would that be picked
> up?
> > Always welcome! +1 on Joakim's hint to keep the PR's small.
> Sure
> >> void at86rf2xx_tx_exec(const at86rf2xx_t *dev)
> >> {
> >>  netdev_t *netdev = (netdev_t *)dev;
> > What would be the way to go here? 'netdev_t netdev = >netdev;'?
> Yes, please. It's already done in several drivers.
> > In this case, it won't work. Would need to recurse into
> > netdev_ieee802154_t, like 'netdev_t *netdev = >netdev.netdev;'.
> >
> > That might be less error.prone, but more confusing. Unfortunately C is
> > not much help here.
> Is it more confusing? I don't think so. Personally, I prefer the
> >netdev.netdev
> above the (netdev_t *)dev.
> >> Casts
> >> * Try to avoid casts (a bit vague, but it should get people's attention)
> >> * Introduce helper variables to avoid multiple casts within a function
> >> * Don't cast a const pointer into a non-const pointer without an
> >> explanation in a comment.
> >> * Don't cast a pointer to a volatile object dropping the volatile
> >> without an
> >> explanation in a comment.
> >> * ...
> > * use dereferenced superclass field instead of "blind" cast
> >
> > (the netdev case above).
> >
> > Kaspar
> > ___
> > 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] Compile-time peripheral configuration in board definitions

[Joakim Nohlgård]

Hi Gunar,
I have experimented with something similar, moving the configurations
to a .c file instead of periph_conf.h, but I came to the conclusion
that there are a number of drawbacks to the various alternatives.

First, let's clear up one thing regarding the current implementation:
The static const structs defined in periph_conf.h are garbage
collected in all modules where they are not directly used, so usually,
this means that it will only use ROM once (in the .rodata section of
the appropriate periph driver object). You can see this in the .map
file in the bin dir after building, there should only be one reference
to each configuration struct.
I don't know if using the _NUMOF macro constitutes as usage with
regards to linker GC, if the compiler is smart then the struct itself
should not be allocated when you only use sizeof(pwm_conf) but never
reference pwm_conf itself.

Putting the configuration struct in the periph driver implementation
file is equivalent to putting it in the header from the compiler point
of view when building the periph driver, so it should be possible to
perform the same optimizations as when the configuration is in
periph_conf.h, which is good.
Putting the configuration in the periph driver implementation will
place the configuration inside the CPU, which is bad for flexibility
and configurability. Unless you also define an initializer macro
somewhere in the board config, e.g. periph_conf.h, which is a bit more
inconvenient than the current approach due to multi line macros
needing to escape newlines etc.
One possible alternative solution is to create a periph_conf.c file in
the board directory, and use extern declarations in periph_conf.h just
like you proposed in order to let the drivers access the structs. The
drawback here is that the compiler will not be able to optimize away
execution paths which are not reachable using the current
configuration. On some implementations this will make no difference
but on others this will make the code a lot larger due to multiple
large branches which would normally be optimized away due to dead code
elimination in the compiler.
XFA would also have the same drawback as the periph_conf.c solution,
because the whole array is not visible to the compiler during
compilation of periph/abcd.c, so it can't fully perform DCE and other
optimizations.

Best regards,
Joakim

On Mon, Dec 17, 2018 at 4:14 PM Gunar Schorcht  wrote:
>
> Hi,
>
> I'm thinking about to revise the ESP32 board definitions and would need
> an advice from experienced core developers.
>
> Most (if not all) boards define their peripheral configuration of ADCs,
> DACs and PWMs in `periph_conf.h` in a kind of static const arrays and
> define macros based on the size of these arrays as follows:
>
> ```
> static const pwm_conf_t pwm_conf[] = {
> {
> .dev = MINI_TIMER0,
> .pin_ch = PWM_PINS_CH0,
> .div = MINI_TIMER0_DIV,
> },
> {
> .dev = MINI_TIMER2,
> .pin_ch = PWM_PINS_CH1,
> .div = MINI_TIMER2_DIV,
> }
> };
> #define PWM_NUMOF (sizeof(pwm_conf) / sizeof(pwm_conf[0]))
> ```
>
> Even though these static const arrays are allocated in the .rodata
> segment, they are allocated in each module that includes `board.h`. XFAs
> addresses this problem.
>
> For ESP32-Boards I tried another approach. In `periph_conf.h` there is
> only a declaration of an external const variable `pwm_dev_num` which
> contains the number of PWM devices and the macro `PWM_NUMOF` is then
> defined as follows:
>
> ```
> extern const unsigned pwm_dev_num;
> #define PWM_NUMOF   (pwm_dev_num)
> ```
>
> That's it. The complex configuration array of PWM is defined as static
> const array in the according .c file. The `prm_dev_num` variable is also
> defined there as usual:
> ```
> const unsigned pwm_dev_num = sizeof(_pwm_hw) / sizeof(_pwm_hw[0]);
> ```
>
> With this apporach, the pretty complex static configuration array
> `_pwm_hw[]` exists only once, the complexity of the configuration is
> hidden and the variable `pwm_dev_num` is also determin at compile time.
>
> The question I have is: should I change the board definitions according
> to the approach used by all other board definitions to be compatible
> with these board definitions, or can I leave them as they are?
>
> What would be your advice?
>
> Regards
> Gunar
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
> ___
> 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] Neighbor solicitations (NS) from border router (6lo ND)

[Joakim Nohlgård]

Hi Thomas,
Thank you for your answer. OK I think I understand what you mean, but
is this really the correct behavior?
It was certainly unexpected to me to have the packets go out the
default route instead of on the interface with the configured prefix.

I will try to elaborate:
I have a prefix 2001:db8::/64 configured for the wireless interface.
When I run ping6 2001:db8::1234 from the shell on the RIOT node, I
expect the system to first attempt to find 2001:db8::1234 on the
interface which has been configured for that prefix, instead of
immediately falling back and taking the default route when the
destination does not already exist in the NIB neighbor table.

/Joakim

On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt
 wrote:
>
> Hi Joakim,
>
> it appears that you are experimenting with a special case.
>
> Normally, a sending node decides on the outgoing interface based on the
> destination IP prefix. If you don't have a more specific routing entry,
> the default IF is correctly chosen in your case.
>
> After the interface is selected, the source needs to decide on the
> Layer2 framing. Most link-layer technologies use an addressing
> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your
> case, you mention SLIP. A serial line interface does not use L2
> addresses and does not need ND.
>
> Best,
>   Thomas
>
> On 17/12/2018 08:59, Joakim Nohlgård wrote:
> > Hi developers,
> > When using the shell on the gnrc_border_router application trying to
> > send to an unknown address with its designated prefix, the application
> > does not send any neighbor solicitations on the wireless network.
> > When I type ping6 2001:db8::1234 I expected that a neighbor
> > solicitation query to go out on the interface that has been configured
> > with the routing destination for 2001:db8::/64, but wireshark shows
> > that nothing is sent on the wireless, but instead the ICMPv6 packet is
> > sent immediately over the slip/ethos interface, which is configured as
> > the default route.
> >
> > Is this behavior correct or is this a routing bug?
> >
> > Configurations:
> >> ifconfig
> > Iface  6  HWaddr: 02:DA:F1:03:BC:48
> >MTU:1500  HL:64  RTR
> >RTR_ADV  Source address length: 6
> >Link type: wired
> >inet6 addr: fe80::da:f1ff:fe03:bc48  scope: local  TNT[1]
> >inet6 addr: fe80::2  scope: local  VAL
> >inet6 group: ff02::2
> >inet6 group: ff02::1
> >inet6 group: ff02::1:ff03:bc48
> >inet6 group: ff02::1:ff00:2
> >
> > Iface  7  Channel: 26  Page: 0  NID: 0x23
> >Long HWaddr: 23:31:53:29:36:B7:6E:5A
> > TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4
> >ACK_REQ  CSMA  MTU:1280  HL:64  RTR
> >RTR_ADV  IPHC
> >Source address length: 8
> >Link type: wireless
> >inet6 addr: fe80::2131:5329:36b7:6e5a  scope: local  VAL
> >inet6 addr: 2001:db8::2131:5329:36b7:6e5a  scope: global  VAL
> >inet6 group: ff02::2
> >inet6 group: ff02::1
> >inet6 group: ff02::1:ffb7:6e5a
> > routing:
> >> nib route
> > 2001:db8::/64 dev #7
> > default* via fe80::1 dev #6
> >
> > Best regards,
> > Joakim
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> >
>
> --
>
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences  Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
> ° http://inet.haw-hamburg.de/members/schmidt  Fon: +49-40-42875-8452 °
>
> ___
> 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] Neighbor solicitations (NS) from border router (6lo ND)

[Joakim Nohlgård]

Hi developers,
When using the shell on the gnrc_border_router application trying to
send to an unknown address with its designated prefix, the application
does not send any neighbor solicitations on the wireless network.
When I type ping6 2001:db8::1234 I expected that a neighbor
solicitation query to go out on the interface that has been configured
with the routing destination for 2001:db8::/64, but wireshark shows
that nothing is sent on the wireless, but instead the ICMPv6 packet is
sent immediately over the slip/ethos interface, which is configured as
the default route.

Is this behavior correct or is this a routing bug?

Configurations:
> ifconfig
Iface  6  HWaddr: 02:DA:F1:03:BC:48
  MTU:1500  HL:64  RTR
  RTR_ADV  Source address length: 6
  Link type: wired
  inet6 addr: fe80::da:f1ff:fe03:bc48  scope: local  TNT[1]
  inet6 addr: fe80::2  scope: local  VAL
  inet6 group: ff02::2
  inet6 group: ff02::1
  inet6 group: ff02::1:ff03:bc48
  inet6 group: ff02::1:ff00:2

Iface  7  Channel: 26  Page: 0  NID: 0x23
  Long HWaddr: 23:31:53:29:36:B7:6E:5A
   TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4
  ACK_REQ  CSMA  MTU:1280  HL:64  RTR
  RTR_ADV  IPHC
  Source address length: 8
  Link type: wireless
  inet6 addr: fe80::2131:5329:36b7:6e5a  scope: local  VAL
  inet6 addr: 2001:db8::2131:5329:36b7:6e5a  scope: global  VAL
  inet6 group: ff02::2
  inet6 group: ff02::1
  inet6 group: ff02::1:ffb7:6e5a
routing:
> nib route
2001:db8::/64 dev #7
default* via fe80::1 dev #6

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

Re: [riot-devel] Hello world stopped working

[Joakim Nohlgård]

Hi,
I don't believe that we require GCC 7 anywhere, it should still work
fine to build with for example the ARM provided GCC 6 release, or the
older Ubuntu/Debian toolchains. It seemed more like there is a problem
with the Ubuntu packaged arm-none-eabi toolchain that produces broken
binaries.

/Joakim

On Wed, Dec 5, 2018 at 10:05 PM Kees Bakker  wrote:
>
> Hey Alex,
>
> Thanks, that did the trick. Wow, what happened with that compiler?
> I now see that we have PR #10404 and a few issues about it. Hmm,
> that PR could have given me a warning.
> -- Kees
>
> On 05-12-18 21:20, Alexandre Abadie wrote:
> > Hi Kees,
> >
> > You need a more recent version of the GNU ARM compiler, 7.x, and you only 
> > have 6.3. The recommended toolchain is the official one from ARM that can 
> > be downloaded at [1].
> >
> > Just uncompress the archive somewhere in your filesystem (in /opt for 
> > example) and update your PATH variable. This is what I do and it works well.
> >
> > Cheers!
> >
> > Alex
> >
> > [1] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
> >
> > - Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit :
> >
> >> Hi,
> >>
> >> This may sound like a stupid question, but I can't get output
> >> from hello world anymore. On my Sodaq Explorer and also on my
> >> Sodaq One.
> >>
> >> I have been away from RIOT for a few weeks and now that I get back
> >> there is no output on UART0, and the LEDs don't work either.
> >>
> >> Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler.
> >> Could that be it?
> >>
> >> binutils-arm-none-eabi  2.27-9ubuntu1+9
> >> gcc-arm-none-eabi  15:6.3.1+svn253039-1build1
> >> gdb-arm-none-eabi  7.10-1ubuntu3+9
> >> libnewlib-arm-none-eabi  2.4.0.20160527-3
> >> libstdc++-arm-none-eabi-newlib  15:6.3.1+svn253039-1+10
> >>
> >> If not, what else could it be? It must be something obvious, but
> >> so far I haven't found it.
> >> --
> >> Kees
> >> ___
> >> 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] EFM32 timers, PWM and xtimer

[Joakim Nohlgård]

Hi Christian,
If you want some inspiration for a timer driver you could take a look
at the Kinetis periph/timer driver which wraps two different timer
hardware modules underneath, one for high frequency and precise
control (PIT, always clocked by the CPU bus clock), and the other for
low power consumption and lower frequency (LPTMR, usually clocked by
the RTC oscillator, but there are other options as well).
Additionally, PR#7897 adds pm_layered management inside the timer
driver for the PIT to prevent low power modes from disrupting a timer
when there is a target set.

https://github.com/RIOT-OS/RIOT/blob/master/cpu/kinetis/periph/timer.c
https://github.com/RIOT-OS/RIOT/pull/7897/files

/Joakim

On Mon, Nov 12, 2018 at 7:29 PM chrysn  wrote:
>
> Hi Bas,
>
> thanks for your quick response!
>
> On Mon, Nov 12, 2018 at 05:54:09PM +0100, Bas Stottelaar wrote:
> > The newer chips have an additional 32-bit timer with the same problem, but
> > this frees up timers for PWM.
>
> That unfortunately won't help with the hardware I have here right now :-/
>
> > The two timers are needed, because they run in cascade mode. Only that way,
> > I can generate values for XTIMER_HZ that have sufficient resolution.
>
> As I understand, the timer that serves XTIMER needs to be precise 1MHz,
> and may be up to 6 shifts away from it -- but there is also the option
> of running it from a 32768Hz clock available as internal and often
> external clock. That seems to be sufficient xtimer resolution for some
> applications (it certainly is for mine).
>
> Options are a bit limited as to how to implement such a clock without
> moving the whole device on the low frequency clock (HFPERCLK TIMERn can
> only be clocked from LFxO if all HF stuff actually uses that in
> HFCLKSEL), but the LETIMER0 (or RTC, but LETIMER is unused) would be an
> option here (provided LFACLK comes from an LFxO).
>
> If LETIMER support were to be added, it could probably look similar to
> the changes in [1] -- but would need to branch out in timer_init, and
> (when it's a LETIMER) err out if the desired frequency is not 32768.
>
> Christian
>
> [1]: https://github.com/RIOT-OS/RIOT/pull/9878/files
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>   -- Bene Gesserit axiom
> ___
> 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] Compute the time elapsed when switching between two threads

[Joakim Nohlgård]

Would you be able to get the measurements you are looking for using this
approach instead?
The low priority thread is toggling a gpio pin in a tight loop. The other
thread toggles a different pin as soon as it is resumed. You would need
external equipment to get the time between the two, but it should give a
fairly accurate measurement for a single context switch.
/Joakim

Den tor 15 nov. 2018 17:49 skrev Julien Gomez <
julien.go...@student.uclouvain.be>:

> Hi Gaëtan,
>
> Thank you for your answer!
>
> I did look at this test and it counts the number of context switches
> between two threads of the same priority in one second.
>
> What I want is something more abstract (any thread, any priority). To
> reformulate my question, let's assume I have two threads. It doesn't matter
> what they are doing. One of the threads will be interrupted by the other
> and a context switch will occur. *What I want to know is how much time is
> spent in the context switching.*
>
> I don't think this is possible at the application-level.
>
> Regards,
> Julien
> --
> *De :* Gaëtan Harter 
> *Envoyé :* jeudi 15 novembre 2018 17:28:16
> *À :* devel@riot-os.org; Julien Gomez
> *Objet :* Re: [riot-devel] Compute the time elapsed when switching
> between two threads
>
> Hi Julien,
>
> I think this test should be doing what you want, I did not look at it
> just knew it existed.
>
>
>
> https://github.com/RIOT-OS/RIOT/tree/master/test/bench_thread_yield_pingpong
>
>
>
> Regards,
> Gaëtan - cladmi
>
> On 15.11.18 16:41, Julien Gomez wrote:
> > Hello fellow developers !
> >
> > I have a simple question: How one could compute the time elapsed when
> switching from thread A to thread B?
> >
> > Any advice or lead is welcome!
> >
> > Regards,
> > Julien
> >
> >
> > ___
> > 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] Lifting the 50 characters commit first line limit?

[Joakim Nohlgård]

+1 what Martine wrote.

(I was composing a similar message when you beat me to it)
/Joakim

Den ons 10 okt. 2018 08:51Martine Lenders  skrev:

> Hi Pekka,
>
> the 50 chars is just the warning bound. You can go up to 70 until the
> commit message check fails on you. Longer will make GitHub break the commit
> message in the webview with the dreaded […] ;-).
>
> My usual approach is to boil down the summary to the bare minimum within
> these constraints (even using just the module name instead of the full
> path) and go into details in the following lines of the commit message.
>
> Regards,
> Martine
>
> Am Mi., 10. Okt. 2018 um 08:06 Uhr schrieb Nikander Pekka <
> pekka.nikan...@aalto.fi>:
>
>> [Refactoring the nRF520 mega-PR to follow the standards...]
>>
>> I guess this has been bashed to death, but I am annoyed.
>>
>> With long paths, the 50 characters limit on the first line
>> of the commit message makes it impossible to have any meaningful
>> explanation of what the commit actually does.  Actually,
>> the limitation makes the commit messages unintelligible.
>>
>> _Any_ change of increasing the limit to e.g. 72 characters?
>>
>> --Pekka
>>
>> ___
>> 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] Current best practice for sleeping in a device driver?

[Joakim Nohlgård]

Hi again,
Are you on a cortex m platform? Did you remember to add cortexm_isr_end()
at the end of the ISR function?
/Joakim

Den tis 11 sep. 2018 20:21Nikander Pekka  skrev:

> Hi Joakim,
>
> I tried also exactly that, but for some reason I couldn't make it work.
> When I tried to unlock it in the ISR, the thread waiting for the mutex for
> the second time still didn't acquire it, but was blocked again in the
> scheduler.  I didn't dive deep into the scheduler to see why.  Maybe I did
> some mistake.
>
> Could you please point to some example code?
>
> --Pekka
>
> On 11.9.2018, at 20:48, Joakim Nohlgård  wrote:
>
> Hi Pekka,
> What we have done in several other places is to use a mutex. The device
> driver blocking code will attempt to lock the mutex twice, and the ISR will
> unlock it to let the thread continue.
> Does that work in your use case?
>
> Best regards, Joakim
>
> Den tis 11 sep. 2018 16:40Nikander Pekka  skrev:
>
>> Hi,
>>
>> Sorry for my ignorance, but what is the current best practice to sleep in
>> a blocking device driver, waiting for an interrupt to take place?  I
>> couldn't find anything reasonable.
>>
>> In many other context I've seen people to use `sleep` and `wakeup`, and
>> even went that far that I tried to introduce a variant of `thread_sleep`
>> that can be entered with interrupts disabled (see below), but couldn't get
>> it working.
>>
>> Here is an excerpt of my current code:
>> ```
>> void isr_saadc(void) {
>> NRF_SAADC->EVENTS_END = 0;
>> NRF_SAADC->INTENCLR = SAADC_INTEN_DONE_Msk;
>> thread_wakeup(sleeper);
>> }
>>
>> int adc_sample(adc_t line, adc_res_t res)
>> {
>> ...
>> /* enable EVENTS_END interrupt */
>> const uint32_t irqs = irq_disable();
>> sleeper = thread_getpid();
>> NRF_SAADC->INTENSET = SAADC_INTEN_END_Msk; /* Disabled at ISR handler
>> */
>>
>> ...
>>
>> /* Wait for the interrupt */
>> thread_sleep_with_interrupts_disabled(irqs);
>> ```
>>
>> This doesn't work.  The thread doesn't wake up, even though the interrupt
>> does take place and `thread_wakeup` states that the thread _is_ sleeping
>> when called:
>> ```
>> Created thread idle. PID: 1. Priority: 15.
>> Created thread main. PID: 2. Priority: 7.
>> main(): This is RIOT! (Version:
>> 2018.10-devel-585-gd2de4-dhcp-85-86.eduroam.aalto.fi
>> -feature-refactor-ble-core)
>> Entering main function.
>> Entering main loop.
>> thread_wakeup: Trying to wakeup PID 2...
>> thread_wakeup: Thread is sleeping.
>> thread_wakeup: Trying to wakeup PID 2...
>> thread_wakeup: Thread is sleeping.
>> ```
>>
>> And then nothing happens.
>>
>> Here is the tentative patch to introduce
>> `thread_sleep_with_interrupts_disabled`:
>> ```
>> diff --git a/core/include/thread.h b/core/include/thread.h
>> index 64a828ab3..4abdb3d25 100644
>> --- a/core/include/thread.h
>> +++ b/core/include/thread.h
>> @@ -399,6 +399,20 @@ int thread_getstatus(kernel_pid_t pid);
>>   */
>>  void thread_sleep(void);
>>
>> +/**
>> + * @brief Puts the current thread into sleep mode with the interrupts
>> already disabled.
>> + *
>> + * @param[in] interrupt_state  Saved interrupt state from irq_disable().
>> + *
>> + *  Places the calling thread to sleep and re-enables interrupts
>> to
>> + *  the `interrupt_state` before calling thread_yield_higher().
>> + *  Meant to be called from drivers that want to be waken up
>> + *  from an interrupt routine.
>> + *  The calling thread to be woken up externally.
>> + *
>> + */
>> +void thread_sleep_with_interrupts_disabled(int interrupt_state);
>> +
>>  /**
>>   * @brief   Lets current thread yield.
>>   *
>> diff --git a/core/thread.c b/core/thread.c
>> index 6f7a71362..05400a0af 100644
>> --- a/core/thread.c
>> +++ b/core/thread.c
>> @@ -62,9 +62,12 @@ void thread_sleep(void)
>>  }
>>
>>  unsigned state = irq_disable();
>> +thread_sleep_with_interrupts_disabled(state);
>> +}
>> +
>> +void thread_sleep_with_interrupts_disabled(int state) {
>>  sched_set_status((thread_t *)sched_active_thread, STATUS_SLEEPING);
>>  irq_restore(state);
>>  thread_yield_higher();
>>  }
>>
>>  int thread_wakeup(kernel_pid_t pid)
>>
>> ```
>>
>> --Pekka Nikander
>>
>> ___
>> 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] Current best practice for sleeping in a device driver?

[Joakim Nohlgård]

Hi Pekka,
What we have done in several other places is to use a mutex. The device
driver blocking code will attempt to lock the mutex twice, and the ISR will
unlock it to let the thread continue.
Does that work in your use case?

Best regards, Joakim

Den tis 11 sep. 2018 16:40Nikander Pekka  skrev:

> Hi,
>
> Sorry for my ignorance, but what is the current best practice to sleep in
> a blocking device driver, waiting for an interrupt to take place?  I
> couldn't find anything reasonable.
>
> In many other context I've seen people to use `sleep` and `wakeup`, and
> even went that far that I tried to introduce a variant of `thread_sleep`
> that can be entered with interrupts disabled (see below), but couldn't get
> it working.
>
> Here is an excerpt of my current code:
> ```
> void isr_saadc(void) {
> NRF_SAADC->EVENTS_END = 0;
> NRF_SAADC->INTENCLR = SAADC_INTEN_DONE_Msk;
> thread_wakeup(sleeper);
> }
>
> int adc_sample(adc_t line, adc_res_t res)
> {
> ...
> /* enable EVENTS_END interrupt */
> const uint32_t irqs = irq_disable();
> sleeper = thread_getpid();
> NRF_SAADC->INTENSET = SAADC_INTEN_END_Msk; /* Disabled at ISR handler
> */
>
> ...
>
> /* Wait for the interrupt */
> thread_sleep_with_interrupts_disabled(irqs);
> ```
>
> This doesn't work.  The thread doesn't wake up, even though the interrupt
> does take place and `thread_wakeup` states that the thread _is_ sleeping
> when called:
> ```
> Created thread idle. PID: 1. Priority: 15.
> Created thread main. PID: 2. Priority: 7.
> main(): This is RIOT! (Version:
> 2018.10-devel-585-gd2de4-dhcp-85-86.eduroam.aalto.fi-feature-refactor-ble-core)
> Entering main function.
> Entering main loop.
> thread_wakeup: Trying to wakeup PID 2...
> thread_wakeup: Thread is sleeping.
> thread_wakeup: Trying to wakeup PID 2...
> thread_wakeup: Thread is sleeping.
> ```
>
> And then nothing happens.
>
> Here is the tentative patch to introduce
> `thread_sleep_with_interrupts_disabled`:
> ```
> diff --git a/core/include/thread.h b/core/include/thread.h
> index 64a828ab3..4abdb3d25 100644
> --- a/core/include/thread.h
> +++ b/core/include/thread.h
> @@ -399,6 +399,20 @@ int thread_getstatus(kernel_pid_t pid);
>   */
>  void thread_sleep(void);
>
> +/**
> + * @brief Puts the current thread into sleep mode with the interrupts
> already disabled.
> + *
> + * @param[in] interrupt_state  Saved interrupt state from irq_disable().
> + *
> + *  Places the calling thread to sleep and re-enables interrupts
> to
> + *  the `interrupt_state` before calling thread_yield_higher().
> + *  Meant to be called from drivers that want to be waken up
> + *  from an interrupt routine.
> + *  The calling thread to be woken up externally.
> + *
> + */
> +void thread_sleep_with_interrupts_disabled(int interrupt_state);
> +
>  /**
>   * @brief   Lets current thread yield.
>   *
> diff --git a/core/thread.c b/core/thread.c
> index 6f7a71362..05400a0af 100644
> --- a/core/thread.c
> +++ b/core/thread.c
> @@ -62,9 +62,12 @@ void thread_sleep(void)
>  }
>
>  unsigned state = irq_disable();
> +thread_sleep_with_interrupts_disabled(state);
> +}
> +
> +void thread_sleep_with_interrupts_disabled(int state) {
>  sched_set_status((thread_t *)sched_active_thread, STATUS_SLEEPING);
>  irq_restore(state);
>  thread_yield_higher();
>  }
>
>  int thread_wakeup(kernel_pid_t pid)
>
> ```
>
> --Pekka Nikander
>
> ___
> 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] Activation of modules by make command line

[Joakim Nohlgård]

It should be possible in the current state if you give the modules as an
environment variable instead of on the command line. So:

USEMODULE='module_a module_b' make BOARD=asdf

/Joakim

Den tor 6 sep. 2018 10:33Gunar Schorcht  skrev:

> Hi,
>
> It is often necessary to enable or disable various functions at
> compilation time, for example, to test dependencies. In RIOT, features
> are activated using the module concept:
>
> USEMODULE + = feature
>
> I'm wondering whether there is a possibility to enable modules without
> changing the makefile when the make command is called, for example:
>
> make BOARD=... USE_MODULES="sdcard_spi mrf24j40"
>
> I was looking through the documentation and the makefile structure for
> something like
>
> USEMODULE += $(USE_MODULES)
>
> Did I miss something? If it is not possible, would it be worth to
> realize it?
>
> Regards
> Gunar
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
> ___
> 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] Where to put board pictures?

[Joakim Nohlgård]

Hi all,
Ideally, the pictures and figures should be part of the pull request
to add the board configuration, to make reviewing easier for
maintainers. Having the maintainers to upload the pictures manually of
a proposed board is too much extra administration and will steal
maintainer focus from other areas. I have no experience with git-lfs,
but maybe someone on this list can answer: Does git-lfs let the
contributor include the pictures and other git-lfs blobs as part of a
Github pull request?

/Joakim

On Tue, Sep 4, 2018 at 11:36 AM, Gunar Schorcht  wrote:
> Hi Juan,
>
> every approach which is not bloating a git repository is surely the best
> one. IMHO, it is important that the approach gives the board developer
> the possibility to upload/update pictures without involving maintainers.
>
> Would it also be possible with git-lfs to give the board developers
> access rights to upload pictures?
>
> Regards
> Gunar
>
> On 04.09.2018 10:41, Juan Ignacio Carrano wrote:
>> Gunar, Jose
>>
>>  >
>>  > In the end, it should not matter which git repository is bloated.
>>  >
>>
>> What about NO repository gets bloated?
>> This was already discussed with some other maintainers offline, but I
>> want to reinstate it here:
>>
>> We are not *special* in any way. Compared to other projects, RIOT OS
>> does not have any crazy wacky requirements or limitations, and we are
>> facing similar issues, for which- after similar sufferings- specialized
>> tools were developed. Then why do we insist in doing things differently?
>>
>> I'm talking about git-lfs. This tools was invented to overcome all those
>> issues we are mentioning in this thread. To me it is the only non-hacky
>> solution. The only time a user will be exposed to the tool will be when
>> building/editing the docs.
>>
>> git-lfs does not bloat the repo because binary blobs are not stored in
>> there, and only the needed versions for the commits you are checking out
>> are downloaded (not the entire diff history as with a regular text file.)
>>
>> Really, all this wiki-as-object-storage thing feels like hammering a
>> nail with a screwdriver. If we go with the hacky solution we will regret
>> it later when we have to maintain the mess.
>>
>> Regards,
>>
>> Juan.
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
>
> ___
> 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] [riot-users] End of I2C embargo

[Joakim Nohlgård]

Good job, everyone involved!
/Joakim

Den tor 2 aug. 2018 12:49Dylan Laduranty  skrev:

> Dear RIOTers,
>
> The I2C rework is now merged into RIOT's master branch, then I am really
> happy to announce you the end of the I2C embargo ! Don't hesitate to ping
> pending PRs that were blocked by this embargo so maintainers can have a
> look at it.
>
> This rework will not be present in the 2018.07 release as we lack of time
> to get things merged, but you can use the master branch if you want to use
> it.
>
> We also create a wiki page [1] to summarize the changes introduced by this
> rework. We will keep working to improve this documentation.
>
> Of course, we cannot guarantee that the new I2C interface is completely
> bug-free. So if you encounter any errors, weird behaviour or if you have
> any questions, don't hesitate to send an email to the mailing list or
> create an issue on Github. We will continue to improve our work.
>
> Finally, I would like to deeply thanks every people involved in this huge
> rework, thank you for your time and your hard will. I'm really proud of
> what we have done here ! You guys are amazing :)
>
> Keep RIOTing !
>
> [1] https://github.com/RIOT-OS/RIOT/wiki/I2C-rework
>
> --
> Dylan Laduranty
> ___
> users mailing list
> us...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/users
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] PIC programmer with Linux support?

[Joakim Nohlgård]

Is this for pic32 HIL tests?
Do the pic32 boards support jtag like the cortex boards? In that case you
could maybe use one of the ftdi ft2232 based jtag programmers out there.

/Joakim

On Fri, May 18, 2018, 10:30 Kaspar Schleiser  wrote:

> Hey fellow RIOTers,
>
> I'm looking for a readily available PIC programmer with Linux support.
>
> Main requirements are:
>
>
> - can flash the boards that RIOT supports
> - has a CLI application that runs on Linux (both x86 and ARM/RasPi)
> (- not too expensive)
>
> Any suggestions?
>
> Kaspar
> ___
> 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] Dropping FEATURES_MCU_GROUP?

[Joakim Nohlgård]

We used Drone at Eistec before when I added it, but not using it anymore
since Murdock solves many of the problems that we had with Travis.

/Joakim

On Wed, Apr 25, 2018, 09:31 smlng <s...@mlng.net> wrote:

> Hi all,
>
> FYI: they are referenced in the Drone-CI config (drone.yml), don't know if
> anybody
> uses that?
>
> Best,
>   Sebastian
>
> > On 25. Apr 2018, at 09:28, Bas Stottelaar <basstottel...@gmail.com>
> wrote:
> >
> > +1 if it's not used.
> >
> > Kind regards,
> >
> > Bas Stottelaar
> >
> >
> > 2018-04-24 7:02 GMT+02:00 Joakim Nohlgård <joakim.nohlg...@eistec.se>:
> > Hi developers,
> > Is the old FEATURES_MCU_GROUP variable used by tools anymore?
> > AFAIK Murdock tracks build status per board/app tuple, without
> > grouping by families or anything.
> > It might be time to drop it from the board configurations to avoid
> > confusing newcomers.
> >
> > Best regards,
> > Joakim
> > ___
> > 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

[riot-devel] Dropping FEATURES_MCU_GROUP?

[Joakim Nohlgård]

Hi developers,
Is the old FEATURES_MCU_GROUP variable used by tools anymore?
AFAIK Murdock tracks build status per board/app tuple, without
grouping by families or anything.
It might be time to drop it from the board configurations to avoid
confusing newcomers.

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

Re: [riot-devel] xtimer race condition

[Joakim Nohlgård]

Hi Matthew,
My guess is that you are running that function with interrupts
disabled, which blocks the xtimer timeouts. The reason that short
sleeps work in xtimer is that internally that is handled as a spin,
while longer timeouts are handled by setting a hardware timer target.
You can try using xtimer_spin instead of usleep, but chances are your
PR will not be merged if you are using xtimer_spin with long timeouts.
xtimer_spin is a busy wait which should be used only for very short
periods, since it will be obstructing other parts of the system from
running while you are spinning.

Best regards,
Joakim

On Sat, Mar 31, 2018 at 8:36 AM, Matthew Blue
 wrote:
> Hello all,
>
> I have had some odd problems with a PR I am attempting to finalize:
>
> cpu/atmega_common: RTT and RTC support
> https://github.com/RIOT-OS/RIOT/pull/8842
>
> When working with the real-time timers, there are a number of times that
> you have to wait a few of the slow clock cycles to go by. I am using
> xtimer_usleep to sleep the thread temporarily. But! xtimer causes the
> code I am using to hang. Debugging it is difficult, because anything
> sending debug messages over UART causes the problems to disappear!
>
> I have been editing and running various numbers:
> xtimer_usleep(8); 8 and bigger fail
> xtimer_usleep(7); 7 and smaller work
>
> Bigger numbers make them fail!
>
> Here is a snippet of the offending code:
>
>> void __asynch_wait(uint8_t num_cycles) {
>> /* Wait until all busy flags clear */
>> while( ASSR & ((1 << TCN2UB) | (1 << OCR2AUB) | (1 << OCR2BUB)
>>  | (1 << TCR2AUB) | (1 << TCR2BUB)) ) {
>> #ifdef MODULE_XTIMER
>> /* Sleep for num_cycles RTC cycles */
>> xtimer_usleep(num_cycles * 35 * US_PER_MS);
>> #else
>> /* Suppress unused parameter warning */
>> (void)num_cycles;
>>
>> thread_yield();
>> #endif
>> }
>> }
>
> Anyone have any ideas on what is going on?
>
> Sincerely,
> Matthew
> ___
> 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] RIOT policy on hardware support without example board

[Joakim Nohlgård]

Hi again,

Is there no readily available commercial dev boards which feature an
RTC crystal? Generally, boards in the main repo have to be available
commercially or at least accessible for a large number of users
(IoT-lab boards for example are only available in the IoT-lab test
sites, but they are open to the public). I don't think your custom dev
board will be accepted unless you are selling it, at least in small
volumes, so that other users may benefit from the board config. It may
be easier to just find some pre-made dev board which have similar
peripheral set up and add a configuration for that to be able to add
the CPU.

/Joakim

On Thu, Mar 15, 2018 at 4:55 PM, Matthew Blue
<matthew.blue.ne...@gmail.com> wrote:
> Hello Joakim,
>
> I do have such a board: the board I am developing for. I also already
> have it ported and passing many of the manual tests. However, my concern
> is that I do not anticipate this board being generally available,
> because of the kind of product it is going to be in. Is it okay for me
> to be the only developer with access to a board in the main repository?
> I assumed that others would wish everything in /boards to be generally
> available. However, adding it to the main repository would allow the CI
> system to run automated tests against its peripherals.
>
> There are other boards using the same MCU, but they do not have the
> peripherals that my board has. For instance, I have almost finished RTT
> support for the ATMegas, but none of the Arduinos breaks out the pins
> that would allow you to add a 32kHz crystal.
>
> Sincerely,
> Matthew
>
>
> On Thu, 15 Mar 2018 09:20:37 +0100
> Joakim Nohlgård <joakim.nohlg...@eistec.se> wrote:
>
>> Hi Matthew,
>> Generally, everything in the main repository should be covered by the
>> automatic compilation tests performed by the CI system, which is why
>> all CPUs must have at least one board using them. Perhaps you have
>> some development board which uses the same CPU that you can add a
>> basic configuration for? A board configuration can be quite simple if
>> you only need the basic features, and should not take a lot of effort
>> to produce. Maybe there is an Arduino board or similar which uses the
>> same CPU?
>> The drivers for TCA9539 and ADS1015 can be integrated in the main repo
>> as long as there is a simple test program for them so that they are
>> built by the CI, and so that they can be tested on actual hardware
>> with only adding the pin/bus configuration for the experiment setup.
>> See the existing tests for some drivers in the main repo e.g.
>> tests/driver_ina220
>>
>> Best regards,
>> Joakim
>>
>> On Wed, Mar 14, 2018 at 6:49 PM, Matthew Blue
>> <matthew.blue.ne...@gmail.com> wrote:
>> > Hello all,
>> >
>> > I am building mesh networking sensor arrays for agriculture, and I
>> > am working on RIOT as an operating system for them. I have a number
>> > of bits of hardware that I need to write support for and I would
>> > like to contribute that back to RIOT. However, since this is ag
>> > equipment designed to be deployed in large quantities, I expect
>> > that it will not really be available for developers other than
>> > myself to test on.
>> >
>> > What is the RIOT community's policy on submitting support for things
>> > like CPUs and peripherals without a board implementing them? I
>> > intend to support what I contribute into the foreseeable future. I
>> > suspect that having hardware already supported will influence
>> > future board designs if they are intended to run a system like RIOT
>> > (it influenced some of my design choices).
>> >
>> > Some of the specific bits I intend to add are the ATmega1284P MCU,
>> > the TCA9539 I2C GPI expander, and the ADS1015 ADC (and variants).
>> >
>> > Sincerely,
>> > Matthew
>> > ___
>> > 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] RIOT policy on hardware support without example board

[Joakim Nohlgård]

Hi Matthew,
Generally, everything in the main repository should be covered by the
automatic compilation tests performed by the CI system, which is why
all CPUs must have at least one board using them. Perhaps you have
some development board which uses the same CPU that you can add a
basic configuration for? A board configuration can be quite simple if
you only need the basic features, and should not take a lot of effort
to produce. Maybe there is an Arduino board or similar which uses the
same CPU?
The drivers for TCA9539 and ADS1015 can be integrated in the main repo
as long as there is a simple test program for them so that they are
built by the CI, and so that they can be tested on actual hardware
with only adding the pin/bus configuration for the experiment setup.
See the existing tests for some drivers in the main repo e.g.
tests/driver_ina220

Best regards,
Joakim

On Wed, Mar 14, 2018 at 6:49 PM, Matthew Blue
 wrote:
> Hello all,
>
> I am building mesh networking sensor arrays for agriculture, and I am
> working on RIOT as an operating system for them. I have a number of
> bits of hardware that I need to write support for and I would like to
> contribute that back to RIOT. However, since this is ag equipment
> designed to be deployed in large quantities, I expect that it will not
> really be available for developers other than myself to test on.
>
> What is the RIOT community's policy on submitting support for things
> like CPUs and peripherals without a board implementing them? I intend to
> support what I contribute into the foreseeable future. I suspect that
> having hardware already supported will influence future board designs
> if they are intended to run a system like RIOT (it influenced some of
> my design choices).
>
> Some of the specific bits I intend to add are the ATmega1284P MCU, the
> TCA9539 I2C GPI expander, and the ADS1015 ADC (and variants).
>
> Sincerely,
> Matthew
> ___
> 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] Improve Documentation

[Joakim Nohlgård]

I think this is certainly an interesting idea! You will probably not even
need Doxygen for anything, plain graphviz (dot) is probably enough.

Best regards, Joakim

On Mar 1, 2018 16:21, "Arndt, Josua"  wrote:

Hello all,



as we are working on the PR to bring the Jiminy board to mainline repo I
had some problems to find where what is, or should be.

So I had the idea that a graph would help me visualize where which module
is implemented.



Something like this.





My idea was to maybe add a feature which uses doxygen to compile dot graphs
for a test/application and board.



So when executing “make doc board=Bordname” in the folder test_spi then
graphs for this project and board are created.

Maybe include graphs or such a Module, feature defines graph.



This would make it possible to just generate one graph for a test and add
this to the depending readme or wiki page.

When implementing you could fastly grasp which feature are necessary and
where they should be.



Also a comparison of the different cpu and boards could be done.

But for me the most important improvement would be I could build this for a
board and fastly grasp where which feature is implemented.





This would also help newcomers to get a fast overview  of what is where.



Is there interest for such a feature? Does any one have an idea of how to
best implement this?
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Porting RIOT to 8051 Architecture

[Joakim Nohlgård]

Hi Madison,
I haven't used any 8051 architecture devices myself, but I think the
biggest difficulties will probably be getting everything to compile with a
new toolchain which is not gcc based (we have support for clang as well,
but the clang developers work hard to be gcc compatible). Like you wrote,
the context switching will likely need to be written in assembly, but those
functions should be pretty easy to implement for someone with experience in
8051 assembly.
Also you will need to make sure that the cpu_init function sets up stack
pointer, clock configuration, and interrupts. I don't know about the c51
compiler, but you might have to work with some linker configuration
(ldscripts or whatever the linker for the 8051 uses) to make sure that all
functions and variables are placed correctly in ROM and RAM.
I suggest you examine the avr and cortexm CPU initialization and context
switch code to see what you will need to implement for the 8051
architecture, especially read all the code comments as well, these parts
are described what they are expected to do, at least in the cortex
implementation.
You will also need to implement all the peripheral drivers that you want to
use, such as uart and gpio. You will likely need to implement some glue
layer between uart_stdio and the C51 libc if you want to be able to use
printf etc. If the toolchain uses newlib, then everything should be good to
go, but other libc implementations will probably need some small
adaptation. Look at the avr port for an example of how to use some other
libc than newlib.

Good luck on your port,
Joakim


On Feb 5, 2018 19:42, "Madison McCarthy" 
wrote:

Hello Everyone,

I am considering porting RIOT for a device that uses the 8051 architecture
(Si1062 using the  C8051F930). Issue #1587 briefly talked about a 8051 port
but ended with no result.

My question is has anyone attempted porting RIOT for an 8051 controller
successfully? How much effort roughly would this task take for a novice?

I have already ported RIOT for the TI LTS compiler and the armcc compiler,
and completed rudimentary ports for an EZR32, CC1310 and ATxmega.

My two issues would be with:

1) thread_arch.c -> the assembly for context_switches would be challenging.

2) I would use the Keil C51 compiler.


Any comments would help, even if it is a suggestion to not proceed due to
the difficulty involved.

Thank you,

Madison

___
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] Clarification request: periph_timer behaviour

[Joakim Nohlgård]

Hi developers,
I have some questions about the details of the expected behaviour of
the periph_timer interface with regards to stopped timers:

timer_init: Should an already initialized and started timer be reset
to zero and timer targets cleared when this is called?

timer_set, timer_set_absolute, timer_clear: should these functions
start the underlying timer if it is stopped when they are called?

timer_read: Is this function expected to show the correct count when
the underlying timer is stopped (that is, the count that the timer was
on when it was stopped)?

timer_stop: Should this function clear the currently set target time
or should the timer continue counting towards the target where it left
off when timer_start is called again?

timer_start: Should the count towards a target time continue where it
was before the timer was stopped or do we start over from the start?
e.g. timer_set(3000), when the count is at 2000 we call timer_stop(),
then timer_start, do we need to wait 3000 ticks until the target is
hit or do we wait 1000 ticks?

Can the count returned by timer_read ever be reset to zero (or
otherwise modified) from the API, without calling timer_init?

in the documentation for timer_init it says:
"The timer will be started automatically after initialization *with
interrupts enabled.*" (emphasis mine)
What interrupts are expected to occur when there is no target time set
yet? Should the callback be called when the timer overflows?
My interpretation of this sentence is that the "with interrupts
enabled" is a leftover from an older iteration of the API when we had
the timer_enable_irq/disable_irq functions, and I don't think the
application will expect the callback to be called whenever the timer
overflows, because that would make it more difficult to handle the
callbacks in the application.

I can make a PR with some doc improvements once we reach a consensus
regarding the above questions.

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

Re: [riot-devel] rtc alarm running with threads

[Joakim Nohlgård]

Hi Paula,
It is likely that the debug print in the sale_test function overflows the
ISR stack. You can increase that stack size by adding
CFLAGS += -DISR_STACKSIZE=1024
to your Makefile.
The interrupt service routines on cortex m have a separate stack which is
set to 512 bytes by default. Usually when you need to do more complex tasks
you will unlock a mutex from the ISR or set a thread flag which will tell
some user space thread to perform the complex tasks instead of running it
inside the ISR.
Having long interrupt service routines may also delay the execution of
other interrupt handlers, so there are several benefits of performing tasks
in user space threads.

Best regards,
Joakim


On Oct 20, 2017 23:52, "Paula Ortega Cancino"  wrote:

> Hi Kaspar,
>
> I'm running on stm32-l1, board nucleo-152RE
>
> Paula
>
> 2017-10-20 18:13 GMT-03:00 Kaspar Schleiser :
>
>> Hi Paula,
>>
>> on which platform are you running your application?
>>
>> Kaspar
>>
>> On 10/20/2017 09:45 PM, Paula Ortega Cancino wrote:
>> > Hi Oleg,
>> >
>> > Thanks for your help. I should mention that i'm working on the 2017.07
>> > release. This is the main functions of the code, the behavor i'm
>> > expecting is to trigger the alarm every TIME_WAITING seconds, run
>> > sale_test() and the go back to the control thread. However i get a
>> > kernel panic or run only the control_thread, without considering the
>> > rtc_alarm after a while.
>> >
>> > char stack[THREAD_STACKSIZE_DEFAULT];
>> > kernel_pid_t control_pid;
>> >
>> > int sale_test(void){
>> > DEBUG("Send sale\n");
>> > return 1;
>> > }
>> >
>> > /* set interrupt event every TIME_WAITING  = 10 seconds*/
>> > static void onInterruptEvent(void *arg)
>> > {
>> > (void)arg;
>> > struct tm time;
>> > rtc_get_alarm();
>> >
>> > /* schedule next message */
>> > time.tm_sec  += TIME_WAITING;
>> > /* Make an interrupt */
>> > sale_test();
>> >
>> > rtc_clear_alarm();
>> > rtc_set_alarm(, onInterruptEvent, 0);
>> > }
>> >
>> > void *control_thread(void *arg)
>> > {
>> > (void) arg;
>> > while (1) {
>> >   DEBUG("Running thread right now\n");
>> >   xtimer_usleep(10);
>> > }
>> > return NULL;
>> > }
>> >
>> > int main(void)
>> > {
>> > printf("This test will display 'Alarm every %i seconds'\n",
>> > TIME_WAITING);
>> >
>> > /* initialize rtc functions */
>> > application_init();
>> >
>> > onInterruptEvent(NULL);
>> >
>> > control_pid = thread_create(stack, sizeof(stack),
>> > THREAD_PRIORITY_MAIN - 1, THREAD_CREATE_STACKTEST,
>> > control_thread, NULL, "control");
>> > (void) control_pid;
>> >
>> > return 0;
>> > }
>> >
>> > Cheers,
>> > Paula
>> >
>> > 2017-10-19 14:41 GMT-03:00 Oleg Hahm > > >:
>> >
>> > Dear Paula,
>> >
>> > can you share the code of your application somewhere? That might
>> > help to find
>> > the issues. I would suppose that the interrupt handler is faulty or
>> > consumes
>> > too much memory or something like this.
>> >
>> > I think start debugging with a basic application that just prints
>> > some text
>> > whenever a message from the RTC interrupt is received is a smart
>> > idea. Now, we
>> > need to figure out what exactly triggers the kernel panic. Are you
>> > compiling
>> > your application with the DEVELHELP macro enabled? And which port
>> > are you
>> > using? Maybe you can use `make debug` to get more information.
>> >
>> > Cheers,
>> > Oleg
>> > --
>> > /* Fuck, we are miserable poor guys... */
>> > linux-2.6.6/net/xfrm/xfrm_algo.c
>> >
>> > ___
>> > 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
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Graphing build sizes

[Joakim Nohlgård]

On Oct 13, 2017 09:53, "Hauke Petersen"  wrote:

Hej,

very nice effort, I love it!

Thinking out loud: would it make sense to do some data aggregation for more
generic views? On first thought I would imagine something like average
ROM/RAM size over all application/examples over all platforms.

I also have an idea for code size diff visualization, that I have in my
mind for quite a while: how about we draw a (huge) table, using all
available platforms as columns and all available applications as rows. Each
cell would then be colored: different green saturation for code size
decreases and different red saturation for code size increases, while
something neutral for no change. Then we could draw this table once for ROM
and once for RAM usage . This would allow us to see on first sight in which
aspects a certain PR influences the overall code size and also if there are
unexpected side effects in that regard.

What do you think about this idea, and how would you assess the doability?


Another way to do this could be using the Google docs api and updating a
huge spreadsheet.


Cheers,
Hauke


On 11.10.2017 16:59, Koen Zandberg wrote:

Hello,

One of the issues from the CI discussion at the RIOT summit was the
tracking and graphing of the nightly build sizes. After some
instructions from Kaspar for getting the JSON files I got something
working here:
https://riot-graphs.snt.utwente.nl/dashboard/db/demonstrator?orgId=1

For now I want to keep it up to date by running my script as a cron
every night approximately after the nightly build. The source code of
the script that parses and pushes the values to the database can be
found at my github [1].

The dashboard is now a simple Grafana templated dashboard where a test
and a board can be selected. I'd like to expand this by creating a
dashboard for every test or for every board. The most difficult thing
for now is to present the huge amount of data in a clear and concise
way. Input on this and the overview in general is most welcome.

Koen

[1]: https://github.com/bergzand/RIOT-graphs



___
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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

[Joakim Nohlgård]

On Wed, Sep 20, 2017 at 11:32 AM, Kaspar Schleiser <kas...@schleiser.de> wrote:
> Hi Joakim,
>
> On 09/20/2017 10:11 AM, Joakim Nohlgård wrote:
>> I have recently been digging around the gnrc_netdev code as well. I
>> think that adding support for other frame types and logic for sending
>> these frames will definitely become a mess if the 802.15.4 code is not
>> decoupled from the netdev code.
>
> Could you elaborate why? We should aim to get as much as possible
> gnrc-independent code.

I don't have an opinion on whether to depend on gnrc or not, but the
current send and recv implementation in gnrc_netdev_ieee802154 acts as
a wrapper for the real device driver send/recv functions, so the MAC
layer calls the wrapper function which generates the frame header
before passing on to the device driver. What I meant was that this
header generation/parsing should be its own separate function that the
MAC layer explicitly calls, instead of implicitly as a middle layer
between the MAC and the network device driver. All of the header
generation code is inside gnrc_netdev_ieee802154.c right now. That
code is going to be a mess if more frame types are added, or different
frame versions and header options should be supported.

https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev/gnrc_netdev_ieee802154.c#L154

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

[riot-devel] gnrc: MAC layer selection

[Joakim Nohlgård]

Dear developers,
Currently there are two different MAC layers for gnrc in the master
branch: basic gnrc_netdev, and gnrc_lwmac. gnrc_netdev is basically a
no-op MAC layer, only passes packets between the netdev driver and the
upper layers, while LWMAC is a duty cycling MAC implementation which
manages a schedule for the radio, including sleep.

Which layer is used is selected by which init function is called
during boot, if gnrc_lwmac_init is called, then the device will run
LWMAC, or if gnrc_netdev_init is called, then the device will use
gnrc_netdev. auto_init has an `#ifdef` block checking for
`MODULE_GNRC_LWMAC` and uses that to select which init function is
called, but this is only implemented for the at86rf2xx driver, any
other drivers will need to have similar changes to their auto_init
functions as well.

This current model is not going to scale well when new devices are
added and new MAC layers are implemented. All MAC layer
implementations will need to touch all netif auto_init
implementations.

I am asking for ideas on how to make this more modular and less #ifdeffy.

One possible solution is to add a function pointer member to the
`at86rf2xx_params_t` (and similar parameter structs for the other
netdev drivers) for initializing the MAC layer, and let the user
select the MAC layer there.
By default, we can use a macro GNRC_DEFAULT_INIT or similar to choose
the default MAC layer depending on the module selection. This would
behave like it is today for LWMAC, but the #ifdef hell would be kept
in a common header file, like gnrc_mac_default.h or something.

What are your thoughts on this?

I have a ContikiMAC MAC layer implementation queued up in the pipe for
inclusion in master and it will only make this situation worse if we
don't alter the current model.

Best regards,
Joakim Nohlgård
Eistec AB
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] 6lowpan fragmentation sending too fast

[Joakim Nohlgård]

Dear developers,
I have been working on the kw41zrf driver in PR #7107 [1]. However, I
can't get 6lowpan fragmented packets to transmit properly.
It seems the GNRC stack is trying to pass the next fragment to the
netdev driver before the first fragment has finished transmitting over
the air, resulting in the driver rejecting the send request. Is this a
known problem with any other radio drivers or is it my driver doing
something wrong?
Also, the send code in _send_nth_fragment in gnrc_sixlowpan_frag
contains a check of the return value of gnrc_netapi_send [2], but it
seems like my return code is lost somewhere along the way, because I
never see that debug message.

How do I get the 6lo thread to wait until the radio driver is ready to
send the next fragment?

[1]: https://github.com/RIOT-OS/RIOT/pull/7107
[2]: 
https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/sixlowpan/frag/gnrc_sixlowpan_frag.c#L211

Best regards,
Joakim Nohlgård
Eistec AB
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] usb-serial support on RIOT for radino32

[Joakim Nohlgård]

Dear Shengrong,
There is currently no USB stack in RIOT. There was an attempt to add one a
while ago, but it was never finished. See
https://github.com/RIOT-OS/RIOT/pull/3890 for the last work in progress.
Adding USB support would be a welcome feature, and I guess a vendor library
can be a useful starting point. However, care needs to be taken to ensure
that the API is suitable for any platform, so that we can use it for any
other USB capable MCU in the future. It should also conform in general with
the RIOT API design. I did not look at the ST USB library, so I can't say
if it is a suitable API for mainline RIOT.
Also note that any code that should be accepted into the RIOT main
repository needs to be LGPL compatible, and that GPL is not accepted.
Feel free to open a PR with your work in progress if you want any comments
on your approach, it does not have to be code ready for merging or even
compile.

Best regards,
Joakim

On Jul 21, 2017 23:07, "Shengrong Yin"  wrote:

Hello,

We are porting RIOT to radino32 uwb board.

However, unlike existing supported board in RIOT, this radino32 board does
not
have a USB to serial converter.

board info:
https://shop.in-circuit.de/product_info.php?products_id=186=en

They don't have onboard st-link or usb-to-serial converter.

We're thinking about including the virtual-serial library from stm32 for
this board in RIOT.
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/
system/libmaple/include/libmaple/usb_cdcacm.h

Is there any existing work on this effort or any other approach we can
follow to enable
the USB-serial?

Thanks,
-Shengrong

___
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] usb-serial support on RIOT for radino32

[Joakim Nohlgård]

On Jul 21, 2017 23:07, "Shengrong Yin"  wrote:

> Hello,
>
> We are porting RIOT to radino32 uwb board.
>
> However, unlike existing supported board in RIOT, this radino32 board does
> not
> have a USB to serial converter.
>
> board info:
> https://shop.in-circuit.de/product_info.php?products_id=186=en
>
> They don't have onboard st-link or usb-to-serial converter.
>
> We're thinking about including the virtual-serial library from stm32 for
> this board in RIOT.
> https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/
> system/libmaple/include/libmaple/usb_cdcacm.h
>
> Is there any existing work on this effort or any other approach we can
> follow to enable
> the USB-serial?
>
> Thanks,
> -Shengrong
>
> ___
> 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] CPU clock on kinetis boards

[Joakim Nohlgård]

Hi again Francisco,
See https://github.com/RIOT-OS/RIOT/pull/7379 for an updated clocking
configuration for Kinetis boards. I think it will be more robust
against non-default starting values because it tries to go to a safe
mode (using the internal reference clock) before reconfiguring the
clock setting registers.

Best regards,
Joakim

On Tue, Jun 13, 2017 at 3:12 PM, Francisco Javier Acosta Padilla
<francisco.aco...@inria.fr> wrote:
> Hi Joakim! Thanks for the hints.
>
> Your proposed approach at a first sight it seemed to work, then I rebased on
> your PRs and it didn’t work anymore. But more strange, I reverted your
> commits and it doesn’t work either… However, with the clock configuration
> that I proposed before it still works, either with your commits or without.
>
> I continue my quest…
>
> Cheers,
>
> --
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
>
> On 12 June 2017 at 19:36:46, Joakim Nohlgård (joakim.nohlg...@eistec.se)
> wrote:
>
> Hi,
> I think the wisest choice is probably to switch to FEI mode first to use the
> internal oscillator before booting a new image. That is the same mode that
> the mcu comes up in after a hardware reset.
>
> There are some relevant PRs open on GitHub for the Kinetis clocking:
> https://github.com/RIOT-OS/RIOT/pull/6986 move k64f clock configuration to
> board config
> https://github.com/RIOT-OS/RIOT/pull/6978 MCG improvements
>
> Best regards,
> Joakim
>
>
> On Jun 12, 2017 16:36, "Francisco Javier Acosta Padilla"
> <francisco.aco...@inria.fr> wrote:
>
> Hi again!
>
> I just made it work, though is super strange why it works… I did:
>
> static void cpu_clock_init(void)
> {
> /* setup system prescalers */
> SIM->CLKDIV1 = (
>SIM_CLKDIV1_OUTDIV1(0) | /* Core/System clock
> divider */
>SIM_CLKDIV1_OUTDIV2(1) | /* Bus clock divider */
>SIM_CLKDIV1_OUTDIV3(1) | /* FlexBus divider, not
> used in Mulle */
>SIM_CLKDIV1_OUTDIV4(3)); /* Flash clock divider
> */
>
> //SIM->CLKDIV1 = (uint32_t)SIM_CLKDIV1_60MHZ;
>
> /* RMII RXCLK */
> SIM->SCGC5 |= SIM_SCGC5_PORTA_MASK;
> PORTA->PCR[18] &= ~(PORT_PCR_ISF_MASK | PORT_PCR_MUX(0x07));
>
> kinetis_mcg_set_mode(KINETIS_MCG_PEE);
> }
>
> And it works… any explanation? I took the values from the k60f code (mulle)
> which seems to be completely different to the values contained in the macro
> SIM_CLKDIV1_60MHZ (0, 0, 1, 2 values). Therefore, I have no idea on which
> speed the clock is running.
>
> BTW, with this code also works for a “normal” build, compiling and flashing
> as usual.
>
> I’ll look at the manual to see why we do that on RIOT (it’s not documented)
> and maybe submit some PRs to both add doc and fix the setup if needed.
>
> Cheers,
>
> --
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
>
> On 12 June 2017 at 15:16:28, Francisco Javier Acosta Padilla
> (francisco.aco...@inria.fr) wrote:
>
> Hi RIOT devs!
>
> I’m currently working on the RIOT port for MCUBoot[1], which takes the
> frdm-k64f board as a reference board, and that’s also supported by RIOT and
> other OSs using MCUBoot.
>
> My first goal is to provide a “bootable” image compiled in RIOT and booted
> by MCUBoot built for mynewt.
>
> The work is going well so far, but I’m facing a problem which was also
> present while coding the RIOT bootloader. Namely, the problem is that the
> bootloader initialises the clock to a specific speed to run the booting
> algorithm, which goal is to boot an OS in another flash position, an thus
> the clock is initialised again leading to a clock crash.
>
> Does anyone knows a “safe” way to reset the clock config to afterwards
> configure it to the desired speed? Currently, as the code shows for the
> k64f, the assumption is that the clock is in it’s default condition, which
> is true when a reset is triggered, but now in this new context it’s not true
> anymore.
>
> I have seen some examples here [2] and here [3] which I tried without
> success.
>
> Thanks in advance!
>
> Cheers,
>
> --
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
>
> [1] https://github.com/runtimeco/mcuboot/
> [2]
> https://github.com/apache/incubator-mynewt-core/blob/master/hw/mcu/nxp/src/ext/sdk-2.0-frdm-k64f_b160321/devices/MK64F12/drivers/fsl_clock.h#L897
> [3] https://github.com/RIOT-OS/RIOT/blob/master/boards/mulle/board.c#L170
>
>
> ___
> 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

[riot-devel] periph/rtt intent

[Joakim Nohlgård]

Dear developers,
The intent of the RTT API seem to be rather unclear. My interpretation was
that the RTT API is used for long time, low precision timers that can be
used to sleep the system for minutes, hours or days. The precision is
expected to be 1 second, the same as for the RTC API, but without the
calendar struct representation. The reason for using the RTT API is to let
it represent the current wall clock time, for tagging collected data etc,
while the xtimer (and periph timer) is used for delays and internal
precision timing of events. The RTT alarm is used to schedule wake ups or
events which should happen at a specific time of day, for example taking a
measurement every day at 2:00.
There seem to be a different interpretation as well: the RTT API is used
for any hardware timers which keep running in low power modes.
This split is seen in the board configurations, where some boards list the
RTT as a 32768 Hz timer, others list it as a 1 Hz timer. This has already
begun causing problems among the API users, see the lwmac implementation
for example, which only works if the RTT is 32768 Hz.
My interpretation was initially based on a limitation in the RTT (called
RTC in NXP documents) on Kinetis hardware which only allow integer seconds
for the alarm, while a different hardware module can be used for 1/32768
second precision, but that timer wraps around after 2 seconds (2**16
ticks).
We need to clarify the documentation and align the implementations to match
each other, or the RTT API will be useless as an abstraction layer, since
its interpretation will be platform dependent.

What are your opinions on the RTT API, or the timer APIs in general?

Best regards,
Joakim Nohlgård
RIOT developer
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Dynamic radio power scaling in RIOT

[Joakim Nohlgård]

Hi Koen,
This sounds to me like a very promising feature for RIOT! Both the power
saving aspect as well as reducing interference for neighboring networks are
important features. Especially for urban environments it will be important
to not pollute the radio environment more than necessary when IoT devices
start becoming ubiquitous.

Best regards,
Joakim Nohlgård
Eistec AB

On Jun 22, 2017 10:00 PM, "Koen Zandberg" <k...@bergzand.net> wrote:

Hello,

For a small research project as a part of my study, I did some research
on the effectiveness of dynamic radio output scaling. The general idea
is that to save power, the radio has to transmit at only the power
required to reach the destination. For the research I wanted to build a
practical setup instead of a simulation as one of the research goals.

The setup I've build works by estimating the minimum required powered
and using layer 2 acks (or the lack thereof) as feedback. At this point
I have a mostly working power scaling proof of concept implemented in
RIOT. For an example measurement: https://bergzand.net/misc/etx5.svg
which is a measurement of a number of packets. The blue dots is an ETX
estimation measured based on the feedback from the radio module. The Red
line is the power configured for that packet. As visible, power is
scaled down until a stable level is reached. Power keeps oscillating
around this level until a lot of interference is noticed, then the power
sweeps back up.

The merit of this whole idea is that it should both save the node power,
but when implemented correctly also improve the total throughput of the
network. This last point because nodes transmit with less power, thus
causing less interference with nodes further away.

If there is interest in having this feature merged in mainline RIOT-os,
I'm willing to work on this to make sure that the code quality is as
required. The code can be viewed and tracked at
https://github.com/bergzand/RIOT/tree/mwn2

Regards,
Koen

___
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] At86rf2xx ACK frame

[Joakim Nohlgård]

Why do you need the actual ACK frame? It's only like 3 bytes + FCS and
doesn't really contain anything interesting. The only interesting
information is that the frame with the given sequence id was received
properly, which is exactly the same information you get from the
transceiver hardware.

Regards,
Joakim

On Jun 15, 2017 8:18 AM, "Baptiste Clenet"  wrote:

Which mean that automated ACK by the transceiver is fine.
1 - RIOT sends a frame
2 - Transceiver receives an ACK and transmit a AT86RF2XX_TRX_STATE__TRAC_
SUCCESS
3 - Here I want to get the ACK frame content
4 - Use it with openthread (Have a look here [1] to understand why we need
it)

[1] https://github.com/openthread/openthread/blob/master/
include/openthread/platform/radio.h#L404

Cheers,

2017-06-13 15:46 GMT+02:00 Baptiste Clenet :
> 2017-06-13 14:45 GMT+02:00 Oleg :
>> Hi Baptiste!
>>
>> On 2017-06-13 12:30, Baptiste Clenet wrote:
>>>
>>> On netdev event: NETDEV_EVENT_TX_COMPLETE (after
>>> AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame
>>> received by at86rf2xx?
>>
>>
>> The ACK frame is processed automatically by the transceiver. There is no
way
>> to access it using the extended mode. If you use the base mode, you will
>> have to send and process the ACK yourself.
>>
>
> Ok I don't want to process the ACK myself, I only want to get the
> frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame
> store in a register/frame buffer? Or do we must use base mode to get
> the ACK frame.
>
>>
>> Cheers,
>> Oleg
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> --
> Baptiste



--
Baptiste
___
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] CPU clock on kinetis boards

[Joakim Nohlgård]

Hi,
I think the wisest choice is probably to switch to FEI mode first to use
the internal oscillator before booting a new image. That is the same mode
that the mcu comes up in after a hardware reset.

There are some relevant PRs open on GitHub for the Kinetis clocking:
https://github.com/RIOT-OS/RIOT/pull/6986 move k64f clock configuration to
board config
https://github.com/RIOT-OS/RIOT/pull/6978 MCG improvements

Best regards,
Joakim


On Jun 12, 2017 16:36, "Francisco Javier Acosta Padilla" <
francisco.aco...@inria.fr> wrote:

Hi again!

I just made it work, though is super strange why it works… I did:

static void cpu_clock_init(void)
{
/* setup system prescalers */
SIM->CLKDIV1 = (
   SIM_CLKDIV1_OUTDIV1(0) | /* Core/System clock
divider */
   SIM_CLKDIV1_OUTDIV2(1) | /* Bus clock divider */
   SIM_CLKDIV1_OUTDIV3(1) | /* FlexBus divider, not
used in Mulle */
   SIM_CLKDIV1_OUTDIV4(3)); /* Flash clock divider
*/

//SIM->CLKDIV1 = (uint32_t)SIM_CLKDIV1_60MHZ;

/* RMII RXCLK */
SIM->SCGC5 |= SIM_SCGC5_PORTA_MASK;
PORTA->PCR[18] &= ~(PORT_PCR_ISF_MASK | PORT_PCR_MUX(0x07));

kinetis_mcg_set_mode(KINETIS_MCG_PEE);
}

And it works… any explanation? I took the values from the k60f code (mulle)
which seems to be completely different to the values contained in the
macro SIM_CLKDIV1_60MHZ (0, 0, 1, 2 values). Therefore, I have no idea on
which speed the clock is running.

BTW, with this code also works for a “normal” build, compiling and flashing
as usual.

I’ll look at the manual to see why we do that on RIOT (it’s not documented)
and maybe submit some PRs to both add doc and fix the setup if needed.

Cheers,

-- 
Francisco Javier Acosta Padilla
Research Engineer at INRIA Saclay
INFINE Team

On 12 June 2017 at 15:16:28, Francisco Javier Acosta Padilla (
francisco.aco...@inria.fr) wrote:

Hi RIOT devs!

I’m currently working on the RIOT port for MCUBoot[1], which takes the
frdm-k64f board as a reference board, and that’s also supported by RIOT and
other OSs using MCUBoot.

My first goal is to provide a “bootable” image compiled in RIOT and booted
by MCUBoot built for mynewt.

The work is going well so far, but I’m facing a problem which was also
present while coding the RIOT bootloader. Namely, the problem is that the
bootloader initialises the clock to a specific speed to run the booting
algorithm, which goal is to boot an OS in another flash position, an thus
the clock is initialised again leading to a clock crash.

Does anyone knows a “safe” way to reset the clock config to afterwards
configure it to the desired speed? Currently, as the code shows for the
k64f, the assumption is that the clock is in it’s default condition, which
is true when a reset is triggered, but now in this new context it’s not
true anymore.

I have seen some examples here [2] and here [3] which I tried without
success.

Thanks in advance!

Cheers,

-- 
Francisco Javier Acosta Padilla
Research Engineer at INRIA Saclay
INFINE Team

[1] https://github.com/runtimeco/mcuboot/
[2] https://github.com/apache/incubator-mynewt-core/blob/
master/hw/mcu/nxp/src/ext/sdk-2.0-frdm-k64f_b160321/devices/
MK64F12/drivers/fsl_clock.h#L897
[3] https://github.com/RIOT-OS/RIOT/blob/master/boards/mulle/board.c#L170


___
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] Help testing Kinetis dev boards

[Joakim Nohlgård]

I forgot to mention that you will need a development snapshot of openocd
for the kw41z.
See my kwxxz-support branch at
https://github.com/gebart/openocd/tree/pr/kwxxz-support?files=1

Best regards,
Joakim

On Jun 12, 2017 14:21, "Emmanuel Baccelli" <emmanuel.bacce...@inria.fr>
wrote:

> Hi Joakim,
>
> FYI I just got hold of some kw41z boards.
> gnrc_networking compiles on both OS X and Ubuntu (Vagrant).
> Now I am trying to debug some trouble with jlink (can't flash the board
> yet).
>
> Cheers
>
> Emmanuel
>
> On Thu, Jun 8, 2017 at 1:09 PM, Emmanuel Baccelli <
> emmanuel.bacce...@inria.fr> wrote:
>
>> Hi Joakim
>>
>> just the other day, we ordered a couple frdm-kw41z at Inria, so we
>> should be able to test here soon.
>>
>> Cheers,
>>
>> Emmanuel
>>
>> On Thu, Jun 8, 2017 at 11:32 AM, Joakim Nohlgård <
>> joakim.nohlg...@eistec.se> wrote:
>>
>>> Dear developers,
>>> Eistec have begun adding support for more Kinetis Freedom development
>>> boards (frdm-k22f [1], frdm-kw41z [2]), to improve RIOT's hardware
>>> coverage.
>>>
>>> I would be thankful if anyone with access to these boards would test it
>>> and comment in the PRs with the results of their tests.
>>>
>>> I have opened a tracker issue [3] on GitHub for viewing the progress of
>>> this effort.
>>>
>>> [1]: https://github.com/RIOT-OS/RIOT/pull/6994
>>> [2]: https://github.com/RIOT-OS/RIOT/pull/6995
>>> [3]: https://github.com/RIOT-OS/RIOT/issues/7154
>>>
>>> Best regards,
>>> Joakim Nohlgård
>>> Eistec AB
>>>
>>> ___
>>> 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

[riot-devel] Help testing Kinetis dev boards

[Joakim Nohlgård]

Dear developers,
Eistec have begun adding support for more Kinetis Freedom development
boards (frdm-k22f [1], frdm-kw41z [2]), to improve RIOT's hardware
coverage.

I would be thankful if anyone with access to these boards would test it and
comment in the PRs with the results of their tests.

I have opened a tracker issue [3] on GitHub for viewing the progress of
this effort.

[1]: https://github.com/RIOT-OS/RIOT/pull/6994
[2]: https://github.com/RIOT-OS/RIOT/pull/6995
[3]: https://github.com/RIOT-OS/RIOT/issues/7154

Best regards,
Joakim Nohlgård
Eistec AB
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Netdev events questions

[Joakim Nohlgård]

Dear developers,
I'm working on a radio driver for the Kinetis KW41Z 802.15.4 radio and
I have run into some questions regarding when to send the different
netdev events from my device driver.

Should NETDEV_EVENT_RX_COMPLETE be sent before, or after TX of ACK
packet is finished?
Should NETDEV_EVENT_RX_COMPLETE be sent even when the radio detects a
CRC failure?

My device is using hardware auto-ACK, but I can enable interrupts for
both the end of RX and at the end of TX ACK. It seem like it would be
more robust to always wait for TX ACK to be performed, but it may add
delays if the medium is very busy. It is possible to abort the TX ACK
after an RX if the CPU issues a new command quickly enough.

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

Re: [riot-devel] Reorganization of Cortex-M build test MCU groups

[Joakim Nohlgård]

On Mon, Apr 24, 2017 at 9:27 AM, Kaspar Schleiser <kas...@schleiser.de> wrote:
> Hey Joakim,
>
> On 04/21/2017 06:46 PM, Joakim Nohlgård wrote:
>> I would like to change this split to create groups of boards which are
>> likely to fail together to be in the same group. For example, the Nucleo
>> boards could be in one or more groups cortexm_nucleo, the SAM boards,
>> nrf, and kinetis boards would be suitable candidates for other groups.
>> Practically grouping by each xxx_common source directory makes sense in
>> my opinion.
>
> IMO a good idea. And as Sebastian pointed out, the build groups
> themselves will be obsolete, soon.
>
> How about introducing tags? The difference being that a board can have
> more than one "tag", with some of them possibly defined by the MCU used.
>
> e.g., every nucleo gets "nucleo", "arm" and "cortex-m", but some also
> get "cortex-m0" and maybe "lowmem", others get "cortex-m4" and
> "hardfloat". You get the idea.
>
> That way we could use our buildtests like:
>
> $ make buildtest TAGS=msp430
>
> or even
>
> $ make buildtest TAGEXPR="cortex-m0 and nucleo"
>
> It might be that this is equivalent to what we now call "features". ;)

A good idea, we could introduce just introduce more features and wire
the features_required checks to be available from the command line.
`make buildtest TAGS=kinetis`
would be very useful while working on periph drivers.

>
> Kaspar
> ___
> 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] Cortex M0 HardFault

[Joakim Nohlgård]

On a related note, I had some trouble with unexplained hard faults when I
built newlib using gcc-6.2, but I didn't have time to investigate further
at that time and I simply reinstalled newlib built with gcc-5.4 instead.

Best regards,
Joakim

On Dec 15, 2016 5:51 PM, "Kaspar Schleiser"  wrote:

> Hey,
>
> On 12/15/2016 05:32 PM, Baptiste Clenet wrote:
> > What could cause:
> > Stack pointer corrupted, reset to top of stack
> > l.238, vectors_cortexm.c
> > (then board is halted)
> >
> > Any program I flash on the samr21 goes directly to hard_fault_handler()
>
> Any program, e.g., also "tests/hello-world"?
>
> > Board dead or something missing?
>
> Which OS are you on, what toolchain?
> Do you have a second samr21-xpro to test the binary?
> Are you on a clean master checkout?
>
> Seriously, did you try a different USB cable?
>
> Kaspar
> ___
> 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] BIN FILES

[Joakim Nohlgård]

If you want a binary file which is an exact byte-for-byte copy of the
microcontroller ROM you can use objcopy to convert from ELF to raw binary.
The RIOT build system also produces a HEX file for flashing, which is a
plain-text variant of the raw binary.

arm-none-eabi-objcopy -O binary myprog.elf myprog.bin

You will not, however, need any of this manual handling for flashing the
supported boards, `make flash` is all you need.

Best regards,
Joakim

On Fri, Oct 7, 2016 at 3:35 PM, Oleg Hahm  wrote:

> Hi Ilias!
>
> On Fri, Oct 07, 2016 at 03:29:38PM +0200, Ilias Seitanidis wrote:
> > Is it possible to create a bin file, which includes everything and then
> > flash the .bin file
> > on the board? (From what I've seen RIOT OS doesn't support this,
> right)
>
> What exactly do you mean by ".bin" file? By default RIOT produces an ELF
> [1] file
> for most platforms that contain the full binary that is flashed onto the
> device.
>
> Cheers,
> Oleg
>
> [1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
> --
> Chuck Norris doesn't do TCP handshake - he does TCP roundhouse-kick to
> initiate
> the connection.
>
> ___
> 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] MIPS Port

[Joakim Nohlgård]

I don't have anything to comment on the PR, but I thought it should be
mentioned that only maintainers can set labels and assign people to an
issue/PR, you'll probably get some labels added on it by the maintainers
soon.

Best regards, Joakim

On Sep 28, 2016 13:52, "Neil Jones"  wrote:

Hi all,

I have just submitted a pull-request for MIPS support.

This is my first pull request and I couldn't work how to apply any
labels to it ? (So go easy on me).

A big thanks goes out to Leon Alrae who started the ball rolling on this
MIPS port.

All reviews welcome.

Cheers,

Neil.

___
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] About RIOT support filesystem

[Joakim Nohlgård]

Hello,
Work is being done to add file system capabilities to RIOT. Currently there
is a proposed change which adds SPIFFS (https://github.com/pellepl/spiffs)
support to RIOT. The changes are not yet merged with the master branch, but
the goal is to get them into master soon. I have unfortunately been a bit
too busy with other tasks at work to be able to work on the VFS parts for
the last month or so, but I intend to clean it up and finish the PR as soon
as I get some spare time. The OTAKeys people have been very active with
their SPIFFS and MTD parts and I get the feeling they might already be
using it in their own code.

There was some talk about adding FAT support, but I think the active
developers have been too busy with other parts of the system to write that
part yet.

Relevant open pull requests:
https://github.com/RIOT-OS/RIOT/pull/5616
https://github.com/RIOT-OS/RIOT/pull/5624
https://github.com/RIOT-OS/RIOT/pull/5625
https://github.com/RIOT-OS/RIOT/pull/5668

Best regards,
Joakim

On Tue, Sep 20, 2016 at 5:30 AM, 王洪涛  wrote:

> Dear all:
> Resently, We'll evaluate an operating system for IOT，Search some releated
> information through Internet, we found that NUTTEX and RIOT are more
> suitable for us，But RIOT maybe not support filesystem，Could you please help
> us to confirm that whether RIOT support filesystem(eg:
> FAT/FAT16/FAT32，yaffs or ubifs!) or filesystem is already in development?
>  thanks o lot!!
>
>
> --
>
> 王洪涛
> Best Regards!!
>
>
>
>
> ___
> 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] Unlocking mutex in RTC ISR and thread switching causes HardFault

[Joakim Nohlgård]

Do you have some example code that you can share which triggers this fault?

Best regards, Joakim

On Sep 14, 2016 7:50 PM, "Anon Anonymous"  wrote:

> Hello,
>
> I trying to unlock mutex in RTC Alarm ISR and after alarm shoots and mutex
> is unlocked, the thread switch request is pending. RTC ISR in rtc.c file
> check that flag and calls thread_yield() to call a scheduler. After PendSV
> interrupt is triggered, HardFault occurs right after PendSV enabling
> command.
>
> When the same operations done from for example, TIM interrupt which used
> by xtimer, context switching goes well.
>
> FSR/FAR:
>>  CFSR: 0x0004
>>  HFSR: 0x4000
>>
>
>
> My device is STM32L151.
>
> Best regards,
> Anon
>
> ___
> 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] RIOT and avr-libc

[Joakim Nohlgård]

Yes, it is using avr-libc for AVR targets.

On Aug 25, 2016 10:16 AM, "Loïc Dauphin"  wrote:

> Hello,
>
> I think I know the answer, but just to be sure : Do RIOT use avr-libc or
> newlib for AVR targets ?
>
> I think it is avr-libc by the way.
>
> Cheers !
>
> Loïc
>
> ___
> 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] qemu-i386 port

[Joakim Nohlgård]

I agree with dropping qemu-i386

On the same subject, would it make sense to clean up some other boards
with less than ideal support?
chronos is one board which I frequently run into trouble with because
it is never up to date with the other platform implementations,
especially the stdio is very hacky on that board.

/Joakim

On Aug 9, 2016 12:51, "Martine Lenders"  wrote:
>
> Hi,
> we now have the third person wondering about the qemu-i386 port. Fact
> is, it doesn't work (we do not even have the unittests activated
> anymore). Is there a reason why we did not drop it yet (except making
> all the good work by René void)? Or are we planning to provide better
> support for it in the future?
>
> Cheers,
> Martine
> ___
> 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] Byte array should be uint8_t, not char

[Joakim Nohlgård]

Hi Kees,
Do you have the time/energy to resume the effort of updating the periph/spi
interface in where Hauke left off in
https://github.com/RIOT-OS/RIOT/pull/4780?

There are a lot of device drivers which need updating, and also some
existing comments on the PR.

I can assist in reviewing the changes and updating device drivers, but I
don't have a lot of time to spend on this right now.

Best regards,
Joakim

On Wed, Jul 6, 2016 at 7:00 AM, Ludwig Knüpfer  wrote:

> Hi Kees,
>
> I assume there are more violations than the ones in the SPI drivers... But
> of course every step forward is great!
>
> Testing can be done by the community. We have plans to create a
> distributed test system with actual hardware attached, but sadly that has
> not become reality yet.
>
> Compilation can be tested automatically by running `make buildtest` for
> the respective test application (tests/periph_spi).
>
> Cheers,
> Ludwig
>
> Am 5. Juli 2016 21:31:49 MESZ, schrieb Kees Bakker :
> >Hi Ludwig,
> >
> >Well, it will be a challenge to smootly correct this.
> >There are 16 CPU's that use spi_transfer_byte(s) and 6 drivers.
> >
> >I won't mind creating a PR, but of course I can only test it by
> >building
> >examples for all boards that support SPI. And look at compile errors.
> >Or are
> >there other procedures?
> >
> >On 04-07-16 07:23, Ludwig Knüpfer wrote:
> >> Hi Kees,
> >>
> >> Unless there is a good reason to deviate from this guideline all
> >violations should be corrected. This particular rule was added
> >relatively recently, so it would not surprise me if not all occurrences
> >in RIOT have been adapted yet.
> >>
> >> Cheers,
> >> Ludwig
> >>
> >> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker :
> >>> Hi,
> >>>
> >>> The Coding Convention is clear about it.
> >>>
> >>> "Guidelines for pointer types (as long as it is reasonable):
> >>>
> >>>   * use |char *| for strings and only for strings
> >>> * use |uint8_t[]| as type for arbitrary byte buffers, but use |void
> >*|
> >>> to pass them around. |uint8_t[]| because we're dealing with
> >bytes
> >>> and not characters, |void *| to avoid unnecessary casting shall
> >the
> >>> need arise to have their content to have a certain type
> >>>   * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
> >>> addresses, where it avoids unnecessary temporary variable
> >>>   * use |void *| for generic typing"
> >>>
> >>>
> >>> In the SPI driver however the transfer functions use char *
> >parameters,
> >>>
> >>> but SPI is usually dealing with binary
> >>> information (bytes), not strings. This leads to unnecessary casts in
> >>> other parts of the code. (E.g. nvram_spi).
> >>>
> >>> What is our policy about this? Are we going to correct this at some
> >>> point? Is it too late already (I hope not)?
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> >
> >
> >--
> >Kees Bakker
> >Founder
> >SODAQ
> >M. 0031617737165
> >www.sodaq.com
> >
> >___
> >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] Compatibility matrix

[Joakim Nohlgård]

Good idea! Maybe it could be linked to Murdock to have it automatically
generate the matrix based on what current master can compile?
/Joakim

Den 15 jul 2016 16:53 skrev "Ludwig Knüpfer" :

Hi,

One idea for improving understanding of the meaning of "supported platform":
We could provide a matrix showing which test application runs on which
platform.
Opinions?

Cheers,
Ludwig
___
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] I have question about scheduler when all thread in sleep

[Joakim Nohlgård]

Dear Teemu,
What you are describing sounds like the xtimer subsystem in RIOT. It uses a
hardware timer to schedule tasks in the future.
See examples/xtimer_periodic_wakeup in the RIOT sources for an example on
how to achieve periodic scheduling for your task.

Also note that the function xtimer_usleep_until used in the example may be
renamed xtimer_periodic_wakeup in a near future, see [1].
The functionality will remain the same and the example will be updated at
the same time the rename happens.

[1]: https://github.com/RIOT-OS/RIOT/pull/5612

Best regards,
Joakim

On Wed, Jul 13, 2016 at 10:53 AM, Teemu Hakala  wrote:

>
>
> > On 12 Jul 2016, at 22:02, Kaspar Schleiser  wrote:
> >
> > The system gets woken up by external interrupts, e.g., a timer,
> > gpio-pin. That powers up the MCU
>
> > thread_flag), that triggers the scheduler and
>
> > The scheduler never wakes up itself
>
> In this thinking concept of achieving some repetitive task, you should
> perhaps configure a hw timer to create a stream of interrupts.
>
> Said interrupts then individually wake up mcu, go via irq handler and
> start processing that then yields, allowing the scheduler to put mcu into
> sleep mode. This is then repeated.
>
> Most normal modern mcus support configuring a timer for this purpose, the
> interrupts can come from an external source or mcu internal peripherals
> such as adc can act as interrupt stream generator.
>
>  - 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

Re: [riot-devel] Byte array should be uint8_t, not char

[Joakim Nohlgård]

Hi Kees,
Like Ludwig wrote, there are some places which haven't followed the coding
conventions because the CC weren't as clear before as they are now with
regards to this. Since RIOT is relying on its community for code
contributions, these kinds of clean ups may take a long time after the
documentation has been updated until someone decides to fix them.

The SPI periph driver is going through some rework, see
https://github.com/RIOT-OS/RIOT/pull/4780 and
https://github.com/RIOT-OS/RIOT/issues/4758, but it has not yet been merged
because of various other things getting in the way.

Best regards,
Joakimr

On Mon, Jul 4, 2016 at 7:23 AM, Ludwig Knüpfer  wrote:

> Hi Kees,
>
> Unless there is a good reason to deviate from this guideline all
> violations should be corrected. This particular rule was added relatively
> recently, so it would not surprise me if not all occurrences in RIOT have
> been adapted yet.
>
> Cheers,
> Ludwig
>
> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker :
> >Hi,
> >
> >The Coding Convention is clear about it.
> >
> >"Guidelines for pointer types (as long as it is reasonable):
> >
> >  * use |char *| for strings and only for strings
> > * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *|
> >to pass them around. |uint8_t[]| because we're dealing with bytes
> >and not characters, |void *| to avoid unnecessary casting shall the
> >need arise to have their content to have a certain type
> >  * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
> >addresses, where it avoids unnecessary temporary variable
> >  * use |void *| for generic typing"
> >
> >
> >In the SPI driver however the transfer functions use char * parameters,
> >
> >but SPI is usually dealing with binary
> >information (bytes), not strings. This leads to unnecessary casts in
> >other parts of the code. (E.g. nvram_spi).
> >
> >What is our policy about this? Are we going to correct this at some
> >point? Is it too late already (I hope not)?
>
> ___
> 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] Hardfault when linking OpenThread library

[Joakim Nohlgård]

What platform are you running this on?
Could you post your .map file? (preferably as a link to gist or pastebin or
similar, since they tend to be very large)

Best regards,
Joakim

On Fri, Jun 17, 2016 at 1:51 PM, Jose Alamos  wrote:

> Hi community,
>
> I'm having a weird hardfault when I'm linking the OpenThread library to
> RIOT. After running GDB, I noticed the hardfault is before accessing main()
> function (so shouldn't be a problem of the port itself).
>
> RIOT is crashing in this line [1]. Here's the content of hardfault:
>
> 2016-06-17 13:40:42,716 - INFO # Context before hardfault:
> 2016-06-17 13:40:42,718 - INFO #r0: 0x
> 2016-06-17 13:40:42,719 - INFO #r1: 0x0655
> 2016-06-17 13:40:42,721 - INFO #r2: 0x
> 2016-06-17 13:40:42,722 - INFO #r3: 0x58c4
> 2016-06-17 13:40:42,724 - INFO #   r12: 0x
> 2016-06-17 13:40:42,726 - INFO #lr: 0x00021ea7
> 2016-06-17 13:40:42,727 - INFO #pc: 0x58c4
> 2016-06-17 13:40:42,729 - INFO #   psr: 0x4000
> 2016-06-17 13:40:42,729 - INFO #
> 2016-06-17 13:40:42,729 - INFO # Misc
> 2016-06-17 13:40:42,731 - INFO # EXC_RET: 0xfff9
> 2016-06-17 13:40:42,735 - INFO # Attempting to reconstruct state for
> debugging...
> 2016-06-17 13:40:42,736 - INFO # In GDB:
> 2016-06-17 13:40:42,737 - INFO #   set $pc=0x58c4
> 2016-06-17 13:40:42,738 - INFO #   frame 0
> 2016-06-17 13:40:42,739 - INFO #   bt
>
>
> The OpenThread library is in C++, I programmed the hooks in C and C++ but
> I get the same hardfault.
>
> Any clue?
> Cheers
>
> [1]:
> https://github.com/RIOT-OS/RIOT/blob/b5497c3be43bdfecb0fb10e84bffbbd76d7a1ca1/cpu/cortexm_common/vectors_cortexm.c#L113
>
> ___
> 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] Populating neighbor cache without ND

[Joakim Nohlgård]

(Continuing from a thread on Github:
https://github.com/RIOT-OS/RIOT/issues/5025)

tldr; It should be possible to use RPL standalone without 6lowpan-ND.

Currently the only way to add neighbor cache entries is through neighbor
solicitations+neighbor advertisements (ND) or through the shell. My initial
opinion was that RPL should add neighbor cache entries for all DAOs it
receives
​.

​@cgundogan
 argued that the lowpan network may be asymmetrical in what packets get
through between nodes, so a DAO reception may not guarantee
​ reliable​
bidirectional communication between two link-local addresses
​:​

​RPL states in the RFC that it requires bidirectional links to function
> properly. (6Lo-)ND is one way to get those bidirectional links, so that the
> ncache itself only contains entries that are bidirectional. Receiving a DAO
> is not a strong indication whether the link is bidirectional or not. DIO
> traffic is (mostly) multicast (and sparse) in the downwards direction,
> while DAO traffic is (mostly) unicast in the upwards direction. Due to the
> known problems of wireless technology (interference, etc.) and
> "enhancements" of link layers (e.g. to apply QoS for certain traffic
> patterns, multicast, unicast, etc.) the link can be highly asymmetric.
> Receiving a DAO does not mean that my DIO, which I send out e.g. 1 minute
> ago, has reached that same child.​


So, a summary of the scenario, written by Cenk:

To summarize again so that I understand you correctly:
> You have 2 nodes (A and B)
> A is the RPL root and has a neighbor cache (+ (6Lo-)ND is running)
> B is a normal rpl router who joins the DODAG of A and has no neighbor
> cache and no ND running.
> A will always expect an entry in its neighbor cache before it can send out
> traffic to B,
> but since B is not participating in the RS/RA-NS/NA exchange with A, A
> will never get an entry for B in its ncache.


​Emmanuel further suggested:

Maybe we should consider creating a STALE entry in the neighbor cache for
> neighbors heard of, but without bidirectional check at ND level yet?
>

It was suggested that we would continue the discussion on the devel mailing
list.

Does anyone have more ideas or suggestions on how to populate the neighbor
cache without ND?

This is especially interesting for interoperability with ​other systems
which may not even have a 6lowpan ND implementation, and can only do RPL.

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

Re: [riot-devel] Updating micro-ecc

[Joakim Nohlgård]

Hey Mathias,

On Mon, Mar 7, 2016 at 12:14 PM, Tausig Mathias
 wrote:
>
> Hy!
>
> I'd like to update the micro-ecc package included with RIOT-OS, since the
> current version is pretty outdated.
> Currently, the package uses a patch which removes all the random number
> generation code from micro-ecc and substitutes it for invocation to the hwrng
> interface.
> Wouldn't it be more straight-forward, to just plug the hwrng intefrface into
> micro-ecc directly (via the uECC_set_rng function), instead of making big
> alterations?

To me that sounds like a really good solution. I don't know anything
about the internals of the micro-ecc package but from a maintenance
burden perspective it is usually better to have as small and as few
changes from upstream as possible. Would you be willing to provide a
PR?

If you provide a PR, check that the micro-ecc RNG code does not bloat
the binary by still being linked in for providing some fallback
mechanism. (Like I said, I don't know anything about micro-ecc
internals so I don't know if this is the case)

Best regards,
Joakim

>
> cheers
> Mathias
> ___
> 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] Implementation of a real low power timer for sleep/stop mode (idle thread)

[Joakim Nohlgård]

Hi Bernhard,
​It should be possible with some modifications to use a slow clock as the
xtimer source. There are a few developers working on improving the low
power operation in RIOT. As you discovered, the periph/timer API currently
needs to be updated to support non-MHz timer frequencies. I have a PR open
which will be merged some time soon, hopefully. Some PRs of interest:

https://github.com/RIOT-OS/RIOT/pull/4040 - support for non-1MHz operation
of periph/timer
https://github.com/RIOT-OS/RIOT/pull/3990 - xtimer 32768 Hz support, needs
some love, there are problems with it right now.
https://github.com/RIOT-OS/RIOT/pull/4065 - kinetis: periph/timer use LPTMR
for TIMER_0, PIT for TIMER_1, TIMER_2
https://github.com/RIOT-OS/RIOT/pull/2605 - kinetis: Add LPM implementation
- mostly an experiment remaining as a memo, needs to be reworked.

Once #4040 gets merged I hope to be able to resume working on xtimer 32768
Hz support. There are some other stuff that I need for work which are more
urgent though.

Best regards,
Joakim

On Mon, Feb 15, 2016 at 12:36 PM, Bernhard Nägele <
bernh...@naegele-privat.de> wrote:

> Hello everyone,
> the STM32L053 has a low power timer which could be configured to be
> clocked by an internal 37kHz oscillator.
> For real low power applications it would be a good idea to use this timer
> during sleep/stop mode (for the idle tread).
> As far as I know the context switching is performed by the xtimer which
> needs a 1MHz clock in its configuration.
> Would it be possible to use such a slow clock for this purpose?
>
> Best regards,
> Bernhard
> ___
> 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] Odd problems with xtimer

[Joakim Nohlgård]

Also, you can use the .map file to find out if there are any buffers
or other things nearby which may have overflowed and messed up your
state.

Are you using any IPC messages other than the xtimer functions?
(I wonder if there might be a race between the timer ISR callbacks and
the message reception in xtimer)

Regards, Joakim

On Wed, Feb 10, 2016 at 11:21 PM, Martine Lenders
 wrote:
> Hi,
> normally you can guess where the timer came from by looking at the address
> (or the debugger straight tells you). Is this somehow possible for your case
> (i.e. 0x200010a4)? That might be helpful for the timer people.
>
> Regards,
> Martine
>
> 2016-02-10 23:08 GMT+01:00 Michael Andersen :
>>
>> Hi
>>
>> Thanks for the reply. I am on a platform essentially equal to a
>> samr21xpro.
>>
>> The short answers:
>>  - samr21xpro
>> - only one declared xtimer_t object that is used more than once. I use it
>> with xtimer_set_msg for a thread to send itself a message. Both the timer
>> and the msg object are statically allocated. On the other hand, I have RPL
>> and all sorts of network things going and I have no doubt there are a ton of
>> timers involved. In terms of ephemeral timers, I call xtimer_usleep a LOT
>> with intervals of between 1ms and 100ms from multiple threads. I also send
>> packets every 200ms or so and receive them every 500ms or so.
>>  -The interrupt load might be pretty steep if the radio is interrupting on
>> every packet (promiscuous mode). I don't think it is. Otherwise I would
>> imagine that other than the timers it is less than ten per second.
>>
>> As for memory corruption, that may well be the case. I will double check
>> my code. I thought it was somewhat unusual that multiple boards would all
>> get a timer pointing to itself, but I suppose not all corruption is
>> non-deterministic and they all run identical firmware, so it might be
>> corruption.
>>
>> One question, in the network stacks, are there ever two threads possibly
>> using the same timer object? I ask because the timer_remove and the insert
>> are in two different critical sections, and if there are concurrent calls
>> with the same timer object then it might be possible to interrupt between
>> the critical sections and insert a timer that is already in the list. What
>> would then happen is that this loop would end with list_head equal to the
>> timer (assuming no other timer has the same time), and then the next two
>> lines would basically link the timer to itself.
>>
>> I could be wrong though, that is just a guess.
>>
>>
>> On Wed, Feb 10, 2016 at 2:45 AM, Kaspar Schleiser 
>> wrote:
>>>
>>> Hey Michael,
>>>
>>> On 02/10/2016 07:57 AM, Michael Andersen wrote:
>>> > it seems that one of the nodes in the list points to itself, hence the
>>> > endless loop.
>>> >
>>> > My first question is: when is this possible? It seems at first glance
>>> > that all code paths that lead here call remove_timer to prevent this
>>> > sort of problem.
>>> It should not be possible (tm).
>>>
>>> I took another look at the code, it seems to me that timer->next gets
>>> overwritten whenever a timer is set, so there can't be some outdated
>>> value.
>>>
>>> It might be that the list logic has a bug somewhere, but I remember
>>> testing them quite rigourously.
>>>
>>> > I don't access a the same timer object from two
>>> > different threads. My code using xtimer functions is not reentered.
>>> >
>>> > I don't use that many timer operations in my application code, but I do
>>> > assume that the following functions don't require any freeing or
>>> > removing afterwards, am I wrong?
>>> Completely right.
>>>
>>> Could you tell us more on how you are using timers?
>>>
>>> Interesting would be things like
>>>
>>> - what platform are you on
>>> - how many timers are simultaneously active
>>> - how are the intervals
>>> - how is the interrupt load
>>>
>>> ... that might help corner the issue.
>>>
>>> You should consider xtimer just showing a problem which might be caused
>>> by memory corruption.
>>>
>>> Kaspar
>>> ___
>>> 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