Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 25, 2015 5pm - 10pm (RIOT Events)

2015-08-25 Thread Joakim Gebart
I noticed that two of my assignments are in that list. I will not be
able to participate in the hack n ack session tonight, however, feel
free to ACK and merge anyway or take over the assignments if you want
to.

Best regards,
Joakim Gebart

On Tue, Aug 25, 2015 at 3:43 PM, Oleg Hahm oliver.h...@inria.fr wrote:
 Dear Hackers and Ackers,

 so far we have 12 candidates for the session tonight:
 https://github.com/RIOT-OS/RIOT/labels/Hack'n'ACK%20candidate

 Feel free to add more, but I would really love to see at least half of the
 candidates being merged tonight, so don't overestimate our capacities.

 Cheers,
 Oleg

 Am Mon, Aug 24, 2015 at 02:59:51PM + schrieb Google Calendar:
 This is a notification for:

 Title: Hack'n'ACK
 When: Tue Aug 25, 2015 5pm - 10pm Berlin
 Where: c-base Berlin; HAW Hamburg
 Calendar: RIOT Events
 Who:
 * Martine Lenders - creator

 Event details: 
 https://www.google.com/calendar/event?action=VIEWeid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxNTA4MjVUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn

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

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

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

 Forwarding this invitation could allow any recipient to modify your RSVP
 response. Learn more at
 https://support.google.com/calendar/answer/37135#forwarding

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


 --
 panic(Yeee, unsupported cache architecture.);
 linux-2.6.6/arch/mips/mm/cache.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] HotSpot JVM on RIOT-OS?

2015-08-11 Thread Joakim Gebart
On Tue, Aug 11, 2015 at 10:23 PM, Zac Harvey zhar...@pobox.com wrote:
 Thanks Kaspar and Joakim,

 I'm not trying to be difficult here (I promise!) I'm just trying to see the
 forest through the trees.

 When you say that The OpenJDK would probably require many megabytes of both
 ROM and RAM, this means it will not run on the sam3x8e..., why? Is it
 because it would require many megabytes, or because it requires ROM, which
 I'm guessing isn't supported by RIOT-OS?

ROM is the flash memory inside your MCU, that is where you store the
actual program code. RAM is volatile and is used for storing runtime
variables and buffers. Both kinds of memory are used by all RIOT
applications (OT: it is possible to run an application without
touching the ROM by loading the binary to RAM via the debugger. It is
not very useful in a real world application, though.)

The SAM3X8E has 512 kB of ROM and 96 kB of RAM. It will not run
OpenJDK because the binary will not fit, and if you manage to load it
(for example via external flash memory) it will definitely run out of
RAM before even finishing its initialization procedure.


 And yes, I will definitely dive into Darjeeling/LLVM, but am trying to see
 if I can't brute force an easier solution first. :-)

Darjeeling is probably the easy solution here :)


 Thanks again!


BR,
Joakim


 On 8/11/15 4:05 PM, Joakim Gebart wrote:

 On Tue, Aug 11, 2015 at 9:48 PM, Zac Harvey zhar...@pobox.com wrote:

 A quick mid-day follow up here: From everything I’ve collected so far,
 the
 RIOT-OS has no problem handling 32-bit (ARM-based) architectures, and so
 there’d be nothing stopping me from getting it to run on, say, the ARM
 SAM3X8E Cortex M3 MCU, yes? (Please correct me if I’m wrong!)

 Yes, the SAM3X8E is already supported in RIOT [1]. It is used by the
 udoo and arduino-due boards.

 There is a 32-bit (i386) version of OpenJDK 7 available on lots of Linux
 repos (check them out here: http://openjdk.java.net/install/). So, I
 can’t
 imagine it would be too difficult to get a 32-bit, Open JDK 7 compiled
 and
 running on an ARM chip where RIOT-OS is its underlying OS. Again,
 *please*
 correct me if I’m wrong, or if I’m overlooking some obvious hurdles here!

 The OpenJDK would probably require many megabytes of both ROM and RAM,
 this means it will not run on the sam3x8e, even if you add all the
 support functions that are required by the program to get it to run
 inside RIOT. A more realistic approach would be to take a serious look
 at the embedded JVMs that were suggested earlier in this thread
 (Darjeeling, and the LLVM based one).

 BR,
 Joakim

 [1]: https://github.com/RIOT-OS/RIOT/tree/master/cpu/sam3

 Best,
 Zac


 On 8/11/15 9:54 AM, Zac Harvey wrote:

 Thanks for the thorough response Joakim.

 I actually think 32-bit is perfectly fine, at least for my needs.
 Specifically I'm looking to target the ARM SAM3X8E family (Cortex M3)
 which
 is 32-bit (most Java apps can - and arguably should run inside of 4GB).

 Your point about Java not being able to *truly* deliver real-time
 guarantees is spot-on.  However, there are all sorts of tricks you can
 do so
 that major collections run very infrequently. And the Shenandoah/G1
 pauseless GC coming in Java 9 or 10 promises to reduce actual
 pausetime
 down to 1ms. That's probably not impressive for you hardcore RTOS
 peoples,
 but in Java-land that is like...the best thing...of all time...ever.

 A lot of IoT-type devices do not need *hard* real-time guarantees, but
 could greatly benefit from running existing platforms, libraries and
 frameworks running in JVM/Python/Ruby/etc. lanaguages.  How cool would
 it be
 to run Akka on a smart device? This is likely how Skynet will come to be
 self-aware and enslave us all.  I guess my motivation would be to accept
 the
 current real-time shortcomings of the JVM, use those tricks to minimize
 GC,
 and hold out for a few years until improvements to the core JVM (such as
 Shenandoah) are released into the wild.

 I also think such an endeavor would spark a large community of non-C
 devs
 to get heavily interested in RIOT-OS, which from what I can tell, is
 best-in-show in the modern RTOS landscape.

 Thanks again for the solid input here - stay tuned!

 On 8/11/15 8:48 AM, Joakim Gebart wrote:

 See my response inline below.

 On Tue, Aug 11, 2015 at 11:58 AM, Zac Harvey zhar...@pobox.com wrote:

 Thanks for that Lejos link, Kaspar, I will definitely dig into it
 later
 today.

 You mentioned that RIOT *targets* devices that require a small
 footprint,
 but you didn't state that RIOT only supports devices with small RAM.

 What's the max size/RAM that RIOT can support, or that RIOT is
 addressable
 for?  What would be entailed with refactoring it to handle larger
 apps?

 So far, RIOT does not support 64 bit systems (native included, it is
 compiled as a 32 bit binary even on amd64 afaik), and it will take
 some effort to add that support, because there may be hidden
 assumptions in the code

Re: [riot-devel] C++ Style Guide

2015-06-25 Thread Joakim Gebart
On Thu, Jun 25, 2015 at 11:44 AM, Johann Fischer j.fisc...@phytec.de wrote:
 Hi Raphael,

 Am 25.06.2015 um 11:09 schrieb Hiesgen, Raphael:

 Hi,


 it is time to write a C++ Coding Style Guide for RIOT. Since C and C++
 have different traditions here, I will simply start to suggest using the C++
 Style used in CAF [1]. While it is not identical, the style is relates to
 the guidelines used by Google and C++ Standard Library.


 How I see it is very similar to RIOT coding style.  2 spaces per indentation
 level is not acceptable to me, should be 4 as in C coding style. Otherwise,
 I find it very good.

+1, indentation must match between the C and C++ coding conventions,
there will be fewer style mistakes that way.


 By the way, can someone explain to me short why we need C ++ at all?

I quite enjoy writing applications in C++ instead of C. The C++
support is basically just a service to other RIOT users like me who
like to use C++ for writing their applications.

I don't know if the RIOT community will be open to having RIOT modules
and device drivers written in C++, (other than the C++ support
modules, of course).

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


Re: [riot-devel] C++ Style Guide

2015-06-25 Thread Joakim Gebart
Good initiative!

Could you create a new wiki article similar to
https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions for the C++
conventions?

/Joakim

On Thu, Jun 25, 2015 at 11:09 AM, Hiesgen, Raphael
raphael.hies...@haw-hamburg.de wrote:
 Hi,


 it is time to write a C++ Coding Style Guide for RIOT. Since C and C++ have 
 different traditions here, I will simply start to suggest using the C++ Style 
 used in CAF [1]. While it is not identical, the style is relates to the 
 guidelines used by Google and C++ Standard Library.


 Raphael



 [1] 
 https://github.com/actor-framework/actor-framework/blob/develop/CONTRIBUTING.md
 ___
 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] API proficiency levels

