Re: [riot-devel] Notification: Hack'n'ACK @ Tue Aug 25, 2015 5pm - 10pm (RIOT Events)
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 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=VIEW&eid=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?
You misread. https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications RPi2 has 1 Gigabyte RAM, not Megabyte. /JG On Thu, Aug 13, 2015 at 3:41 AM, Zac Harvey wrote: > Kaspar & Adam, > > Thanks for the ideas (lejos and non-JVM langs). I am already in touch with > the lejos admin. > > All, > > An earlier suggestion was to investigate SOCs like Raspberry Pi or > BeaglBoard. At first I thought: OK this is exactly what I need! But now > that I'm really thinking about it, there's something that leaves me feeling > uneasy here. > > So the main argument against the ARM SAM3X8E for a JVM is that it only has > 512KB ROM and 96KB RAM. But after researching the RaspberryPi, the later > models are using an ARM Cortex-A7 CPU that, according to Wikipedia it has > 1MB RAM. So this doesn't make sense: why is RaspberryPi touted as a > JVM-capable ARM-based SOC, whereas SAM3X8E is totally incapable of such a > feat (nothing in the modern Java landscape will run on 1MB). > > Clearly I'm missing something here, but: what is the difference between > RapsberryPi's ARM processor vs SAM3X8E that makes it capable of running a > Java app?!? > > Thanks, > Zac > > > > > On 8/12/15 2:30 PM, Adam Hunt wrote: > > While I applaud the idea of getting something as heavyweight as a JVM to run > on the type of devices that most of us on this list are targeting have you > thought about non-JVM languages? I've often wondered how small of a system > Erlang could be persuaded to running on. > > On Wed, Aug 12, 2015 at 4:47 AM Kaspar Schleiser > wrote: >> >> Hey, >> >> On 08/12/2015 01:36 PM, Zac Harvey wrote: >> > still planning on using RIOT-OS if it all possible. >> >> When you're evaluating embedded JVMs, take a look at the VM used by >> leJOS. It seems like it could rather easily be cut out of the OS, and it >> is apparently very capable even on the lego NXTs (64kb RAM, 256kB >> flash), and seems like more than a research proof-of-concept. >> >> 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
Re: [riot-devel] HotSpot JVM on RIOT-OS?
On Tue, Aug 11, 2015 at 10:23 PM, Zac Harvey 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 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. >>>> >>>>
Re: [riot-devel] HotSpot JVM on RIOT-OS?
On Tue, Aug 11, 2015 at 9:48 PM, Zac Harvey 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 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 that some data type is 32 bit long. >>> >>> The biggest problem, however, with porting to a larger system than a >>> microcontroller is that these larger systems have MMU (memory >>> management unit)-hardware which performs address space translations >>> between virtual addresses and physical addresses, and ensures that >>> each process has its own address space to run inside. This MMU must be >>> configured when booting in order to access all of the memory. My area >>> of expertise is constrained systems, such as the current RIOT >>> platforms, so I may have some factual errors in the above explanation, >>> please correct me if I am wrong about anything above. >>> >>>> I ask this because to
Re: [riot-devel] HotSpot JVM on RIOT-OS?
I think the few others who _are_ interested in this kind of project may find your progress interesting. I personally wouldn't mind if you ask questions on the mailing list as long as you try to stick to one thread and don't post a large number of messages without letting the list users a little time to answer your posts first. Best regards, Joakim On Tue, Aug 11, 2015 at 3:38 PM, Zac Harvey wrote: > Kevin, > > Thanks for getting back to me and yes, I would agree that this Darjeeling > fork makes for a nice starting point for such a project. I will have a good > look at it tonight after I get home, but will likely have a lot of > questions. > > Are you OK with me reaching out to you via email or GitHub, or would you > prefer that I keep these questions on the mailing list; or would you prefer > that I just figure things out for myself :-) ? I'm only a hesitant to use > these mailing lists because I will likely have a lot of initial questions > and feel this is a pretty niche topic that not many other RIOTers will care > about. > > Thanks again! > Zac > > > On 8/11/15 9:29 AM, kevin wrote: >> >> Hi, >> >> >> On 08/11/2015 02:35 PM, Michael Frey wrote: >>> >>> >>> Darjeeling VM [1] might also be a good starting point. >> >> >> in an effort to prevent duplicate work: if anyone wants to start playing >> around with Darjeeling on ARM cortex, please have a look at the port I did >> for my Bachelors Thesis first [0]. >> >> While the examples[1] do not use RIOT, but xpcc for platform abstraction, >> the vm itself is independent of any hardware abstraction. I have fixed a lot >> of alignment issues on cortex-m0 and at least one logic bug in the >> implementation on sourceforge, so it might be worthwhile to have a look at >> my code before starting your own port to cortex-m. >> >> Kevin Laeufer >> >> [0]: https://github.com/RWTH-OS/ostfriesentee >> [1]: https://github.com/RWTH-OS/ostfriesentee-examples >> ___ >> 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] HotSpot JVM on RIOT-OS?
See my response inline below. On Tue, Aug 11, 2015 at 11:58 AM, Zac Harvey 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 that some data type is 32 bit long. The biggest problem, however, with porting to a larger system than a microcontroller is that these larger systems have MMU (memory management unit)-hardware which performs address space translations between virtual addresses and physical addresses, and ensures that each process has its own address space to run inside. This MMU must be configured when booting in order to access all of the memory. My area of expertise is constrained systems, such as the current RIOT platforms, so I may have some factual errors in the above explanation, please correct me if I am wrong about anything above. > > I ask this because to me, and for many others I'm sure, the main value in an > RTOS (as opposed to Linux) is its deadline guarantees. When I run Java on > Linux, the whole JVM process might come to a hault for a few seconds while > Linux flushes some stream. Or perhaps some system-level utility runs for a > few minutes and bogs down everything on the server (including my Java app). > So to me, the real appeal of RIOT is: > > 1. Its a legitimate real-time OS when hard deadlines, task execution > guarantees, etc.; and Can you really get any real-time guarantees on a Java VM? There are background processes happening inside the Java VM which may cause delays, for example memory garbage collection (this applies to Python too and probably others, but I don't know any other interpreted languages well enough to comment on them) > 2. It's an OS where I can just deploy my app and I know that *nothing else* > besides the OS is running > > So to me, if RIOT-OS can technically handle JVM apps (2GB - 4GB in size), > then why not try to get a JVM like HotSpot to run on it? And if for some > reason it can't handle apps that size (e.g. perhaps the largest integer it > can handle is only 65,536, etc.), then I'm wondering what level of > refactoring would be required to enable it to handle beefier/server-like > apps. > > Traditionally, the counter-argument here is: "Well then just write your apps > in C." However, in 2015, all hobbyists, commercial and open source > organizations have an enormous amount of time & effort ($$$) invested in > existing software systems, which may be Java-based, Python-based, > Ruby-based, Node-based, etc. > > I can't speak for anyone else, but I would argue that the ability to run a > JVM app on a real-time OS is going to be of *enormous* utility, especially > in this modern "Internet of Things" era we're careening towards. It might > also spawn up a whole subculture of getting other systems (again, Python, > Ruby, etc.) running in an embedded context. I'm just sayin'...! > > Thoughts? Criticisms? Hate mail? By all means, go for it! Even if it may not give the same real-time guarantees as running a process hand-coded in C on the bare metal platform it is still a useful experiment and concept. For anyone attempting this: I don't believe this is an easy task. You will probably have to implement quite a large part of POSIX ioctl, some improvements to the supervisor call handler (at leas if running on ARM, to handle more than just task scheduling). You may also need to write an adaptation layer between gnrc (the network stack) and whatever network API is expected by the JVM. Filesystem storage may not be strictly necessary, but probably mandatory for almost any apps you want to run on this system. Best regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] MQTT + RIOT
I was only yesterday reading up on Paho and MQTT SN for use in RIOT. I will probably add it as a pkg during the autumn unless someone else beats me to it. Best regards, Joakim On Aug 4, 2015 9:36 AM, "Kaspar Schleiser" wrote: > Hey guys, > > is anybody aware of any work on getting an MQTT client on RIOT? > > 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] Need CodeSourcery codebench lite Edition for ARM Eabi Windows installer
On Mon, Jul 13, 2015 at 4:10 PM, nehal982Ss wrote: > > > Hello , > > > > Redirected from here : https://github.com/RIOT-OS/RIOT/wiki/Family:-ARM > > i need to get CodeSourcery Codebench Lite Edition For ARM Eabi as it seems it > is not available anymore. What platform are you building for? Why do you specifically need the CodeSourcery toolchain? Most (all?) developers use the gcc-arm-embedded toolchain at https://launchpad.net/gcc-arm-embedded or Debian's gcc-arm-none-eabi (available in the standard Debian/Ubuntu repositories). Our CI system compiles all examples and tests for all ARM platforms using the gcc-arm-embedded toolchain and it seems to work fine over there. If you are on Windows I would recommend installing Linux in a virtual machine (e.g. using VirtualBox or VMWare) for your development. Most of our developers are using either Ubuntu or OSX, with a few exceptions, e.g. FreeBSD, Gentoo (Linux). Other developers will be able to help you with any issues regarding programmers or toolchain much more quickly if you use Linux or OSX than if you want to build on Windows. Best regards, Joakim > > Many thanks and Best Regards, > > Family: ARM · RIOT-OS/RIOT Wiki · GitHub > RIOT - The friendly OS for IoT > Read more... > > > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Using C++ in device drivers
Dear RIOT developers, What are your opinions on writing device drivers or system modules in C++? I know some of the more constrained platforms might not yet have C++ support, but still it might be an interesting option for some device drivers. C++ objects for example can be used as an alternative to the device descriptor pattern we are using in many drivers. I don't have any particular driver in mind, I just want to hear any opinions around the community. Joakim Gebart Eistec AB www.eistec.se ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] C++ Style Guide
On Thu, Jun 25, 2015 at 11:44 AM, Johann Fischer 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
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 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
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 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
[riot-devel] GSoC status
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] Association time in mobile RPL/6lowpan networks
On May 21, 2015 8:37 AM, "Cenk Gündogan" 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 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
Re: [riot-devel] enums vs. macros
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 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
On May 11, 2015 3:12 PM, "Daniel Krebs" 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
On Mon, May 11, 2015 at 11:37 AM, Daniel Krebs 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
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" 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
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 : > 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" 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] WDT questions
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" 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] broken archives?
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 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 > 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 >> 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] Build issue on Windows (8.1)
An easier way to add images is to just drag and drop them from a file browser into the Github markdown text edit field. Then you don't need to go through any external hosting providers to get your image onto the network. Joakim Gebart Managing Director Eistec AB www.eistec.se On Wed, Apr 1, 2015 at 1:39 PM, Oleg Hahm wrote: > Hi Murat! > >> I did not see any issue about picture. I have re-added same picture(address) >> to page again. > > Funny! Yesterday the picture was showing a red car... > > Thanks, > Oleg > -- > The sad thing about IPv6 jokes is that almost no one understands them and no > one is using them yet. > > ___ > devel mailing list > devel@riot-os.org > https://riot-os.org/mailman/listinfo/devel > 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 On Wed, Apr 1, 2015 at 1:39 PM, Oleg Hahm wrote: > Hi Murat! > >> I did not see any issue about picture. I have re-added same picture(address) >> to page again. > > Funny! Yesterday the picture was showing a red car... > > Thanks, > Oleg > -- > The sad thing about IPv6 jokes is that almost no one understands them and no > one is using them yet. > > ___ > 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
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 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
On Sun, Mar 22, 2015 at 12:18 AM, Oleg Hahm 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
Re: [riot-devel] NFC & Atmel AT86RF232B
Hello, On Wed, Mar 18, 2015 at 10:08 PM, Craig Younkins wrote: > I think the at86rf231 driver works with the 212B or will otherwise require > minimal changes. I have not tested it but anticipate using it. In the linux > kernel they are both supported in the same file. Yes, the AT86RF212B works with the at86rf231 driver. The driver is undergoing some work right now, see https://github.com/RIOT-OS/RIOT/pull/2562 and http://lists.riot-os.org/pipermail/devel/2015-March/002247.html I have seen a memory corruption bug with the driver but not had the time to pinpoint it exactly, it seems to happen randomly, but in the vicinity of the radio RX code. I will open a PR when I find a solution unless someone else beats me to it. Best regards, Joakim www.eistec.se > > Craig Younkins > > On Wed, Mar 18, 2015 at 5:04 PM, Joël Chotard > wrote: >> >> Hi all, >> >> Does somebody is working on a RIOT NFC device driver ? and the ATMEL sub-G >> AT86RF212B driver ? >> >> Joël >> ___ >> 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] NSTF radio driver
Hi Thomas, On Fri, Feb 20, 2015 at 10:53 AM, Thomas Eichinger 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
[riot-devel] Radio duty cycling
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] kinetis common - differences between families
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" 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 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" > 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?
Re: [riot-devel] kinetis common - differences between families
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" 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
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" 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] [GSOC] Introduction
I am also interested in lwm2m support in RIOT, professionally. I have colleagues working on an lwm2m implementation for Contiki which can be useful for testing interoperability. I can help with the review and testing of the gsoc implementation, as well as technical discussions. Best regards, Joakim On Mar 5, 2015 9:04 PM, "Alexandru Razvan Caciulescu" < alex.darrede...@gmail.com> wrote: > Hello, > > I'm a 3rd year student at Politehnica University of Bucharest , Romania. > > I have former experience with communication protocols and worked on a few > college projects involving DNS Resolver and File Sharing protocols for > Linux among others.Currently I am also attending an Operating Systems > course aimed at teaching low level programming which will undoubtedly be of > great help.I would like to apply for GSOC for the "Implementation of LwM2M" > project. > > If possible I would like to discuss with the mentor for this project on > how to approach it. > > Thank you, > Alexandru Razvan Caciulescu > > > ___ > 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
riotdocker is more descriptive for the github repo name, I like it. Best regards, Joakim On Feb 24, 2015 8:20 AM, "Oleg Hahm" 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
Re: [riot-devel] Repository for Docker builds
What is a suitable name for the new repo? I have been using "riotbuild" for my Docker development at https://github.com/gebart/riotbuild 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. Best regards, Joakim Gebart www.eistec.se On Mon, Feb 23, 2015 at 11:24 AM, Hauke Petersen wrote: > Hi Joakim, > > +1 from my side! > > Cheers, > Hauke > > > On 23.02.2015 09:35, Oleg Hahm wrote: > > Hi Joakim! > > I'm completely fine with that. Thanks for the effort! > > Cheers, > Oleg > > Am Mon, Feb 23, 2015 at 09:18:42AM +0100 schrieb Joakim Gebart: > > I'd like to hear if anyone is strongly opposed to this, otherwise I > will go ahead and create a new repository tomorrow. > > Best regards, > Joakim Gebart > www.eistec.se > > > On Sun, Feb 22, 2015 at 2:51 PM, Ludwig Ortmann > wrote: > > Hi, > > fine with me, thank you for the initiative =) > > Cheers, > Ludwig > > On Sun, Feb 22, 2015 at 11:54:16AM +0100, Joakim Gebart wrote: > > Dear relentless RIOTers, > I would like to introduce an official repository for keeping Dockerfiles > used for building Docker images. The images can be used to build RIOT in > conjunction with the work being proposed in [1]. The images will contain > supported versions of tool chains to make getting started with RIOT more > convenient. I volunteer as maintainer for the Dockerfile repository and the > pre-built images which will be published at the Docker hub [2]. The reason > for making a separate repository instead of using /dist/X is that we > can more easily keep track of tool chain updates, and we can use the Docker > hub automatic build feature to automatically update the images. Using the > core RIOT code repo for Dockerfiles will cause an unnecessary amount of > rebuilds when watching it with the automatic build feature of the Docker > hub. > > [1]: https://github.com/RIOT-OS/RIOT/pull/2392 > [2]: https://registry.hub.docker.com/repos/riot/ > > Best regards, > Joakim > > ___ > 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 > > > > ___ > 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] Changing the workflow.
Hello, On Sat, Feb 21, 2015 at 8:06 PM, Ludwig Ortmann wrote: > Hi, > > On Sat, Feb 21, 2015 at 07:02:58PM +0100, Martine Lenders wrote: >> This is why I propose we change to a slightly adapted topic branch workflow >> (also known as feature branch) workflow [1]: >> >>- the main RIOT-OS/RIOT repository will get the following branches >> - master: points to the stable version of our latest release >> - one stable branch for every major release (?) > > (I understand "stable" to denote non-changing APIs, and a "stable > branch" to denote a branch which is stable in this sense, and gets > bugfixes, and possibly new features.) > > We don't have enough people to support this at the moment. > Also, we would definitely need to make sure the releases are sensible > for this to make sense. > Let's keep this one open until there is a need, time and a codebase > that makes sense to put this effort into. > I agree with Ludwig. >> - devel: points to current development version (what is currently our >> master), hot fixes can be cherry-picked to the master from here. > > According to my first remark there is no need for a devel branch, we > just keep using master. > >> - branching from devel: feature branch for every task force that is >> currently in active development, current changes will be merged >> regularly >> from devel by the branches maintainers > > "will be merged regularly" sounds like the amount of merging will > increase in total. I'd rather leave it to the respective maintainers > how they work on their feature branch. > >>- feature branches will be merged into devel if the feature reaches >>sufficient stability. > > What does "stability" mean in this context? > >> I observed two extra benefits from that: >> >>- accidentally merged "SQUASH ME" commits can be squashed further >>upstream, before we add the commits to master or devel > > Actually, that is not the case as feature branches will also need to > be PR'd against master, and might need fixing as well. > > Also, we could as well "fix" these accidental commits in our master branch. > >>- we can make maintenance of features more granular (and maybe solve our >>maintenance problem) by enacting the "Dictator and Lieutenants Workflow", >>where the "Dictator(s)" are responsible for master and devel, and the >>feature branches can be maintained by the central persons of the Task >> Force >>(the Lieutenants). > > We could just as well use the decentralized hierarchical development > model as performed by the Linux community. > https://www.kernel.org/doc/Documentation/SubmittingPatches > This would mean less visibility of the "feature branches" (in > possession of a "Lieutenant" in your terminology), but also less > stress on the "Dictators", because they don't constantly see what > doesn't need to concern them. At least I guess the GitHub interface > would make it much easier to only follow repositories one is concerned > with. Another possible improvement to the current situation might be to refactor the tags in the PR tracker to allow for finer granularity of Issues and PRs. IMHO, some of these tags today have confusing names and there may even be some duplicates right now. Best regards, Joakim ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Repository for Docker builds
I'd like to hear if anyone is strongly opposed to this, otherwise I will go ahead and create a new repository tomorrow. Best regards, Joakim Gebart www.eistec.se On Sun, Feb 22, 2015 at 2:51 PM, Ludwig Ortmann wrote: > Hi, > > fine with me, thank you for the initiative =) > > Cheers, > Ludwig > > On Sun, Feb 22, 2015 at 11:54:16AM +0100, Joakim Gebart wrote: >> Dear relentless RIOTers, >> I would like to introduce an official repository for keeping Dockerfiles >> used for building Docker images. The images can be used to build RIOT in >> conjunction with the work being proposed in [1]. The images will contain >> supported versions of tool chains to make getting started with RIOT more >> convenient. I volunteer as maintainer for the Dockerfile repository and the >> pre-built images which will be published at the Docker hub [2]. The reason >> for making a separate repository instead of using /dist/X is that we >> can more easily keep track of tool chain updates, and we can use the Docker >> hub automatic build feature to automatically update the images. Using the >> core RIOT code repo for Dockerfiles will cause an unnecessary amount of >> rebuilds when watching it with the automatic build feature of the Docker >> hub. >> >> [1]: https://github.com/RIOT-OS/RIOT/pull/2392 >> [2]: https://registry.hub.docker.com/repos/riot/ >> >> Best regards, >> Joakim > >> ___ >> 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
[riot-devel] Repository for Docker builds
Dear relentless RIOTers, I would like to introduce an official repository for keeping Dockerfiles used for building Docker images. The images can be used to build RIOT in conjunction with the work being proposed in [1]. The images will contain supported versions of tool chains to make getting started with RIOT more convenient. I volunteer as maintainer for the Dockerfile repository and the pre-built images which will be published at the Docker hub [2]. The reason for making a separate repository instead of using /dist/X is that we can more easily keep track of tool chain updates, and we can use the Docker hub automatic build feature to automatically update the images. Using the core RIOT code repo for Dockerfiles will cause an unnecessary amount of rebuilds when watching it with the automatic build feature of the Docker hub. [1]: https://github.com/RIOT-OS/RIOT/pull/2392 [2]: https://registry.hub.docker.com/repos/riot/ Best regards, Joakim ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF radio driver
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. Best regards, Joakim PS: Sorry, you are "Joakim" not "Joachim" :-) Am 20.02.2015 um 08:51 schrieb Peter Kietzmann: > Hi Joachim, > > I think it will be the at86rf231-driver (in near future). @thomaseichinger > is currently working on the refactoring according to the network > restructuring. There is still no PR but as far as I know the progress is > well. I think it's wise to wait at least until this driver is merged, as it > acts as a proof-of-concept for network devices. I assume there won't be > many changes to the netdev API. So if you cannot wait with this for time > reasons, the potential adoptions might be small (I hope :-) ). > > Best, > Peter > > > Am 20.02.2015 um 07:25 schrieb 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 >> > > -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ 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
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] About function pointers
The reason that I wanted to use function pointers in the NVRAM
interface is to avoid having to resort to macros or defining wrapper
functions in the board directory for my specific board's NVRAM
hardware. As I see it I have three choices for implementing a board
specific configuration of NVRAM:
- Macros for the board's functions such as:
board.h:
#define NVRAM_READ(addr, len) nvram_spi_read(MYBOARD_NVRAM_SPI,
MYBOARD_NVRAM_CS, addr, len)
#define
- board-specific wrapper functions:
board.c:
int nvram_read(addr, len) {
return nvram_spi_read(MYBOARD_NVRAM_SPI, MYBOARD_NVRAM_CS, addr, len)
}
- Function pointers:
board.c:
inside board_init():
nvram_spi_init(&fram, &spi_params, memsize);
I decided on function pointers for the ease of use and the clear
interface abstraction.
BR,
Joakim Gebart
www.eistec.se
On Wed, Feb 18, 2015 at 11:16 PM, Oleg Hahm wrote:
> Hi Kévin!
>
>> I began to use function pointers in the 'radio_driver.h' when trying to
>> create a unified model for radio drivers. I guess it went over later to the
>> whole netdev effort.
>
> Yes, I remember that, but why can't this be implemented in a similar way we
> did for most of the peripheral drivers like SPI? Instead of calling a function
> pointer, we simply pass a struct describing the low-level device (driver) that
> should be used.
>
>> My idea then was to have a "fast", predictable call chain from the MAC layer
>> to the physical radio transceiver functions: most MAC protocols expect to
>> run with precise delays, and a mechanism relying on message between threads
>> (like 'transceiver') did not fit that need.
>
> I completely agree on the point that we need to have direct function calls for
> MAC protocols (see also http://arxiv.org/abs/1502.01968).
>
>> The model of driver as structs containing function pointers is the one used
>> in Contiki: it seemed quite a natural way to handle the problem to me... In
>> their code, the needed drivers are aliased as 'NETSTACK_xxx' macros, then
>> functions are called by invoking 'NETSTACK_xxx.func()'.
>
> I think it is indeed one of the two natural solutions - the other one would be
> MACROing everything. I made experiences with both versions while developing on
> firmware for older sensor board platforms. And both had their drawbacks. Thus,
> when I started to work on what now is known as RIOT, I wanted to avoid Macros
> and a function pointer based abstraction layer model as much as possible. Of
> course, there are cases where either the one or the other will be the best
> solution, but I think we have to make sure to check if there are no
> alternative solutions that might work better on the long run.
>
>> As P. Nikander said, since you are supposed to know your hardware at compile
>> time, these pointers are actually constants that should be resolved at
>> compile (linking) time -- even with GCC. Theoretically, it should be
>> translated by standard indirect calls at the assembler level.
>
> You name it: If everything is known at link time, then there is also always a
> way around function pointers. As I've written in the previous mail: I'd rather
> tell the compiler (or linker) how to do the stuff in an efficient way than
> hoping for the toolchain being smarter than me.
>
>> Could you tell us more about your previous experiments? It seems quite
>> strange to me that such a mechanism (that seems simple to me) could impose
>> speed and debugging penalties.
>
> I cannot disclose any code here, because it was proprietary code for my old
> company, but the problem was a layered one. We had a highly abstracted driver
> model, similar to Linux' one with char and block devices, abstracted serial
> line devices and the like. Thus, an application or any high level code
> accessing low-level drivers would be de-referenced multiple times. This made
> it incredible hard to debug (because you had to follow all the pointer
> de-referencing) and made it almost impossible to hold some strict deadlines
> for TDMA on our old MSP430F1612.
>
>> The other question is how could we implement the network stack? Using a
>> mechanism like 'transceiver', that relies on message-passing between
>> threads, implies that there is no predictable delay for executing network
>> functions (one has to wait for the scheduler to switch to the thread(s) that
>> execute(s) the feature(s) you want to use). At some levels -- like between
>> MAC and PHY -- this can be a huge disadvantage.
>
> I think we can live with the overhead of IPC calls on all layers except the
> MAC protocol. However, even message-passing ha
Re: [riot-devel] reserve main and let application define thread(s)
On Sat, Feb 14, 2015 at 3:28 PM, Kaspar Schleiser wrote:
>
> Hi,
>
> On 02/14/15 12:28, Ludwig Ortmann wrote:
>>
>> I created quick&dirty 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] OTA meetup 11.2.2015
I am not sure I will be able to attend (remotely) at this time, will you write some minutes of the meeting (e.g. in the RIOT wiki) which I can look at afterwards? BR, 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 On Wed, Feb 11, 2015 at 10:41 PM, Arvid Picciani wrote: > Hi, > > by popular demand, we will be meeting this Friday at 19:00 at the kiwi.ki > office > > KIWI.KI GmbH > Lehrter str. 17 > 10557 Berlin, DE > > as well as online over appear.in or google hangouts (whatever i can get > working). > > Attached are the slides i will be presenting for about 15minutes. > Feel free to bring your own slides or notes. Especially for topics not > covered by me. > > see ya there! > > best, > Arvid > > > > > ___ > 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] Event driven drivers
I was actually writing on a post for this list along the same theme when I saw your message. The main reason I see for removing the busy waits is that you can lower the power consumption if you can let the CPU core sleep while the peripheral is working, either using interrupts or DMA for the transfer. I was thinking I could use `thread_sleep()` inside the part of the driver called from the application thread and `thread_wakeup` from an ISR for the relevant status flag. Will this introduce any noticeable extra delays from the context switching or otherwise? (Except for the function calls to `thread_sleep()`, `thread_wakeup()` which obviously are an extra overhead) Has anyone measured the cost of the thread context switching on the different platforms? I'm mainly interested in Cortex-M4 (Kinetis). This would be a good indication of how "slow" an I/O device has to be before it is worth it to manually yield a thread while waiting. I think ADC and UART (depending on baudrate vs. core clock frequency) are good candidates for this, as well as I2C in normal or fast mode when running on a fast MCU. SPI may not be very useful for small transfers, but DMA of larger blocks will definitely save some power/decrease CPU usage with such a change. Best regards, Joakim Gebart Eistec AB www.eistec.se On Sun, Feb 8, 2015 at 11:47 AM, Frank Holtz wrote: > Hello, > > i have looked into periph drivers and found a lot of single line "while" > statements waiting for finishing things. > > stm32f4 -> 26 statements > nrf51822 -> 4 statements > atmega2560 -> 8 statements > cc2538 -> 4 statements > sam3x8e -> 13 statements > ... > > Slow devices like ADC, Flash, UART or Random number generation are > wasting a lot of CPU cycles while waiting to finish an action. This > blocks task switching(right?) and preventing to go into sleep mode. > > What about an architecture for asynchronous drivers? > > An asynchronous driver can be initialized, but it brings hardware into > sleep mode. The hardware is powered on when an process is added to queue > and powered off when noting listens to queue. It should be possbile to > add more than one process to an queue. This gives the availability to > debug things, implement an work flow to decrypt or route radio packages > or use ADC values to generate better random data when ADC is enabled. > > An queue can be centralized and handle an event-type, the priority and > an pointer to an call back function. > > When an event is triggered any function with same event type is called > with an identifier like pin number and an value or pointer to expected > data structure. Every function can determine with return code if other > functions with same event type are called. This is needed for random > numbers to make sure that an random number is not used twice. > > When it's possible to change an event type and re queue an event an work > flow can implemented. > > Regards, > > Frank > ___ > 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] How low can you go?
On Fri, Feb 6, 2015 at 10:10 AM, Thomas Eichinger wrote: > Hi, > >> On 06 Feb 2015, at 09:36, Ludwig Ortmann 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] Bypassing hardware vendors' unlicensed header files
The only tool I've found for converting SVD to header files is the svdconv.exe that comes with the Keil IDE. The headers it produces are somewhat convoluted and it did not make nice indexable arrays and such of array-like register sets, at least when feeding it with the Kinetis SVD files that I've found. It did however give some warnings about those SVD files so it might have been badly formed input files as well. It is difficult to find any information about how the industry is working with SVD files... Does anyone have any inside connections on the larger manufacturers and can tell something about what tools are used "on the inside"? Since the SVD files are XML it is fully possible to write an xslt file and use xsltproc to produce whatever output we want from the .svd, but it is not going to be a small task to write such an xslt. 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 On Thu, Feb 5, 2015 at 3:26 PM, Thomas Eichinger wrote: > Dear list, > > tl;dr: Does anybody have experience with SVD files? > > Since it happened at least two times that ports of RIOT to new hardware was > put > on halt because of unclear or no license statements in hardware manufacturers > header files I did some research into this direction. > > What I found yet are SVD (System View Definition) files, specified by ARM and > somehow > distributed I was thinking about generating missing header files directly > from this > definitions. > > Would it make sense to generate our own header files from these files? > > Does anybody have any experience with those files and license implications > with those? > (When searching the ARM page there are a couple of EULAs to accept and so > forth) > > Any input on this topic is welcome. > > Best, Thomas > > ___ > 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] Switch to BSD?
If the proposed method in https://github.com/RIOT-OS/RIOT/pull/2362 provides a way to legally comply with LGPL and still run proprietary binary application level code on RIOT, then my vote is on LGPL. This will make sure that any improvements to core, sys, drivers etc are passed back to the project in the future as well, even if the actual applications are not open. 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 On Tue, Jan 27, 2015 at 9:12 PM, Emmanuel Baccelli wrote: > Hi everyone, > > this thread has been silent since new year's break. > > Has anyone changed his/her mind on the topic in the mean time? > > Else, here's a tentative summary on where we are at, so far, in terms of > expressed opinions: > > - a few have stated their enthusiasm for MIT/BSD > - a few have stated their enthusiasm for (L)GPL > - the vast majority is less enthusiastic to either direction but could > approve a switch to MIT, for pragmatic reasons > > Is that fair enough, in a nutshell? > > On a related topic, concerning the technical feasibility of LGPL licensing > with RIOT, > I assume you have all seen this proposal > https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide > which is the first attempt at a practical guide to proprietary code in RIOT. > > Any comments on this in the context of the license discussion? > > Best, > > Emmanuel > > > On Wed, Dec 3, 2014 at 10:59 PM, Emmanuel Baccelli > wrote: >> >> Dear RIOTers, >> >> we have been receiving an increasing amount of negative feedback from >> various companies concerning the practical usability of our LGPL license in >> their context, being a show-stopper. >> >> For this reason, INRIA, Freie Universitaet (FU) Berlin and Hamburg >> University of Applied Science (HAW) are currently considering changing the >> license of their contributions to RIOT to a less restrictive license (i.e. >> BSD, potentially as soon as next release). >> >> Such a switch to BSD is betting that the effect of a potentially smaller >> percentage of user/devel contributing back to the master branch will be >> dwarfed by the effect of a user/devel community growing much bigger and >> quicker. This seems doable considering the current momentum around RIOT. >> >> In a second phase, if such a license switch takes place for INRIA/FU/HAW >> contributions, we would then contact other contributors individually, to >> check their status concerning a similar switch for their own contributions. >> >> But in the first place, we would like to debate this topic. In particular: >> is anyone violently opposing the idea of migrating to a less restrictive >> license, such as BSD? If so, why? On the other hand, if you explicitly >> support the license change, feel free to indicate this as well. Please send >> your opinion to the list before Dec. 10th. >> >> Cheers, >> >> Emmanuel > > > > ___ > 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] LGPL compliance testing
Is RIOT_VERSION the only thing that is automatically generated for each build? I mean, if even a build date is included somewhere the result will not be identical. I like the idea, however. Best regards, Joakim Gebart Eistec AB www.eistec.se On 01/26/2015 04:43 PM, Kaspar Schleiser wrote: > Hey guys, > > here's an initial draft on how to check for LGPL compliance: > > https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide > > This is for showing that some proprietary code has been compiled and > linked with a specific version of RIOT. > > I wrote the wiki entry out of my head, so maybe I missed something, > but the general method worked in prior testing. ;) > > Should we go and automate this, or am I missing something? > > Kaspar > > p.s.: This is in no way any conclusion to the license discussion, see > it as purely technical please. > ___ > 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] Call for OTA (Over the Air Update) Task Force
On 01/20/2015 06:47 PM, Arvid Picciani wrote: > As discussed during Hack'n'Ack, let’s organize a task force to address > a currently hot feature in RIOT: Over the Air Updates. > In Q1 2015 the company I work for is planning to contribute that > feature, so i would like to call everyone who is planning or > interested in the same feature to align goals. > > - Who is interested in such feature, and what is your approach to OTA? We (Eistec) are interested in this feature as well. > - When can we meet virtually (or physically in case anyone is in Berlin)? Initially I would prefer to have a virtual meeting, but I think it would be beneficial to have a physical meeting once a task force/working group has been formed. > > While “when” and “from which buffer” is totally application specific, > there are some > common Ideas how to approach OTA in the core os itself that i have > collected from people so far: > > - Simply over-writing RIOT in flash with a new copy, by keeping the > flasher code external. > - Insert SD cards with a new image and reboot > - Two copies of RIOT on the same flash, with a boot loader selecting > the active one > - Re-flashing only the application part of RIOT over the air while > keeping the OS part forever. > - Any relevant concepts missing here? Another method related to the SD card solution if there is external memory available would be to download the new firmware image to external memory (NOR flash or similar) and then tell the device to reboot into a flasher/bootloader which checks the external memory for a new image and perform the device flashing before jumping into the main entry point. This way the bootloader could be kept small and placed in a reserved area of the internal flash, at least if partial erases of the internal memory are supported by the hardware. > > While I do have a favorite approach, the goal of a first virtual or > physical meeting would be to figure out a common ground here, so we > can focus on implementing one set of standard features into the base > OS. Independent from the actual OTA approach, these are the core > features that we appear to need from RIOT so far. > > - The ability to flash memory regions from a buffer > - Simple hashing (crc?) > - Reducing rom size > - Optimizing stacks > - Converting some statically allocated stacks to dynamic > - Define a common OTA header with at least a magic and the checksum > > Open discussion points are wether we need: > > - Cryptographically signed OTA updates > - Dynamic loader to support updating only parts of the binary > - A common boot-loader that can chain-boot riot from different memory > regions > - Are HW watchdogs necessary to check if the new image boots properly? > > Feedback on these lists as well as other input on the requirements for > OTA are appreciated at this point. > > I will collect responses to this mail and summarize the discussion, > and/or organize a meetup. > Have you looked at the LWM2M initiative? They have a firmware update service specified in their registry. I have not yet had time to look closer at it, though. See http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry and http://technical.openmobilealliance.org/tech/profiles/LWM2M_Firmware_Update-v1_0.xml 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] thread is not working
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
> 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
> <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] Switch to BSD?
In http://lists.riot-os.org/pipermail/devel/2014-September/001185.html Ludvig Ortmann stated: > > Last but not least, none of us intends to sue anyone for building > proprietary applications with RIOT as long as they are in line with our > goals (as given above). We embrace your contributions and will be happy to > help you in the task of getting them into RIOT as best we can. However, it > is possible for anyone, for example your competitors, to sue you for > copyright infringement if you build a proprietary application on top of RIOT > that does not comply with it's license terms. This is what started us thinking about the implications of building applications on RIOT. We want to be able to write binary only _applications_ for RIOT, and not have to release the source code, regardless of what license the kernel and drivers are released under. We wish RIOT to succeed as an OS and we will contribute back any changes that we make to platforms, cpus or core, but we do not want to end up in a situation where a competitor can force us to release proprietary algorithms or other code released as an application running on an OS just because the OS is LGPL. Some vendor provided libraries are also binary only. On the other hand, we do not want our competitors to take the open source software and close it off and not contribute back to the project. All in all, I think it is important for RIOT to find a way to allow binary application code, similar to what open source desktop OSes do. Best regards, Joakim Gebart Managing Director Eistec AB Aurorum 1C 977 75 Luleå Tel: +46 730-65 13 83 joakim.geb...@eistec.se www.eistec.se On 12/17/2014 01:52 PM, Emmanuel Baccelli wrote: > > Hi Joakim, > > Thanks for your feedback. With the current license, are you able to plan using RIOT as a component for some of your company's products or services? > > Best, > > Emmanuel On Dec 17, 2014 1:52 PM, "Emmanuel Baccelli" wrote: > Hi Joakim, > > Thanks for your feedback. With the current license, are you able to plan > using RIOT as a component for some of your company's products or services? > > Best, > > Emmanuel > Le 4 déc. 2014 09:30, "Joakim Gebart" a écrit : > >> I am also very much in favor of using a license which requires >> openness but like Adam said, in the embedded world it is quite common >> that changes will be necessary in order to support some hardware >> configuration. Additionally, the interpretation that we would need >> dynamic linking in order to comply with the license without opening up >> all application code makes this a quite important question. >> >> Companies are not always willing or even able (because of patents, >> NDAs or other contracts) to release the source of proprietary >> applications. The use of LGPL in RIOT has been the source of some >> discussion between me and my colleagues and I hope to see some other >> license in the future where it is possible to still distribute >> proprietary applications that run on RIOT. >> >> Eistec (see www.eistec.se) generally has the policy that anything >> related to the platform and OS (cpu drivers, device drivers, etc) will >> be sent upstream to related OSS projects, mainly RIOT and Contiki for >> now (but we have also provided some patches for other tools we use, >> such as OpenOCD), but we usually want to keep application code >> (algorithms, higher level service implementations etc.) proprietary. >> Since we work as a consulting firm it is also common that we do not >> own the code to the applications themselves but have to negotiate with >> the client on what parts to release, clients are usually fine with >> sharing bug fixes and low level driver and OS code with upstream. >> So far we have only used Contiki commercially but I personally would >> like to see that change in the future, but for now I think the risk of >> ending up in a situation where someone can demand any proprietary >> application code from us makes this a bit too dangerous. >> >> This is my personal view on the license situation, but I know that >> many of the people I work with share this concern. >> >> 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 >> >> >> On Thu, Dec 4, 2014 at 5:06 AM, Adam Hunt wrote: >> > While I've been a fervent supporter of the GPL for many years I'm on >> board >> > with a change to a simple BSD or MIT style license. Initially I was >> > skeptical about the need to move away from the LGPL but in the world of &g
Re: [riot-devel] hwtimer implementation for Freescale MKW2xDxxx
I posted a new Issue to track the progress. https://github.com/RIOT-OS/RIOT/issues/2188 Joakim Gebart Managing Director Eistec AB Aurorum 1C 977 75 Luleå Tel: +46(0)70-570 66 35 joakim.geb...@eistec.se www.eistec.se On 12/12/2014 08:56 PM, Joakim Gebart wrote: > On 12/12/2014 04:51 PM, Hauke Petersen wrote: >> Hi guys, >> >> maybe you can think of creating an issue like this one [1] to sync you >> porting efforts? It might be useful also for other people with some >> Freescale HW > Good idea! >> Regarding the `kinetis_common`: Are there actually any other >> differences for the kinetis CPUs then clock config and RAM/ROM sizes? >> Otherwise it would maybe make sense to even create just a single >> `kinetis` CPU and just put some different linkerscripts to it (as the >> clock config can be configured from the `periph_conf.h`? Don't know, >> so its just thinking out loud... > I am most familiar with the K60, I have only looked at the data sheets > of some of the others, but I think that the main difference between the > variations of the Kinetis CPU is simply that there are different numbers > of each module (e.g. number of UARTs) and some modules are not included > in all controllers (CAN bus for example). > I guess it could be possible to use `periph_conf.h`, or similar, to > differentiate between them. > > Best regards, > Joakim >> Cheers and looking forward to your PRs, >> Hauke >> >> [1] https://github.com/RIOT-OS/RIOT/issues/1646 >> >> >> >> On 12.12.2014 14:57, Joakim Gebart wrote: >>> See my reply inline below. >>> >>> Joakim Gebart >>> Eistec AB >>> www.eistec.se >>> >>> On 12/12/2014 02:36 PM, Johann Fischer wrote: >>>> Hello Hauke, Hello Gebart, >>>> >>>>> As far as I see it, we have a short- and a longterm solution: For now >>>>> I think the using the LPTMR seems reasonable, although it only offers >>>>> a single channels if I see it right. As for the offered resolution >>>>> this should be fine as long as there are no drivers and/or other >>>>> application code, that needs this resolution... >>>> Ok, then i will continue my work with LPTMR. >>> Take a look at >>> https://github.com/gebart/RIOT/blob/mulle/cpu/k60/hwtimer_arch.c if >>> there is anything you can use there. It seems to be working on my board >>> for the default example, but I have not tested it thoroughly yet. >>>>> For the long-term we are planning/working on a new timer >>>>> infrastructure substituting the hwtmer and the vtimer. One design >>>>> objective is a more flexible backend that can cope with downcounting >>>>> and similar, so that the PIT timers should be usable. Addressing the >>>>> power-down and sleep issues of the timers and finding a generic way >>>>> to deal with this is also on the requirements list... I actually >>>>> expect some serious work on this starting by mid-January, so it's >>>>> only a matter of time... >>>> The problem with PIT is, that it is not running in low power mode. >>>> Let me know when you start it, I can help you, at least with tests :-) >>>> >>>>> About merging the Kinetis implementations: I would be careful with >>>>> this, as experience has shown that even MCU's from the same or very >>>>> similar families have their differences in their peripherals. This is >>>>> for example true for the STM CPUs, and that's why we have them >>>>> separated... But as I don't know the 'Freescale World' this concern >>>>> might be for nothing?! >>>>> >>>> The Kinetis MCU's peripherals are very similar (some peripheral are >>>> taken from ColdFire :-)). I think we should try it. >>>> >>>>>> Would there be any interest in merging the K60 and the KW2x >>>>>> peripherals into a single Kinetis port? >>>> @Gebart >>>> I will finish my LPTMR implementation and attach to #2059[1]. >>>> Then i will rebase it so that you can cherry-pick and test the >>>> peripheral driver (i2c, spi ...). If it works then we can start with >>>> kinetis_common. What do you think? >>> From what I gather in the datasheets it seems like Freescale pretty >>> much >>> have a library of hardware modules that they pick and match from when >>> they create new variants of the Kinetis controllers. I think >>>
Re: [riot-devel] hwtimer implementation for Freescale MKW2xDxxx
On 12/12/2014 04:51 PM, Hauke Petersen wrote: > Hi guys, > > maybe you can think of creating an issue like this one [1] to sync you > porting efforts? It might be useful also for other people with some > Freescale HW Good idea! > > Regarding the `kinetis_common`: Are there actually any other > differences for the kinetis CPUs then clock config and RAM/ROM sizes? > Otherwise it would maybe make sense to even create just a single > `kinetis` CPU and just put some different linkerscripts to it (as the > clock config can be configured from the `periph_conf.h`? Don't know, > so its just thinking out loud... I am most familiar with the K60, I have only looked at the data sheets of some of the others, but I think that the main difference between the variations of the Kinetis CPU is simply that there are different numbers of each module (e.g. number of UARTs) and some modules are not included in all controllers (CAN bus for example). I guess it could be possible to use `periph_conf.h`, or similar, to differentiate between them. Best regards, Joakim > > Cheers and looking forward to your PRs, > Hauke > > [1] https://github.com/RIOT-OS/RIOT/issues/1646 > > > > On 12.12.2014 14:57, Joakim Gebart wrote: >> See my reply inline below. >> >> Joakim Gebart >> Eistec AB >> www.eistec.se >> >> On 12/12/2014 02:36 PM, Johann Fischer wrote: >>> Hello Hauke, Hello Gebart, >>> >>>> As far as I see it, we have a short- and a longterm solution: For now >>>> I think the using the LPTMR seems reasonable, although it only offers >>>> a single channels if I see it right. As for the offered resolution >>>> this should be fine as long as there are no drivers and/or other >>>> application code, that needs this resolution... >>> Ok, then i will continue my work with LPTMR. >> Take a look at >> https://github.com/gebart/RIOT/blob/mulle/cpu/k60/hwtimer_arch.c if >> there is anything you can use there. It seems to be working on my board >> for the default example, but I have not tested it thoroughly yet. >>>> For the long-term we are planning/working on a new timer >>>> infrastructure substituting the hwtmer and the vtimer. One design >>>> objective is a more flexible backend that can cope with downcounting >>>> and similar, so that the PIT timers should be usable. Addressing the >>>> power-down and sleep issues of the timers and finding a generic way >>>> to deal with this is also on the requirements list... I actually >>>> expect some serious work on this starting by mid-January, so it's >>>> only a matter of time... >>> The problem with PIT is, that it is not running in low power mode. >>> Let me know when you start it, I can help you, at least with tests :-) >>> >>>> About merging the Kinetis implementations: I would be careful with >>>> this, as experience has shown that even MCU's from the same or very >>>> similar families have their differences in their peripherals. This is >>>> for example true for the STM CPUs, and that's why we have them >>>> separated... But as I don't know the 'Freescale World' this concern >>>> might be for nothing?! >>>> >>> The Kinetis MCU's peripherals are very similar (some peripheral are >>> taken from ColdFire :-)). I think we should try it. >>> >>>>> Would there be any interest in merging the K60 and the KW2x >>>>> peripherals into a single Kinetis port? >>> @Gebart >>> I will finish my LPTMR implementation and attach to #2059[1]. >>> Then i will rebase it so that you can cherry-pick and test the >>> peripheral driver (i2c, spi ...). If it works then we can start with >>> kinetis_common. What do you think? >> From what I gather in the datasheets it seems like Freescale pretty >> much >> have a library of hardware modules that they pick and match from when >> they create new variants of the Kinetis controllers. I think >> kinetis_common is a good move, at least for the peripherals, I'm >> guessing that some parts such as pin muxing and core clocking might need >> cpu- or board-specific handling. >> I might find some time to work on RIOT K60 stuff later tonight. >> >> Status of my port: >> - My next step for the K60 is to finish the SPI implementation and test >> it, maybe I will be able to reuse your implementation instead of >> finishing the one I started a long time ago. >> - I have not started working on any I2C d
Re: [riot-devel] hwtimer implementation for Freescale MKW2xDxxx
See my reply inline below. Joakim Gebart Eistec AB www.eistec.se On 12/12/2014 02:36 PM, Johann Fischer wrote: > Hello Hauke, Hello Gebart, > >> As far as I see it, we have a short- and a longterm solution: For now >> I think the using the LPTMR seems reasonable, although it only offers >> a single channels if I see it right. As for the offered resolution >> this should be fine as long as there are no drivers and/or other >> application code, that needs this resolution... > Ok, then i will continue my work with LPTMR. Take a look at https://github.com/gebart/RIOT/blob/mulle/cpu/k60/hwtimer_arch.c if there is anything you can use there. It seems to be working on my board for the default example, but I have not tested it thoroughly yet. > >> For the long-term we are planning/working on a new timer >> infrastructure substituting the hwtmer and the vtimer. One design >> objective is a more flexible backend that can cope with downcounting >> and similar, so that the PIT timers should be usable. Addressing the >> power-down and sleep issues of the timers and finding a generic way >> to deal with this is also on the requirements list... I actually >> expect some serious work on this starting by mid-January, so it's >> only a matter of time... > The problem with PIT is, that it is not running in low power mode. > Let me know when you start it, I can help you, at least with tests :-) > >> About merging the Kinetis implementations: I would be careful with >> this, as experience has shown that even MCU's from the same or very >> similar families have their differences in their peripherals. This is >> for example true for the STM CPUs, and that's why we have them >> separated... But as I don't know the 'Freescale World' this concern >> might be for nothing?! >> > The Kinetis MCU's peripherals are very similar (some peripheral are > taken from ColdFire :-)). I think we should try it. > >>> Would there be any interest in merging the K60 and the KW2x >>> peripherals into a single Kinetis port? > @Gebart > I will finish my LPTMR implementation and attach to #2059[1]. > Then i will rebase it so that you can cherry-pick and test the > peripheral driver (i2c, spi ...). If it works then we can start with > kinetis_common. What do you think? >From what I gather in the datasheets it seems like Freescale pretty much have a library of hardware modules that they pick and match from when they create new variants of the Kinetis controllers. I think kinetis_common is a good move, at least for the peripherals, I'm guessing that some parts such as pin muxing and core clocking might need cpu- or board-specific handling. I might find some time to work on RIOT K60 stuff later tonight. Status of my port: - My next step for the K60 is to finish the SPI implementation and test it, maybe I will be able to reuse your implementation instead of finishing the one I started a long time ago. - I have not started working on any I2C driver yet. - UART is working, but I have only tested with one module (UART1) out of five possible (UART0-4). Best regards, Joakim > > Johann Fischer > > [1] https://github.com/RIOT-OS/RIOT/pull/2059 > ___ > 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
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
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
* @author Hauke Petersen
*
* @}
*/
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.
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] Switch to BSD?
I am also very much in favor of using a license which requires openness but like Adam said, in the embedded world it is quite common that changes will be necessary in order to support some hardware configuration. Additionally, the interpretation that we would need dynamic linking in order to comply with the license without opening up all application code makes this a quite important question. Companies are not always willing or even able (because of patents, NDAs or other contracts) to release the source of proprietary applications. The use of LGPL in RIOT has been the source of some discussion between me and my colleagues and I hope to see some other license in the future where it is possible to still distribute proprietary applications that run on RIOT. Eistec (see www.eistec.se) generally has the policy that anything related to the platform and OS (cpu drivers, device drivers, etc) will be sent upstream to related OSS projects, mainly RIOT and Contiki for now (but we have also provided some patches for other tools we use, such as OpenOCD), but we usually want to keep application code (algorithms, higher level service implementations etc.) proprietary. Since we work as a consulting firm it is also common that we do not own the code to the applications themselves but have to negotiate with the client on what parts to release, clients are usually fine with sharing bug fixes and low level driver and OS code with upstream. So far we have only used Contiki commercially but I personally would like to see that change in the future, but for now I think the risk of ending up in a situation where someone can demand any proprietary application code from us makes this a bit too dangerous. This is my personal view on the license situation, but I know that many of the people I work with share this concern. 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 On Thu, Dec 4, 2014 at 5:06 AM, Adam Hunt wrote: > While I've been a fervent supporter of the GPL for many years I'm on board > with a change to a simple BSD or MIT style license. Initially I was > skeptical about the need to move away from the LGPL but in the world of > embedded systems it's very common to make changes to the core codebase in > order to work on various platforms. Under the LGPL such changes would have > to be tracked, checked for IP conflicts, and made available. This > requirement may very well end up being so onerous that it may vary well push > companies to adopt a more suitably licensed alternative over RIOT. > > On Wed, Dec 3, 2014, 2:14 PM Thomas Watteyne > wrote: >> >> Emmanuel, >> I support the change to BSD. One of the reasons is that OpenWSN is also on >> BSD, so integration of the different code bases might be easier when both >> have the same license. >> Thomas >> >> On Wednesday, December 3, 2014, Emmanuel Baccelli >> wrote: >>> >>> Dear RIOTers, >>> >>> we have been receiving an increasing amount of negative feedback from >>> various companies concerning the practical usability of our LGPL license in >>> their context, being a show-stopper. >>> >>> For this reason, INRIA, Freie Universitaet (FU) Berlin and Hamburg >>> University of Applied Science (HAW) are currently considering changing the >>> license of their contributions to RIOT to a less restrictive license (i.e. >>> BSD, potentially as soon as next release). >>> >>> Such a switch to BSD is betting that the effect of a potentially smaller >>> percentage of user/devel contributing back to the master branch will be >>> dwarfed by the effect of a user/devel community growing much bigger and >>> quicker. This seems doable considering the current momentum around RIOT. >>> >>> In a second phase, if such a license switch takes place for INRIA/FU/HAW >>> contributions, we would then contact other contributors individually, to >>> check their status concerning a similar switch for their own contributions. >>> >>> But in the first place, we would like to debate this topic. In >>> particular: is anyone violently opposing the idea of migrating to a less >>> restrictive license, such as BSD? If so, why? On the other hand, if you >>> explicitly support the license change, feel free to indicate this as well. >>> Please send your opinion to the list before Dec. 10th. >>> >>> Cheers, >>> >>> Emmanuel >> >> ___ >> 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] 802.15.4 SPI transceiver
Dear Peter, How many units would you be interested in? We (Eistec) have actually designed a BeagleBone cape for the Atmel radio which we are currently evaluating for use in our gateways (WSN border router) that I guess could be used directly or re-layouted to a more compact form. The board design will not be open sourced, unless as a part of a specific contract job, but we could discuss different options for hardware sales. Contact me off-list if you are interested in discussing this. Best regards, Joakim Gebart Managing Director Eistec AB joakim.geb...@eistec.se www.eistec.se On Tue, Dec 2, 2014 at 5:37 PM, Peter Kietzmann wrote: > Hi, > > the idea behind this was to have 802.15.4 support with the stm32fxdiscovery > boards as they are available and kind of "popular". I agree with you that > AT86RF2xx would be the best solution because of the already implemented > spi-based driver but we could not find this transceiver as an external > hardware device. On Samr21 xpro and IoT LAB_M3 the transceiver is onboard. > For sure, the driver for MRF24J40MA then has to be implemented. > > Any other experiences with (/opinions on) that device? Or does someone know > where to get a AT86RF2xx with pinout? > > Best, > Peter > > > > > Am 02.12.2014 um 17:23 schrieb 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 >> 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 > > > ___ > 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] 802.15.4 SPI transceiver
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 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
Dear Thomas, Thank you for your feedback, see my response inline below. On Mon, Dec 1, 2014 at 11:32 AM, Thomas Eichinger wrote: > Dear Joakim, > >> On 30 Nov 2014, at 18:02, Joakim Gebart 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
[riot-devel] Separating module drivers from physical pin configuration
Dear developers, (This is probably only relevant to Cortex-M or other advanced MCUs; AVR etc. usually do not have much function muxing capability.) I would like to hear opinions on the following model: 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. This is something that we are adding to our Contiki port soon and I would love to see something similar in RIOT. 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. 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. 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] [quentin.lam...@orange.com: [iot-lab-users] OpenOCD and M3 nodes : configuration file using the FTDI interface driver pushed upstream]
I just want to add that we (Eistec) have been using the libusb ftdi driver in openocd since December 2013 for our Mulle programming board. Our board is based on FT2232H, like the IoT_Lab-M3 uses. It has been working very well for us. To me it seems like the proper choice to migrate to use libusb than to require a separate ft2232 driver. Less dependencies => Less risk of running into incompatibilities at users' systems. BR, Joakim Gebart Eistec AB www.eistec.se On Fri, Nov 28, 2014 at 4:24 PM, Thomas Eichinger wrote: > Hi, > > On 27 Nov 2014, at 17:34, Oliver Hahm wrote: > > P.S. Haven't compared with our version, nor tested yet. > > Tested it a minute ago. It has some slightly different configurations, > couldn’t > make out any differences in behaviour nor performance though. > But we don’t have to maintain it our selfs anymore! \o/ > > Best, Thomas > > > ___ > 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] RIOT's new test system - wiki pages
This seems like an impressive system if used properly. I especially like the possibility of running tests on actual hardware. Is this system also going to be published as open source? Best regards, Joakim Gebart Eistec AB www.eistec.se On Thu, Nov 27, 2014 at 11:09 PM, Philipp Rosenkranz wrote: > Hi everyone, > > in order to make the development/design of the new test system for > RIOT more transparent and to encourage a lively discussion about this > topic I've created a few wiki pages. You may find the hub page for all pages > related to the new system here: > > https://github.com/RIOT-OS/RIOT/wiki/RIOT%27s-new-test-system > > Best regards, > Philipp > > ___ > 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] hwtimer questions
Dear RIOT developers, What are the drawbacks of using a hardware timer with only a 32.768 kHz tick rate? Would there be any problems with scheduling or hardware drivers when using a lower timer frequency? What is the side effect of assigning the hwtimer module only one hardware timer channel? As I understand from the code, the hwtimer module uses some kind of internal queue to be able to handle more timers than there are hardware channels, is this correct? On our platform we are using the Freescale Kinetis K60 which has only one timer (LPTMR) which can wake the CPU from deep sleep. We need to use deep sleep in order to reduce power consumption in power constrained situations (battery powered etc.). All other timer modules in the CPU are halted when the CPU enters a deep sleep mode. 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] SAMR21: SPI, at86rf233, I2C
There is also an rf212 which is a 868 MHz/900 MHz variant of the 230, and uses the same driver as rf230 (at least in Contiki) with the exact same commands and register addresses. BR, Joakim Gebart Software and Hardware Engineer Eistec AB Aurorum 1C 977 75 Luleå Tel: +46(0)730-65 13 83 joakim.geb...@eistec.se www.eistec.se On Fri, Nov 14, 2014 at 9:56 AM, Baptiste Clenet wrote: > Thank you for your answers. > I think we should follow the Hauke's idea with a flag to select the 233 > and a common driver for 23x. > > Best, > Le 13 nov. 2014 19:32, "Hauke Petersen" a > écrit : > >> Hi Baptiste, >> >> On 13.11.2014 17:22, Baptiste Clenet wrote: >> >> Hi, >> >> I have seen the pull request from Troels51 concerning the SAMR21. >> Is that normal that it uses the transceiver at86rf231 instead of the >> at86rf233? The SAMR21 Explained pro board uses the *at86rf233 *transceiver >> so something should be changed. >> >> We did a little study on both and ended up with the conclusion, that >> actually both transceivers are quite similar. The xx233 is a little newer >> and has some added functionality regarding power management. But the basic >> register set (and register addresses) are identical which makes the x231 >> driver work perfectly also with the x233 device. >> >> Maybe we can rename the driver to at86rf23x and enable the additional >> features for the x233 per define. So feel free to open a PR! >> >> >> By the way, Rane implemented the SPI here: >> https://github.com/wiredsource/RIOT/blob/master/cpu/samd21/periph/spi.c >> Did you implement yours from his source code? >> >> >> Finally, I'm almost done with I2C, I just need to check each function >> (i2c_read_res works). >> >> Yeah! Looking forward for the PR! >> >> Cheers, >> Hauke >> >> ___ >> 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