2015-05-22 Thread Joakim Gebart
Did the discussion about redundant parameter validations and DEVELHELP die?

I like the idea of getting rid of some redundant input validation. For
example, if you are internally using spi_transfer_byte to provide
spi_transfer_regs, then if the SPI device is valid for the first byte
transferred, then it is probably going to be valid for the rest of the
bytes in the same function call chain.

There was some discussion about null pointer checks in a PR or a
mailing list thread but I did not find it when I did a brief search.

Best regards,
Joakim Gebart
www.eistec.se


On Wed, Mar 25, 2015 at 5:02 PM, Kaspar Schleiser kas...@schleiser.de wrote:
 Hey,

 On 03/25/2015 11:12 AM, Hauke Petersen wrote:

 in general I like the idea, one problem I see is however, that is not
 always clear, to which level an API belongs (e.g. the GPIO API is
 definitely used also by high-level application programmers, while still
 belonging to the low-level peripheral drivers...).

 We could mark certain functions / parts of an API as advanced in the docs
 and provide safe alternatives.

 Seriously, it hurts to not be able to work around 10 redundant
 checks whether an int coming from flash is a correct SPI device...


 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] Association time in mobile RPL/6lowpan networks

2015-05-21 Thread Joakim Gebart
On May 21, 2015 8:37 AM, Cenk Gündogan cenk.guendo...@fu-berlin.de
wrote:

 Hey Adam,

 I am currently adopting RPL to our new network stack and while doing so,
 I also added sane functionalities which were plainly missing in the old
implementation.
 This also includes sending a DIS when initializing RPL for the first time.
 However,  I am just now realizing that such a DIS can get lost in our
typical LLN case - it may make sense to send a DIS periodically until a DIO
is received?
 Does anyone has an opinion on this?

Good idea, as long as the periodic interval is large enough to not waste
power or cause interruptions in normal traffic if there is no other rpl
node on the network.


 Forcing a DIS from userspace sounds like a good feature. It may help in
testing/debuging the dodag tree interactively.
 I also thought about reseting the trickle timer from userspace to enforce
DIOs.

+1 for this. It would be nice to have some shell commands to call these
functions too.

Best regards,
/Joakim


 Cheers,
 Cenk


 On 21.05.2015 04:36, Adam Hunt wrote:

 That's great. Is there any way to force a node to send a DIS message
from userspace?


 On Wed, May 20, 2015, 5:34 PM Oleg Hahm oliver.h...@inria.fr wrote:

 Hi Adam!

  Has anyone tested the amount of time it takes for a node (full or
reduced
  function) to join an RPL routed 6lowpan network? I realize that it's
very
  likely to vary quite a bit depending on the network, I'm just curious
if
  anyone has an approximate range.

 As you said: it depends quite a bit on the network and the parameters.
Since
 nodes on the current RPL implementation won't send proactively DIS
messages
 and the interval of sending DIOs increases, it will usually take just a
couple
 of seconds if you try to join the network right after bootup, but can
take
 more than one minute in a later phase.

 Cheers,
 Oleg
 --
 printk (KERN_ERR %s: Oops - your private data area is hosed!\n, ...)
 linux-2.6.6/drivers/net/ewrk3.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


[riot-devel] GSoC status

2015-05-21 Thread Joakim Gebart
Hello fellow developers,
Will there be public status updates from the GSoC projects during
their work or will all be revealed at the end of summer?
I am interested in all three projects and would like to know if I can
support the students in any way.

What is the time period that the students will be working on this?

Best regards,
Joakim Gebart
Managing Director
Eistec AB

Aurorum 1C
977 75 Luleå
Tel: +46(0)730-65 13 83
joakim.geb...@eistec.se
www.eistec.se
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] enums vs. macros

2015-05-13 Thread Joakim Gebart
gcc's -fshort-enums might do what you describe:

https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html:

-fshort-enums Allocate to an enum type only as many bytes as it needs
for the declared range of possible values. Specifically, the enum type
is equivalent to the smallest integer type that has enough room.

Warning: the -fshort-enums switch causes GCC to generate code that is
not binary compatible with code generated without that switch. Use it
to conform to a non-default application binary interface.

/Joakim

On Wed, May 13, 2015 at 8:12 AM, Oleg Hahm oliver.h...@inria.fr wrote:
 Dear replying IoTlers,

 some time ago I had a discussion with Martine on GitHub about the usage of
 enums for flags [1]. Martine convinced me that seems to be wise to prefer
 macros over enums here, to avoid alignment issues. However, it feels somehow
 wrong not to use enums for this purpose (it's easier for the developer *and*
 the compiler if a valid data type is chosen). Does anyone know a trick around
 the issues that Martine mentioned:
 Because flags have a width in memory that is in most cases smaller than
 sizeof(enum) (most bit fields I know of are 16 bits max, on most of our
 newer platforms, sizeof(enum) is however 32 bits). This results in every
 assignment needed to be cast to either uint8_t or uint16_t. With macros you
 don't need to cast since they are typeless.

 Making the enum packed makes it's width unpredictable in terms of alignment
 issues, when used in struct (which is not the case here, I know).

 Cheers,
 Oleg

 [1] https://github.com/RIOT-OS/RIOT/pull/2614#discussion_r28941692
 --
 panic (No CPUs found.  System halted.\n);
 linux-2.4.3/arch/parisc/kernel/setup.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] Implementing a new MAC protocol for IEEE 802.15.4

2015-05-12 Thread Joakim Gebart
On May 11, 2015 3:12 PM, Daniel Krebs m...@daniel-krebs.net wrote:

 Hi Joakim,


 +1 We use mostly Contiki-based applications presently and it would be
 a big improvement if it was possible to get ContikiMAC duty cycling
 working in RIOT as well.

 Who is we if I may ask? Just curious.

Sorry about that, I should have started with At Eistec, we use mostly
contiki...

BR, Joakim



 # Requirements

   * Mesh topology = no single-point-of-failure
 Is this not a requirement of the routing?

 Did you have a look at the IEEE 802.15.4 specification? It's assumed to
have a so called PAN coordinator that forces the network to a star
topology. It's extendable to a tree of stars, but still you need a PAN
coordinator in every region. This node is the mentioned single point of
failure and additionally has increased energy consumption.

 This is exactly what I don't want.


 # Ideas / Questions

   * Do we need broadcasting?

 Routing protocols might need it. RPL sends solicitation messages to
 ask for routing information.

 There are broadcasting schemes for the implementation I aim for, but they
don't come for free in terms of energy consumption, like e.g. on a network
bus. I'll elaborate about this later if you want.


   * Add multi-hop / routing later? Is this even reasonable?

 Some kind of routing will be necessary for any useful applications, at
 least some kind of hardware address to IPv6 address mapping must exist
 to fill the neighbor cache. (e.g. RPL, NDP)

 Sure. Hardware addresses are needed anyway to get your data delivered to
the destination node.


 Best regards,
 Daniel Krebs

 ___
 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] Implementing a new MAC protocol for IEEE 802.15.4

2015-05-11 Thread Joakim Gebart
On Mon, May 11, 2015 at 11:37 AM, Daniel Krebs m...@daniel-krebs.net wrote:
 Hello RIOTers,

 I want to use RIOT for a low-power 802.15.4 network project. Having a bit
 familiarized with RIOT and my samr21-xpro boards now I want to tackle my
 next milestone, i.e. I need a MAC protocol that fits my requirements (see
 below).

 As it seems that there are only 2 MAC implementations for now [1,2], both
 not what I'm searching for and also not merged, I decided to try this on my
 own.

 Therefore I studied some papers and existing MAC schemes to not reinvent the
 wheel. There is one nice paper [3] that sums up quite nicely the most basic
 duty-cycling schemes (p. 4ff).

 There are some adaptions and refinements to these protocols which might
 improve the throughput or energy-saving further, but I think that these
 basic schemes already provide a good starting point. Namely there is
 ContikiMAC [4] that incorporates these improvements.

 While I want to start implementing a basic and simple protocol first, I
 wonder if it could be nice for RIOT to have some ContikiMAC-compatible MAC
 layer later.

+1 We use mostly Contiki-based applications presently and it would be
a big improvement if it was possible to get ContikiMAC duty cycling
working in RIOT as well.


 I can't promise anything for now on how well this will work in the end, but
 I wanted to inform you about my undertaking and maybe you have some thought
 or pointers that could help me. As there is so much change in all over the
 network stack at the moment, it would be nice to know which (for me
 relevant) parts of the stack I should use that are not subject to change
 shortly.

 I gathered some notes and requirements, please find them below.

 Best regards,
 Daniel Krebs

 [1] https://github.com/rousselk/RIOT/commits/s-cosens
 [2] https://github.com/RIOT-OS/RIOT/pull/2467
 [3] http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4539479
 [4] http://dunkels.com/adam/dunkels11contikimac.pdf


 Requirements for MAC-layer
 ==

 # Requirements

  * Mesh topology = no single-point-of-failure

Is this not a requirement of the routing?

  * Low energy consumption
  * Relatively small single-hop network (~10 nodes)
  * New nodes can join and leave the network
  * No need to comply with IEEE 802.15.4 MAC schemes
  * No need for hard realtime
  * Should be reasonibly simple to implement

 # Ideas / Questions

  * Do we need broadcasting?

Routing protocols might need it. RPL sends solicitation messages to
ask for routing information.

  * Add multi-hop / routing later? Is this even reasonable?

Some kind of routing will be necessary for any useful applications, at
least some kind of hardware address to IPv6 address mapping must exist
to fill the neighbor cache. (e.g. RPL, NDP)

  * Do we really need adaption to traffic load?
  * Find out which APIs to use in RIOT to have a modular MAC protocol that
 might
work with multiple transceivers

 # Observations

  * Requirements seem to match ContikiMAC, so maybe aim for compatibility?

Yes!


 # Implementation

  * Duty cycle nodes for energy saving
  * LPEAS = Implicit synchronization
  * Use 802.15.4 features, so this might only work with 802.15.4 networks
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel


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


Re: [riot-devel] LPM idle_thread

2015-05-09 Thread Joakim Gebart
See https://github.com/RIOT-OS/RIOT/issues/2927
It's not yet been developed fully, those are just place holders. I have
proposed to use a more dynamic scheme for the LPM modes.

Best regards, Joakim
www.eistec.se
On May 9, 2015 6:40 PM, Frank Holtz frank-riot2...@holtznet.de wrote:

 Hello,

 why is LPM_SLEEP or LPM_POWERDOWN is commented out?

 kernel_init.c:
 ---
 static void *idle_thread(void *arg)
 {
 (void) arg;

 while (1) {
 if (lpm_prevent_sleep) {
 lpm_set(LPM_IDLE);
 }
 else {
 lpm_set(LPM_IDLE);
 /* lpm_set(LPM_SLEEP); */
 /* lpm_set(LPM_POWERDOWN); */
 }
 }

 return NULL;
 }
 ---

 ___
 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] WDT questions

2015-04-29 Thread Joakim Gebart
It has to do with the difficulty of providing a reliable way of poking the
watchdog in an event driven, tickless, system such as RIOT. Maybe it is
time to start discussing a watchdog api?
In order to get any traction within industry applications I believe it will
be necessary to at least provide an api for applications to use the
watchdog.

Best regards,
Joakim Gebart
Eistec AB
www.eistec.se
On Apr 29, 2015 2:43 PM, Baptiste Clenet bapcle...@gmail.com wrote:

 Hi,

 I've got two questions concerning WDT:
  - Why do we disable it on the samr21 at launch time?
  - Why doesn't RIOT provide a wdt.h in drivers/include/periph?

 Cheers,

 --

 *Clenet 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] WDT questions

2015-04-29 Thread Joakim Gebart
An idea:
Create a multi-channel software watchdog that in turn pokes the hardware
watchdog when all parameters are met.
We could configure different timeouts for different channels and each
critical process can have its own channel(s) which they update
independently.

Some risks of this approach is that it will be possible for software errors
to make the software watchdog misbehave and poke the hardware watchdog and
keep the system running when it should be reset.

Best regards,
Joakim
Thanks for your explanations. I understand why it is counter productive.
But how RIOT will make sure that the board is not stuck in a deadlock? This
is mandatory for industrial context.

Cheers,


2015-04-29 15:07 GMT+02:00 Joakim Gebart joakim.geb...@eistec.se:

 It has to do with the difficulty of providing a reliable way of poking the
 watchdog in an event driven, tickless, system such as RIOT. Maybe it is
 time to start discussing a watchdog api?
 In order to get any traction within industry applications I believe it
 will be necessary to at least provide an api for applications to use the
 watchdog.

 Best regards,
 Joakim Gebart
 Eistec AB
 www.eistec.se
 On Apr 29, 2015 2:43 PM, Baptiste Clenet bapcle...@gmail.com wrote:

 Hi,

 I've got two questions concerning WDT:
  - Why do we disable it on the samr21 at launch time?
  - Why doesn't RIOT provide a wdt.h in drivers/include/periph?

 Cheers,

 --

 *Clenet 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




-- 
*Clenet 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] broken archives?

2015-04-02 Thread Joakim Gebart
I am also seeing this for http://riot-os.org/pipermail/devel/. The
root site (http://riot-os.org) still works.

I think the URL is configured wrong in mailman.
https://lists.riot-os.org/pipermail/devel/ works for me.

As an alternate archive you can also use gmane:
http://news.gmane.org/gmane.os.riot.devel

Regards,
Joakim Gebart
www.eistec.se


On Thu, Apr 2, 2015 at 3:40 PM, Julien Vermillard jvermill...@gmail.com wrote:
 still,
 it's sending me to http://riot-os.org/pipermail/devel/ with a NGINX 404 page

 On Thu, Apr 2, 2015 at 3:37 PM Emmanuel Baccelli
 emmanuel.bacce...@inria.fr wrote:

 Hi Julien
 does it still do that for you? On my end, it works perfectly well.
 Best,
 Emmanuel

 On Thu, Apr 2, 2015 at 3:27 PM, Julien Vermillard jvermill...@gmail.com
 wrote:

 Hi,
 I tried to consult this mailing list archives, but the archive link on
 this page:
 https://lists.riot-os.org/mailman/listinfo/devel return a 404

 Julien

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


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


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

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


Re: [riot-devel] Removing thirdparty repositories

2015-03-22 Thread Joakim Gebart
I haven't looked too closely, but I think at least the ideas put
forward in https://github.com/RIOT-OS/thirdparty_cpu/pull/3 are
useful. The PRs are old so they probably won't work on the current
master but the LPM stuff is interesting.
On the thirdparty_boards repo I didn't find anything interesting.

Best regards,
Joakim Gebart
www.eistec.se


On Sun, Mar 22, 2015 at 12:12 AM, Oleg Hahm oliver.h...@inria.fr wrote:
 Dear rousing IoTlers,

 since we don't need the thirdparty repositories for CPUs and boards any more
 for quite some time, I think we should finally remove them. Any objections?
 Can anyone with some experience with the Cortex ports take a look at the PRs
 in these repos that are still open and see if they contain anything useful
 that might be applied to the current implementation in RIOT master?

 Cheers,
 Oleg
 --
 arrival order packet joke is critical to good a make

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

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


Re: [riot-devel] Repository for Docker builds

2015-03-21 Thread Joakim Gebart
On Sun, Mar 22, 2015 at 12:18 AM, Oleg Hahm oliver.h...@inria.fr wrote:
 Hi!

  Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or
  Matthias Wählisch) create the repo since maintainers do not have the proper
  access to do it.

 Sure, I can do so. Let's wait if no one objects against the proposed name.

 This somehow disappeared from my radar. I think you need to give me admin
 access to the repository in order to move it to the RIOT organization (and
 rename it to riotdocker).

What do you mean?
If you create a new empty riotdocker repo in the RIOT organization we
can push the Dockerfile commits to it.


 Cheers,
 Oleg
 --
 /* The HME is the biggest piece of shit I have ever seen. */
 linux-2.6.6/drivers/scsi/esp.h

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

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


[riot-devel] Radio duty cycling

2015-03-17 Thread Joakim Gebart
Hello RIOTers,
What is the current state of radio duty cycling in RIOT?
I know that radio drivers implement on and off functions for the chip, but
how do we make the best use of them?
​In order to reduce power consumption it will be necessary to duty cycle
the radio​
​.
​

​For comparison, in
​Contiki there are multiple RDC drivers that can be switched​ between at
compile time, the most well-known is ContikiMAC [1]. Something similar
would be very useful in battery powered scenarios for RIOT.

[1]: http://dunkels.com/adam/dunkels11contikimac.pdf

Best regards,
Joakim Gebart
Eistec AB
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] NSTF radio driver

2015-03-17 Thread Joakim Gebart
Hi Thomas,

On Fri, Feb 20, 2015 at 10:53 AM, Thomas Eichinger
thomas.eichin...@fu-berlin.de wrote:
 Hi Joakim,

 On 20 Feb 2015, at 9:31 CET(+0100), Joakim Gebart wrote:

 Thank you for the prompt response. I will start reading the existing
 drivers but I think I will wait at least until there is a PR for the rf231
 before I begin my implementation work.

 As Peter mentioned I'm working hard on refactoring the rf2xx driver. As we
 want to use it on EmbeddedWorld on Tuesday you can expect a PR for this
 soonish. :-)

How is the new rf2xx driver coming along?

I have been seeing some memory corruption problems on my platform and
I think it originates somewhere in the radio stack, but I have not
managed to pinpoint it further. I would like to test the new driver
before I spend more time chasing down a bug that might have already
been fixed in the refactoring process.

Is there any WIP branch we can look at?
Do you have any ETA for a PR?

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


Re: [riot-devel] kinetis common - differences between families

2015-03-14 Thread Joakim Gebart
For the kw01 you should look at the PR that the Phytec guys are working on
(Johann Fischer and Jonas Remmert et.al.) which can be found at
https://github.com/RIOT-OS/RIOT/pull/2328

Best regards, Joakim
On Mar 14, 2015 2:00 PM, Jozef Maslik ma...@binarylemon.com wrote:

 Hi,

 @Joakim, It is not easy question :)

 In short, we can say, there are differences between families based on core
 type but it is not true for all options. MCUs with core Cortex M4 have
 different modules compare to Cortex M0+ and here is difference compared to
 L0x family which use some modules from FSL 8bit parts (SPI, UART, timers…)

 Some example with major differences:
 SPI has min 3 variants: DSPI (K family), SPI (L, M family), SPI(L0x family)
 UART has min 3 variants: 1. K, M family, 2. L family, 3. L0x family
 low power UART is in L families (except L0x)

 Some functionality (as @Joakim wrote) can be handled by conditional
 compilation like KINETIS_UART_ADVANCED, but I think, some extended
 functionality can be omitted because it is not interesting for our use case.

 But I think, best way is to say, which families are interesting for RIOT
 OS and compare only these. Maybe wiki page can be helpful for this task.

 At this moment, I’m working with Cortex M0+ families (which are not
 supported on RIOT yet) - I have port on KL02 and in future I want to do
 port for KW01 (if someone else do not do it).

 From my point of view, best option is to have one common kinetis_family
 directory with all driver regardless of the family.

 Jozef

  On 14 Mar 2015, at 09:49, Joakim Gebart joakim.geb...@eistec.se wrote:
 
  We have used some conditional compilation in drivers where the
  differences have been somewhat manageable. See the UART driver for
  example. If the entire module is different then I guess I would prefer
  to have two separate C-files for the two solutions rather than forking
  the entire kinetis_common directory, because there are still many
  other modules which are the same between the processors. We have used
  such an approach for the RNGA, RNGB modules which are two different
  RNG modules which are present in the Kinetis processors. In the long
  run I think we will benefit more from each others' work if we try to
  keep all of the Kinetis code concentrated to one directory. If you
  look at the stm32fx cpu implementations you will find that there are
  some features only implemented in one of them and it is difficult to
  say which one is most up-to-date since different developers are using
  different CPUs to test their design and then they don't always port it
  to the other CPUs within the same family.
 
  Jozef: Do you know which modules are different and will need new
  drivers rather than only cpu-conf.h modifications?
 
  Below is a list of the currently implemented hardware drivers, as far
  as I know, they are fully functional on K60, KW22 (K20 with built-in
  transceiver), KW02 (based on some K0x, with built-in transceiver), and
  another K20 (unknown exact model):
  - ADC
  - CPUID (called UID in SIM module reference manual)
  - GPIO
  - hwtimer (uses LPTMR module)
  - I2C
  - MCG (supports all of PLL, FLL, fast and slow internal ref)
  - PWM (uses FTM module)
  - RNGA
  - RNGB
  - RTT (RTC module)
  - RTC (wrapping RTT)
  - SPI (DSPI module)
  - Timer (PIT module)
  - UART (conditionally compiling for some extra features present in
  the K60, K20, but not present in the KW0x, via #define
  KINETIS_UART_ADVANCED)
 
  Out of the supported CPUs, the KW0x is the oddest one since that has a
  M0+ core instead of an M3/M4.
 
  Best regards,
  Joakim Gebart
  Eistec AB
  www.eistec.se
 
  On Mar 13, 2015 7:57 PM, Hauke Petersen hauke.peter...@fu-berlin.de
 wrote:
 
  Hi Jozef,
 
  I have to say I was more or less expecting these slight differences...
 
  The RIOT way to go would be option 3. This is already done for the
 STM32Fx CPUs.
 
  Of course this leads to some duplication of code, but in the end it
 leaves the overall folder structure very clean and it is always clear,
 where the code you are currently building is coming from. In my opinion a
 finer grained dependency-tree like kinetis-common - kinetis-k-common -
 k60 on so on would lead to a structure that is as hard to maintain as some
 duplicated code...
 
  @gebart and @jfischer: would that solution work for you?
 
  Cheers,
  Hauke
 
  On 13.03.2015 19:47, Jozef Maslik wrote:
 
  Hi,
 
  How we want deal with the difference between variants of peripherals
 in Freescale Kinetis families (I mean, what is RIOT OS prefered way)? Here
 is difference between families - for example between K family vs L family.
 And if I remember correctly ;), there can be difference between specific
 chips in same family, too.
 
  For example SPI, kinetis_common contain driver spi.c but module on K60
 is different compare to KL02 or KL10, etc.
  Here can be few options (minimal three ;)):
  1. rename spi.c to real module name, at this situation it can be
 “DSPI” for K

Re: [riot-devel] kinetis common - differences between families

2015-03-14 Thread Joakim Gebart
We have used some conditional compilation in drivers where the
differences have been somewhat manageable. See the UART driver for
example. If the entire module is different then I guess I would prefer
to have two separate C-files for the two solutions rather than forking
the entire kinetis_common directory, because there are still many
other modules which are the same between the processors. We have used
such an approach for the RNGA, RNGB modules which are two different
RNG modules which are present in the Kinetis processors. In the long
run I think we will benefit more from each others' work if we try to
keep all of the Kinetis code concentrated to one directory. If you
look at the stm32fx cpu implementations you will find that there are
some features only implemented in one of them and it is difficult to
say which one is most up-to-date since different developers are using
different CPUs to test their design and then they don't always port it
to the other CPUs within the same family.

Jozef: Do you know which modules are different and will need new
drivers rather than only cpu-conf.h modifications?

Below is a list of the currently implemented hardware drivers, as far
as I know, they are fully functional on K60, KW22 (K20 with built-in
transceiver), KW02 (based on some K0x, with built-in transceiver), and
another K20 (unknown exact model):
 - ADC
 - CPUID (called UID in SIM module reference manual)
 - GPIO
 - hwtimer (uses LPTMR module)
 - I2C
 - MCG (supports all of PLL, FLL, fast and slow internal ref)
 - PWM (uses FTM module)
 - RNGA
 - RNGB
 - RTT (RTC module)
 - RTC (wrapping RTT)
 - SPI (DSPI module)
 - Timer (PIT module)
 - UART (conditionally compiling for some extra features present in
the K60, K20, but not present in the KW0x, via #define
KINETIS_UART_ADVANCED)

Out of the supported CPUs, the KW0x is the oddest one since that has a
M0+ core instead of an M3/M4.

Best regards,
Joakim Gebart
Eistec AB
www.eistec.se

On Mar 13, 2015 7:57 PM, Hauke Petersen hauke.peter...@fu-berlin.de wrote:

 Hi Jozef,

 I have to say I was more or less expecting these slight differences...

 The RIOT way to go would be option 3. This is already done for the STM32Fx 
 CPUs.

 Of course this leads to some duplication of code, but in the end it leaves 
 the overall folder structure very clean and it is always clear, where the 
 code you are currently building is coming from. In my opinion a finer grained 
 dependency-tree like kinetis-common - kinetis-k-common - k60 on so on would 
 lead to a structure that is as hard to maintain as some duplicated code...

 @gebart and @jfischer: would that solution work for you?

 Cheers,
 Hauke

 On 13.03.2015 19:47, Jozef Maslik wrote:

 Hi,

 How we want deal with the difference between variants of peripherals in 
 Freescale Kinetis families (I mean, what is RIOT OS prefered way)? Here is 
 difference between families - for example between K family vs L family. And 
 if I remember correctly ;), there can be difference between specific chips 
 in same family, too.

 For example SPI, kinetis_common contain driver spi.c but module on K60 is 
 different compare to KL02 or KL10, etc.
 Here can be few options (minimal three ;)):
 1. rename spi.c to real module name, at this situation it can be “DSPI” for 
 K family and “SPI” for L family.
 - exact name for K60 SPI module is “DSPI, then rename spi.c to dspi.c solve 
 this major issue
 - module name for SPI on L family is simply “SPI”
 - I prefer this solution…

 2. conditional compilation for different MCUs (one spi.c file)
 - this will be mess in code, because modules are too much different
 - I do not like this solution

 3. another “common” directory - for each family
 - this can produce code duplication

 Regards,
 Jozef
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel


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


Re: [riot-devel] Google Summer of Code 2015

2015-03-12 Thread Joakim Gebart
We have been getting quite a lot of students introducing themselves on the
mailing lists now. How many students can be accepted? Who decides on which
students are accepted? Google or RIOT?

Best regards, Joakim
On Mar 4, 2015 4:41 PM, Emmanuel Baccelli emmanuel.bacce...@inria.fr
wrote:

 Hi everyone,

 we are happy to announce that RIOT was selected as mentoring open source
 organization for Google Summer of Code 2015.

 In short: this means that students are welcome to apply for (paid) project
 work in this context, to further develop RIOT, over the summer. For more
 details see [1].

 Don't hesitate to forward this call for applications to students you know
 who may be interested in RIOT, and/or to apply if you are a student
 yourself!

 Student application opens March 16th and closes March 27th. But note that
 if you plan to apply, we recommend that you come forward even before this
 period, to share/shape ideas for your project (see process/templates
 below). Basically: you should engage a technical discussion with the RIOT
 community on devel@riot-os.org, as soon as possible.

 Templates for applications form can be found at [2], and GSOC project
 ideas for RIOT can be found at [3]. Note that these are just suggestions,
 and that you are welcome to propose your own project ideas!

 Cheers,

 Emmanuel


 [1] https://www.google-melange.com/gsoc/homepage/google/gsoc2015
 [2] https://github.com/RIOT-OS/RIOT/wiki/GSOC-Student-Application-Template
 [3] https://github.com/RIOT-OS/RIOT/wiki/GSOC-Idea-List

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


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


Re: [riot-devel] Repository for Docker builds

2015-02-24 Thread Joakim Gebart
riotdocker is more descriptive for the github repo name, I like it.

Best regards, Joakim
On Feb 24, 2015 8:20 AM, Oleg Hahm oliver.h...@inria.fr wrote:

 Hi Joakim!

  What is a suitable name for the new repo?
  I have been using riotbuild for my Docker development at
  https://github.com/gebart/riotbuild

 I don't have any particular ideas for the name, so, for me riotbuild (or
 riotdocker) would be fine.

  Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or
  Matthias Wählisch) create the repo since maintainers do not have the
 proper
  access to do it.

 Sure, I can do so. Let's wait if no one objects against the proposed name.

 Cheers,
 Oleg
 --
 The problem with git jokes is everyone has their own version.

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


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


[riot-devel] NSTF radio driver

2015-02-19 Thread Joakim Gebart
Dear RIOT developers,
 - Which radio driver is the most up to date with regards to the
network stack restructuring work being done in #2278?
 - How stable is the radio device API currently? Are there any more
API changes coming?
 - Would it be wise to wait until the restructuring todo list is
mostly checked off until starting work on implementing a new radio
device driver?
 - Which driver would be best to use as an example of a fully
compliant radio driver?

I am looking at implementing a driver for a new radio chip, but I do
not want to have to redo the work again in a couple of weeks because
of the network refactoring...

https://github.com/RIOT-OS/RIOT/issues/2278

Best regards,
Joakim Gebart
Managing Director
Eistec AB

Aurorum 1C
977 75 Luleå
Tel: +46(0)730-65 13 83
joakim.geb...@eistec.se
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] reserve main and let application define thread(s)

2015-02-14 Thread Joakim Gebart
On Sat, Feb 14, 2015 at 3:28 PM, Kaspar Schleiser kas...@schleiser.de wrote:

 Hi,

 On 02/14/15 12:28, Ludwig Ortmann wrote:

 I created quickdirty branches for both methods:

 plain c:
 https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-application-init
 macro magic:
 https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-make

 Not sure which one I dislike better ;)

I like the main-application-init version because it is still somewhat
simple to follow. Perhaps it would be possible to still keep the
trampoline but make it execute application_init instead of main and
let auto_init() execute from the trampoline. This eliminates the need
to modify the example applications.


 ;)

 I think we should come up with a method that enables inclusion of multiple 
 application threads. Maybe we can even replace auto_init in the process.

 We could have something like

 struct _auto_thread {
 char* name;
 char* stack;
 int stacksize;
 ...
 };

 struct _auto_threads[] = {
   {idle, idle_stack, STACKSIZE_IDLE, PRIORITY_IDLE, NULL },
   {default, main_stack, STACKSIZE_MAIN, PRIORITY_MAIN, NULL },
   {application, app_stack, ... }
 };

 The second struct we create during the build process and write it to a file 
 that gets includes by kernel_init.c. There, we just traverse the list in 
 order to start the threads.

 For the makefiles we devise a way to declare these threads. Maybe something 
 easily parsable like

 THREADS += 
 (application;PRIORITY_MAIN+1;STACKSIZE_MAIN+STACKSIZE_PRINTF;dependency1,transceiver)

 ... with a lot of sensible defaults so John Duino can just do

 THREADS += my_app

 We could also introduce some kind of image build description file that 
 holds the necessary thread configuration:

 E.g., defining one thread named default using a default stacksize, default 
 function name (default_thread), with a dependency on transceiver:
 - examples/default/default.yaml:
 default:
 depends: [ transceiver ]
 -

 Defaults and modules:
 - modules.yaml:
 _defaults:
 stacksize: STACKSIZE_MAIN

 transceiver:
 depends: [ pkt_buf ]
 stacksize: INTERESTING_DEFINE

 dumb_module:
 thread: false # this module doesn't have a thread
 init: true # we will call dumb_module_init on bootup
 -

 All that we parse and auto-generate the corresponding C code.

 Not sure if we're entering a world of pain this way. ;)

This is a good looking solution for a large project with a clear and
well-specified build environment etc. but I think in this case we will
be over-complicating the build system.

BR,
Joakim Gebart
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] How low can you go?

2015-02-06 Thread Joakim Gebart
On Fri, Feb 6, 2015 at 10:10 AM, Thomas Eichinger
thomas.eichin...@fu-berlin.de wrote:
 Hi,

 On 06 Feb 2015, at 09:36, Ludwig Ortmann ludwig.ortm...@fu-berlin.de wrote:

 Hi,

 On Fri, Feb 06, 2015 at 09:03:31AM +0100, Oleg Hahm wrote:
 Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt:
 There's already a driver for for Atmel's AT86RF231 in the tree and while
 the AT86RF230 on the Raven boards are nearly the same the 230 lacks a
 couple minor features, namely a crypto processor and RNG. So, the RF link
 would be wide open but for experimentation and learning sacrifices are
 often necessary.

 As far as I know there were some considerations and work done towards a
 generic AT86RF23x or even AT86RF2xx driver. Thomas, am I right?

 Yes, I'm working on that (almost done).
 Yes, I will take up work on this again next week, as we have a stable netdev
 interface by today.


That's great news!
I have seen some compatibility issues when I have been attempting to
use the 231 driver for the 212B (sub-GHz band), but I assume this is
because every limit etc. is configured to work with the 2.4 GHz
register values on the 231.

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


Re: [riot-devel] thread is not working

2015-01-14 Thread Joakim Gebart
You can look at the startup files for other CPUs for a proper way of
doing initialization e.g. cpu/stm32f1/startup.c
Note that you must also make sure that your linker script provides the
correct symbols at the beginning and end of .data and .bss.

Best regards,

Joakim Gebart
Eistec AB
www.eistec.se 

On 01/13/2015 10:45 PM, Ryan Kurte wrote:
 Hi Shishir,

 I seem to recall having the same issue when starting the EFM32 port.
 The issue in my case was that without the startup files, the .bss
 section was not getting cleared.
 When the threads came to launch, the value in one of the kernel
 functions was not correct. Which is pretty easy to check with a debugger.

 The fix was to clear the .bss section in the _init routine, my
 implementation (using symbols from the linker) is:

 //Clear bss
 for (uint32_t i = (uint32_t)__bss_start__; i 
 (uint32_t)__bss_end__; i++) {
 addr = (int*)i;
 *addr = (int)NULL;
 }

 I am not sure this is the /correct/ way to do it, but the .bss
 definitely needs to be initialised to zeros.

 Hope that helps,

 Ryan

 On 14 January 2015 at 07:56, Hauke Petersen
 hauke.peter...@fu-berlin.de mailto:hauke.peter...@fu-berlin.de wrote:

 Hi,

 On 13.01.2015 19:04, shishir tiwari wrote:

 Hi petersen,

   Thanks for your information.

 we are trying to put your method but still is it not working.
 we are
 studying and doing some experiments.

 one more question : In hwtimer_init()-- hwtimer_arch_init()
 this need
 to be implemented in harsware is compulsory?? for scheduling
 to work?

 nope, the timer is generally not needed for scheduling.

 Cheers,
 Hauke





 thanks
 shishir tiwari

 On Mon, Jan 12, 2015 at 10:01 PM, Hauke Petersen
 hauke.peter...@fu-berlin.de
 mailto:hauke.peter...@fu-berlin.de wrote:

 Hi Shishir,

 when RIOT initially starts up, the CPU is normally running
 in interrupt mode
 (using the interrupt mode stack). After creating the
 stacks for the main and
 the idle threads, the CPU must be put into thread-mode.
 This means the main
 threads initial context needs to put into the CPUs
 registers and the stack
 pointer must put to the main-threads stack. After this is
 done the CPU can
 just do 'normal' task switching for switching between threads.

 So to put it short: in cpu_switch_context_exit() you
 simply must load the
 main threads context into the CPUs register and point the
 stack pointer to
 the main threads stack.

 Let me know if you need further information!

 Cheers,
 Hauke



 On 12.01.2015 15:35, shishir tiwari wrote:

 Hey Everyone,

 I have been porting RIOT OS to new processor(ARC) and
 i had compilied
 hello world program successfully.
 When i debug the helloworld.elf in kernel_init
 function the
 thread_create() function has execute successfully.But
 the thread
 idle_thread and main_trampoline function is not
 been called. why?

 What is thing need to be done on this
 cpu_switch_context_exit()
 function. please explain me.


 Thanks
 Shishir Tiwari
 ___
 devel mailing list
 devel@riot-os.org mailto:devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel


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

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


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




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

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


Re: [riot-devel] hwtimer implementation for Freescale MKW2xDxxx

2014-12-12 Thread Joakim Gebart
Hello Johann,

I am developing for the K60 which has the same timer set up as the KW2x.
The solution that I decided to go for is to let the LPTMR run at 32768
Hz and let the hwtimer use that one. It will not allow for 1 µs
precision, but at least it will be able to wake the MCU from STOP modes.
I have not yet made a PR from my work, but you can see the current WIP
state at https://github.com/gebart/RIOT, mulle branch.

Would there be any interest in merging the K60 and the KW2x peripherals
into a single Kinetis port?

See also some earlier threads regarding the Kinetis timers:

http://lists.riot-os.org/pipermail/devel/2014-November/001426.html
http://lists.riot-os.org/pipermail/devel/2014-October/001219.html
http://lists.riot-os.org/pipermail/devel/2014-September/001086.html

Best regards,

Joakim Gebart
Eistec AB
www.eistec.se 

On 12/12/2014 11:14 AM, Johann Fischer wrote:
 Hello RIOTers,

 I tried to implement a hwtimer for MKW2xDxxx and failed.

 The MCU has 4 downcounter PIT(Periodic Interrupt Timmer) 32-bit timers,
 PITs can be cascaded so that timer[0] acts as prescaler for timer[1].
 PIT can be loaded with a start value. The timer will count down and
 generate an interrupt at 0. Then the start value will be reloaded and
 it will repeating. PITs can not run in low power modes.
 Apart from the fact that it is a down counter, the timer do not work in
 low power mode, and that bothers me.

 The MCU has also one Low-Power
 Timer. This one is a upcounter 16-bit timer with compare register and
 can be configured as as Free-Running Counter (reset on overflow not on
 compare match). Also LPTMR can run in (very) low power modes.
 I tried to implement the hwtimer with LPTMR.
 The implementation divided (or multiply) the tick-values by 1000 and run
 the timer with 1kHz. But this does not work reliable.

 There is also a RTC module, but it fits even less for the hwtimer.

 Ideas?

 Regards,
 Johann Fischer
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

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


[riot-devel] Basing my cpu/board port off existing ports

2014-12-09 Thread Joakim Gebart
What is the correct procedure regarding author and copyright headers
when I write a new port, but base the file off another port?

For example:
I start by copying the cpu/stm32f1 directory, as a basis for my new port.
The CPUs share no code other than RIOT generic code, such as API
(function declarations etc.).
Looking at cpu/stm32f1/lpm_arch.c [1], it has the following copyright header:

/*
* Copyright (C) 2013 INRIA
* Copyright (C) 2014 Freie Universität Berlin
*
* This file is subject to the terms and conditions of the GNU Lesser General
* Public License v2.1. See the file LICENSE in the top level directory for more
* details.
*/

/**
* @ingroup cpu_stm32f1
* @{
*
* @file lpm_arch.c
* @brief Implementation of the kernel's lpm interface
*
* @author Alaeddine Weslati alaeddine.wesl...@inria.fr
* @author Hauke Petersen hauke.peter...@fu-berlin.de
*
* @}
*/

All the functions in this file contain a single line `/* TODO */`, so
this file is only a stub necessary for building the project.

If I then implement all the functionality for the lpm functionality,
should I then add myself/my company as author and copyright or do I
leave the FU berlin stuff? Should I both add myself and keep the old
copyright? Should I remove the old copyright? What about @author
lines?

My gut feeling is that the correct way (legally) for me to implement
my own lpm_arch.c is to add Copyright (C) Eistec AB as a new line
below (C) FU Berlin as well as adding an @author line to the file
Doxygen block. This means that this file would end up with three
copyright lines, and three authors, of whom only one knows anything
about the code it contains.

[1]: https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f1/lpm_arch.c

Best regards,
Joakim Gebart
Managing Director
Eistec AB

Aurorum 1C
977 75 Luleå
Tel: +46(0)730-65 13 83
joakim.geb...@eistec.se
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] Clarification on netdev netapi etc.

2014-12-07 Thread Joakim Gebart
I see the terms netdev, netapi, pktbuf and more around the mailing
lists and issue tracker, and I have understood that some of these
terms refer to deprecated APIs and modules in RIOT, and some of them
are referring to new APIs and modules.
The page at https://github.com/RIOT-OS/RIOT/wiki/Model-for-the-network-stack
describes some classes and use cases, and I believe it applies to the
newer implementation.

Could someone explain briefly some of the most used terms and what are
the different APIs for network in RIOT and how they relate to each
other?
What documentation/source code files and directories are relevant?
Which parts are deprecated/obsolete/on its way out?

Best regards,
Joakim Gebart
Managing Director
Eistec AB

Aurorum 1C
977 75 Luleå
Tel: +46(0)730-65 13 83
joakim.geb...@eistec.se
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] 802.15.4 SPI transceiver

2014-12-02 Thread Joakim Gebart
There doesn't seem to be an existing RIOT driver for the MRF24J40MA.
If you are not locked to that particular chip you have the AT86RF2xx
which is also SPI and seem to have a quite actively maintained RIOT
driver (it is used in the IoT-Lab_M3).

Best regards,
Joakim Gebart
Eistec AB
www.eistec.se


On Tue, Dec 2, 2014 at 5:07 PM, Martin martin.landsm...@haw-hamburg.de wrote:
 Hi all,

 we searched for a suitable 802.15.4 transceiver with SPI interface to play
 around on e.g. the stm32f4discovery, and came across the MRF24J40MA [1].

 Has anyone experience with the device?

 Best regards,
 Martin

 [1] http://www.farnell.com/datasheets/526949.pdf
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Separating module drivers from physical pin configuration

2014-12-01 Thread Joakim Gebart
Dear Thomas,

Thank you for your feedback, see my response inline below.

On Mon, Dec 1, 2014 at 11:32 AM, Thomas Eichinger
thomas.eichin...@fu-berlin.de wrote:
 Dear Joakim,

 On 30 Nov 2014, at 18:02, Joakim Gebart joakim.geb...@eistec.se wrote:
 I would like to have a separate driver for setting up the CPU pin mux.
 That is, separate the CPU logic module drivers (such as SPI, I2C, UART
 etc.) from the actual hardware ports and pins.

 You mean introducing a central point to handle all the PIN initialisation for
 the other peripherals? “Mux-driver, initialise pins for UART3!”

I would expect that reconfiguring pin function muxing in the middle of
a running application would be a quite uncommon use case, so I would
expect something like during board init, I would call something like
Mux-driver, initialize all pins according to board config X. And
then the module drivers would not need to worry about which signal
goes to what pin, only generating the signals.


 By improving the separation/abstraction it may make it easier use the
 same board directory for multiple variations of the same board, where
 the on board peripherals are the same, or almost the same, and only
 some minor additions.

 I see your point here, but couldn’t it be realised by using some different
 configuration in periph_conf.h separated by preprocessor guards? Like:

 ```C
 #ifdef MULLE_v1
   #define SPI0_MISO_PIN PA12
   ...
 #elif MULLE_v1.2
   #define SPI0_MISO_PIN PB09
   ...
 #endif
 ```

Yes, I guess you are right about the preprocessor conditionals, but
there are some applications where you may want to configure something
only a tiny bit different, e.g. rerouting the debug UART to another
pin in the RPL border router, to let the default UART only handle SLIP
traffic, and connect an extra UART cable to your PC only when you need
the debug output. It is of course achievable by the traditional model
as well, but if I know that all pin configs are done at a particular
moment, and according to the config, then I do not have to worry about
in what order I initialize drivers.


 Because of the hardware function muxing capabilities in advanced MCUs
 is usually in a separate module it is only logical that the driver for
 a CPU module does not need to know anything about which pin numbers on
 the IC is connected to its signals, the driver should only control the
 logic within its own module.

 The peripheral interface currently tries to exploit the greatest possible
 common set of functionality while minimising overhead. Since such a mux-driver
 would mainly be used in the other peripheral drivers it could be optional.
 Also it would need evaluation of the impact on more constraint platforms
 (cortex-M0 etc.) in terms of memory and clock rate.

This is kind of a board/cpu software architecture design decision, I
am merely looking for merits and deficiencies with this model.

The main point of splitting it up is a logical division of
responsibilities between software components. Since the pin function
mux is its own hardware module it is only logical that it has its own
driver, instead of letting all other drivers poke around inside it at
will. Every driver in the current implementations is designed to
handle its own hardware module, except it has to touch the pin muxing
as well. Every driver also does basically the same thing during
initialization, which means code duplication and risks for
copy-and-paste errors or code rot. The outline of most drivers' init
functions is:

1. Enable clock gate to I/O port/pin
2. Set pin mux to correct choice.
3. Enable clock gate to CPU module
4. Initialize CPU module configuration registers.

The main change would be that steps 1 and 2 are handled in a central
place = possibly less ROM usage.


 I like the idea in general but could you elaborate a little bit more on the
 concrete use case and implementation so we can discuss this in more detail.


I don't have an implementation yet, still working on the best approach
to do it, and whether it is a good choice, hence this thread.

 Best, Thomas



Best regards,
Joakim Gebart
Eistec AB
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel