Re: [riot-devel] Interim Hack'n'ACK
Hi, apparently there was a copy/paste error, the correct URL is: http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- See https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation for instructions on how to participate. Currently the session is not live due to some technical problem on the hosting side, though. Keep your fingers crossed ;) Cheers, Ludwig On Tue, Mar 01, 2016 at 05:56:54PM +0100, Oleg Hahm wrote: > Dear reviewing IOTlers, > > in Berlin we're having an interim Hack'n'ACK session tonight. If someone wants > to join us remotely, you can do so at > http://placecam.de/call.php?c=3DVBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- > > Cheers, > Oleg > -- > /* We are root, all done! */ > RIOT/sys/net/rpl/rpl.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] RIOT rtos compatibility question
Hi, Short answer: no. Long answer: RIOT is focused on microcontrollers and low power. Therefore it probably also has no support for most of the remaining hardware of a system that can host a 10gb network controller. Cheers, Ludwig Am 23. Mai 2015 00:31:53 MESZ, schrieb Samuel Hutchinson samuel.hutchin...@ctfmeg.com: I need to have a 10Gb network connection to my RTOS. Does RIOT have a driver for any 10Gb cards? -Samuel Hutchinson Applied Math Coop CTF MEG ISL ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF - Naming the stack
Hi, Am 12. Mai 2015 20:26:58 MESZ, schrieb Oleg Hahm oliver.h...@inria.fr: Hi! what about `ipc_stack` due to its utilization of the former? But still: I'm still not convinced of the reason to give it a name. All operating systems have a default stack but no one is bound to use it and can use their `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is mainly historic, since it started out as a seperate project. As far as I know TinyOS' stack has no name either. Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We have ccn-lite, OpenWSN, and this one. Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if I'm wrong) of the old stack and should be upgraded to use the lower layer(s) of the new stack? (What about OpenWSN?) Or are those layers not considered part of the stack? I think we cannot compare to Linux, BSD, and the like here. They can afford to make different modules somehow interoperable at cost of memory, we cannot. As far as I remember, the modularization of the new stack had exactly this as a goal. Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LPM idle_thread
Hi, DEVELHELP should not be used to change the semantics of things. Cheers, Ludwig Am 9. Mai 2015 18:43:36 MESZ, schrieb Oleg Hahm oliver.h...@inria.fr: Hi Frank! why is LPM_SLEEP or LPM_POWERDOWN is commented out? I think it's mostly commented out for debugging. Debugging with power save modes can become really nasty (even printf() debugging). However, I agree this shouldn't be solved like this. Another case for DEVELHELP, maybe? Cheers, Oleg ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] help
Hi, This is often called firmware update or OTA for (firmware) over the air. We don't have support for this yet, but it is planned, and there is some information in the wiki (look for OTA). Cheers, Ludwig Am 8. Mai 2015 00:50:30 MESZ, schrieb Sonda Bousnina sondabousn...@gmail.com: Hi, Thanks for your quick reply yes exactly, that what I mean On Fri, May 8, 2015 at 12:35 AM, Kaspar Schleiser kas...@schleiser.de wrote: Hi, On 05/08/15 00:23, Sonda Bousnina wrote: I'm wondering if it is possible to flash or update the code in the target board in real time while it is working without switching it off. Not sure I understand the question. You mean, add/replace code while the device is running? Are you referring to updating the device in the field? 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] NSTF - Naming the stack
Hi, On Sat, May 02, 2015 at 05:12:55PM +0200, Oleg Hahm wrote: After thinking just for some minutes over a new name for the stack, I thought that NG (pronounced Angie? ;)) may be not a bad idea after all and would save us from quite some renaming... All we would have to do then is to extract the common functionality and move it generic IPv6 and co. files. What do you think? Due to its known meaning ng is as bad a name as new or next, because it will loose this meaning in the foreseeable future. I'm not sure if naming is necessary at all. I think public/shared headers can be used without a problem, and non-default implementations (I assume the current ng implementation will be the default) can as well get a characterizing suffix like _light or _tiny if and when they arrive. Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc
Hi, we are already discussing this in IRC, the problem was missing 32 bit toolchain support. Cheers, Ludwig On Fri, May 01, 2015 at 05:20:50PM +0200, Drasko DRASKOVIC wrote: Hi all, just downloaded RIOT and I am trying hello-world example build on my Debian machine: drasko@Lenin:~/riot/examples/hello-world$ make Building application hello-world for native with MCU native. make -C /home/drasko/riot/boards/native make -C /home/drasko/riot/boards/native/drivers make -C /home/drasko/riot/core make -C /home/drasko/riot/cpu/native make -C /home/drasko/riot/cpu/native/periph make -C /home/drasko/riot/drivers make -C /home/drasko/riot/sys make -C /home/drasko/riot/sys/auto_init /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s collect2: error: ld returned 1 exit status /home/drasko/riot/examples/hello-world/../../Makefile.include:175: recipe for target 'all' failed make: *** [all] Error 1 Is there any particular reason why these libraries would be incompatible? Also, how to get verbose Make? I tried make V=1 and make V=s, do not work. BR, Drasko ___ 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] Task force ping
Hi, Kaspar Schleiser schrieb: Every task force: please give a short status update. OTA/Firmware upgrade: stalled (at least I'm not aware of any activity) Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Biweekly virtual meeting @ Every 2 weeks from 10am to 11am on Wednesday (RIOT Events)
Hi, I updated the calendar entry. Cheers, Ludwig Am 8. April 2015 08:07:40 MESZ, schrieb Oleg Hahm oliver.h...@inria.fr: Hi! Ok, then let's have the meeting at 2pm CEST from _today_. Cheers, Oleg On Wed, Apr 08, 2015 at 03:36:37AM +0200, Philipp Rosenkranz wrote: Hi, I am also for that change (even though I won't be able to join the meeting today) Best, Philipp 2015-04-07 20:24 GMT+02:00 Martine Lenders authmille...@gmail.com: Hi, in general I prefer 2pm, but tomorrow I'm not able to attend at this time. Cheers, Martine Am 07.04.2015 10:08 schrieb Oleg Hahm oliver.h...@inria.fr: Hi, anyone opposed to permanently rescheduling this call to 2pm CEST? Cheers, Oleg On Tue, Apr 07, 2015 at 08:00:13AM +, Google Calendar wrote: This is a notification for: Title: Biweekly virtual meeting Developer discussions. Remote participation will be provided. When: Every 2 weeks from 10am to 11am on Wednesday Berlin Calendar: RIOT Events Who: * Ludwig Ortmann - creator Event details: https://www.google.com/calendar/event?action=VIEWeid=anBwMXUyaXZsdWVkOHFkdHA1MGpzYjFzZ2sgazNxbDhzZXR2N2w0OG9mbm9sMHRmdXU2dHNAZw 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. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- printk(%s: TDR is ga-ga (status %04x)\n, ...); linux-2.6.6/drivers/net/eexpress.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] CC2538dk support
Hi Andre, as far as I see, the radio support is still in PR state (and in need of work): https://github.com/RIOT-OS/RIOT/pull/2198 Cheers, Ludwig Andre Guedes schrieb: Hi all, I can see from RIOT wiki that CC2538dk board is supported, but I couldn't find any information about its networking support. So could anyone confirm that networking pieces (e.g. radio, 6lowpan) are properly working in CC2538dk board? Thanks, Andre ___ 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] Cross Compilation
If you want to run the RIOT hardware emulator native as a Linux process on the MIPS architecture, you have to port it to this architecture first. Native has some some assembler lines which are only written for x86 and arm as of now. Cheers, Ludwig Am 28. März 2015 00:53:54 MEZ, schrieb Maxence Chotard maxence.chot...@xsoen.com: Ludwig, do you mean that I can't compile RIOT with a mips toolchain adapted to my openwrt version and to my hardware platform ? Cheers, Maxence -Message d'origine- De : devel [mailto:devel-boun...@riot-os.org] De la part de Ludwig Ortmann Envoyé : vendredi 27 mars 2015 17:04 À : RIOT OS kernel developers Objet : Re: [riot-devel] Cross Compilation Hi, RIOT native does not currently run on MIPS anyways. Cheers, Ludwig Am 27. März 2015 16:04:56 MEZ, schrieb Maxence Chotard maxence.chot...@xsoen.com: Hello, Is there anybody who knows how to cross compile hello-world example on RIOT for an openwrt distribution, which is using a MIPS architecture ? Cheers, Maxence ___ 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] Wakaama LWM2M
Hi, are they willing to support this endeavor in the form of a license change? Cheers, Ludwig Emmanuel Baccelli schrieb: Hi everyone, I was recently in contact with Wakaama [1] community (part of the Eclipse IoT foundation), and which maintains an open source implementation of LWM2M. More to the point, they told me that the code base [3] is deprecated (it was their repo prior to joining Eclipse), and that their supported codebase is now [2]. They would be very happy if their implementation would be ported to RIOT, and would provide some support for that (they suggest whoever is interested in that contacts them through [4]). I thought this information may be of interest for us, and in particular for GSoC project proposals on this topic. Best, Emmanuel [1] http://eclipse.org/proposals/technology.liblwm2m/ [2] https://github.com/eclipse/wakaama [3] https://github.com/01org/liblwm2m [4] https://dev.eclipse.org/mailman/listinfo/wakaama-dev ___ 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] Nucleo L1 Wiki article renamed
Hi, in case anyone wonders what happened to the Wiki entry; https://github.com/RIOT-OS/RIOT/wiki/Board%3A-ST-nucleo-l1 I renamed it to https://github.com/RIOT-OS/RIOT/wiki/Board:-Nucleo-L1 in order to match the naming scheme of the other Nucleo boards. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Benchmarks
Hi, I think our only m0+/802.15.4 board is the samr21-xpro and there are problems with the current/old network stack because of its memory demands. That said: which protocol on top of IP are you interested in? I assume you want to ignore RPL and any other side-tasks for this evaluation? Cheers, Ludwig Am 17. März 2015 17:46:52 MEZ, schrieb Simon Vincent simon.vinc...@xsilon.com: Hi Craig, We have a 802.15.4 transceiver that is capable of 250kbps. We are thinking of using this with a Cortex M0+ but wanted to make sure that the M0+ would have the processing power to handle the 802.15.4/6lowpan/ipv6 stack at a datarate of 250kbps. I just wondered if anyone had done any datarate measurements on existing development boards using the Cortex M0+? - Simon On 17/03/15 16:20, Craig Younkins wrote: Hi Simon, Throughput will be highly dependent upon the RF environment and what transceiver you are using. The M0+ most likely has enough power to do it under ideal conditions, but retransmissions due to collisions will limit the effective bandwidth. You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is significantly less crowded but lower theoretical bandwidth. The Atmel 212B is 900 Mhz and specs 1000 kbps as the max air data rate. Which transceiver are you using? Craig Younkins On Tue, Mar 17, 2015 at 11:42 AM, Simon Vincent simon.vinc...@xsilon.com mailto:simon.vinc...@xsilon.com wrote: Has anyone done any performance tests to see what throughput can be achieved using RIOT? I would be interested to know if the Cortex M0+ is powerful enough to sustain 250Kb/s TCP over 6lowpan/802.15.4. Does RIOT have any mechanism to measure CPU usage? - Simon ___ 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 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] OTA meetup 11.2.2015
Hi Baptiste, I was/am extremely busy with non-RIOT work, so please bear with me ;) An update will follow soonish. If you're on a deadline say so and I can look if I can squeeze it in somehow. Cheers, Ludwig Baptiste Clenet schrieb: Arvid, Ludwig, any improvements concerning OTA? Cheers, 2015-03-09 15:12 GMT+01:00 Baptiste Clenet bapcle...@gmail.com: Hi, Ludwig, how is the planning going ? Could you create a wiki page (like [1]) or an issue (like [2]) with description of the work to do as well as assignment for each task? Everybody will know how it is going then. What do you think about it? Cheers, [1] https://github.com/RIOT-OS/RIOT/wiki/Timer-Task-Force [2] https://github.com/RIOT-OS/RIOT/issues/2278#issuecomment-73411503 2015-02-22 10:35 GMT+01:00 Ludwig Ortmann ludwig.ortm...@fu-berlin.de: Hi, On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote: the minutes from the meeting have been added to our wiki: https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015 Have there any concrete next steps been identified? Did you conclude in some kind of a schedule for upcoming tasks and who is gonna work on what? There has been some preliminary scheduling, we will announce more concrete planning soon, possibly in the form of an issue. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- *Clenet Baptiste* -- *Clenet BaptisteFR: +33 6 29 73 05 39* ___ 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 2015 Introduction - N1 BLE Project
Hi Alexis, You don't necessarily need to implement everything from scratch. Maybe you can find parts of the BLE stack implemented under a compatible license somewhere. Cheers, Ludwig Am 16. März 2015 10:13:15 MEZ, schrieb Alexis DUQUE alexis...@gmail.com: HI RIOT Developers ! I'm Alexis, from Lyon, France, student in Telecom Engineering. I'm fond of IoT, embedded development, FOS Projects, and I'm currently doing a master thesis in Barcelona, wich focus on Thread ( http://www.threadgroup.org/) protocols stack. I will be really interested to take part of RIOT community as developer, starting working on BLE Project. Even if I've no experience with RIOT development (I just use it on MSP430) , I well know BLE at different level of the stack : I've worked on Nordic nrf1822 eval board, nrf8001 with Arduino, Android API, and Bluez driver on Unix system. Obviously, I'm familiar with C/C++ and embedded development, on different platforms such as Arduino, STM32L0, MSP430 or M2M Gateways (arm poky toolchain with Yocto builded distro). As this is just an introduction and presentation post, I've not yet technical questions (but they will come :-) ) But if can someone introduce me the community, core developers, processes, to know you a bit more, that will be great ! Some questions: When are next virtual meeting, or call (18/03) ? the next Hack'n'ACK (26/03)? Who is the potential mentor for N1 BLE project (or the dev that best known RIOT network implementation) ? In my point of view, implementing complete BLE stack is a huge work for 4 month project. What do you think about that ? Which is the priority (central, peripheral roles) ? For you, what's better for the community : unachieved work on bigger project, or reduced but well tested and documented keys functionalities ? To conclude, I've participated (with success :-)) on GSoC2014 with OpenMRS ( openmrs.org) on Atlas project. And I'm currently the lead dev and maintainer of OpenMRS Atlas server (atlas.openmrs.org), and OpenMRS Atlas Module (https://dev.openmrs.org/#/show/atlas/). Cheers, Alexis DUQUE ___ 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] Project N2- BLE stack - GSoc 2015
Hi Kausthub, What exactly do you want to know? Cheers, Ludwig Am 16. März 2015 02:31:04 MEZ, schrieb Kausthub Naarayan kausthubnaara...@gmail.com: Hi all, I am currently trying for the network project that is : implementing BLE stack for RIOT . After doing a bit of searching a found out that I need to implement GAP and GATT protocol and HCI protocol to implement this project ! But I do not know how to proceed further in terms of coding these ! Please help ! Thanks in advance Regards Kausthub Naarayan ___ 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'15 project
Hi Prudhvee, What kind of help do you need? The specifications of both technologies are open, so you can get familiar with those. The RIOT sources are open and documented as well. The wiki and issue tracker contain information about current work on the network stack (look out for network stack task force). Cheers, Ludwig Am 13. März 2015 02:26:36 MEZ, schrieb Prudhvee Narasimha Sadha prudhvi.s...@gmail.com: Hi, My name is Prudhvee Narasimha. I'm an undergraduate student in National Institute of Technology, India. My interest lies in OS and Networking Concepts and their programming in UNIX environment. I have gone through the ideas page of RIOT. The projects Project N2: Implementation of LwM2M and Project N1: Support for Bluetooth Low Energy aka Bluetooth Smart. Project N1: Support for Bluetooth Low Energy aka Bluetooth Smart I'm a learning at work type student. Right now, I am a novice programmer for application level programming. But, I promise to work dedicatedly towards my project with my best. Regarding, Bluetooth Low Energy, I had gone through the web about this and learned somethings about it and I'm interested in working to reduce the power consumption using Bluetooth Smart. Project N2: Implementation of LwM2M I had gone through web about LwM2M, it is Light Weight Member 2 member protocol. liblwm2m is an implementation of the Open Mobile Alliance's LightWeight M2Mprotocol (LWM2M). We can base our work on this or we can code from scratch depending on the seniors decision on optimization or ease. I'm willing to work in either of the projects but priorly, Project N2. I will be very much thankful and grateful if you would provide me with the necessary resources and information on contributing to these projects. As of my experience to RIOT, I'm a novice. I installed RIOT in my UBUNTU 14.04. Completed my first newbie project and hacking the source code. Awaiting your response and thanks in advance for reading my mail and helping me. Thanks, Prudhvee ___ 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] Fwd: Need help about RIOT radio communicate example
Hi Chen, How exactly does the example not work? Or the other way around: what does work? Cheers, Ludwig Am 12. März 2015 16:31:55 MEZ, schrieb Chen Xie xcmic...@gmail.com: Hi, I'm a USC(University of Southern California) student. and I'm new to RIOT and I have a project based on RIOT. Firstly, I want to make 2 TelosB boards(Sky Tmote) talk through radio (CC2420). I tried to use default example, but it seems do not work. I am not sure which part goes wrong. I searched several days, and no radio examples found. Do you have examples related to radio communication? No shell related is better. Can you help? Thanks for your attention. Best, Chen ___ 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] replace printf, puts issue
Hi,
Yes, we came to the same conclusion while driving to embedded world.
I've got the implementation and API specification ready as well and will open
a PR later.
Cheers, Ludwig
Am 27. Februar 2015 02:14:51 MEZ, schrieb Jozef Maslik ma...@binarylemon.com:
Hi,
Yes compiler do not optimize (remove out) empty function defined as is
suggested.
But if RIOT does not want use macros, we can define empty function as
static inline function in header and then will be removed by
optimization.
log_api.h
#if MODULE_LOG
void log_info(...);
#else
static inline void log_info(...) {}
#endif
BTW. Hauke idea use modules is nice.
Regards,
Jozef
On 23 Feb 2015, at 13:00, Martine Lenders authmille...@gmail.com
wrote:
Hi,
Am 23.02.2015 10:04 schrieb Ludwig Ortmann
ludwig.ortm...@fu-berlin.de:
are you suggesting macros are better than APIs + functions?
If so, please explain why and what better means ;)
I was not sure if the compiler optimizes out empty functions, so I
assumed
#define INFO(msg) (void)0;
to be the better solution concerning code size.
Regards,
Martine
___
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] LGPL compliance testing
PS: can you send a link to your PR? I couldn't find it. Cheers, Ludwig Am 26. Februar 2015 07:23:52 MEZ, schrieb Ludwig Ortmann ludwig.ortm...@fu-berlin.de: Hi Murat, Under what license are the generated files? And also, how do you think your port is related to the discussion in this thread? I can try to talk about this topic with a cypress representative today. We are currently at the embedded world and they are too. They seemed interested in RIOT in an initial chat. BTW: As far as I understood it, their software can create object files with library code for the psoc. Therefore I guess it should be possible to link the generated psoc library with RIOT in our make system as well. So, whatever it looks like today, please don't close your pull request yet. Cheers, Ludwig Am 25. Februar 2015 21:46:45 MEZ, schrieb Murat CAKMAK m...@muratcakmak.net: Hi All, I was (still) busy to read mails about LGPL compliance so sorry for slience. As you know, I have initially ported RIOT to PsoC 5LP processor by creating a PsoC Creator IDE Projects. In my case: 1. This port not using the default RIOT build environment and PsoC Creator IDE hides linking and other details. 2. PsoC Creator IDE also creates automatically some source codes. I have created an empty project with a small HW design under dist/PsoCCreator directory. But when you build project in PsoC Creator IDE, It is going to create a lot of files; system initialization, APIs for HW blocks which created for RIOT etc. I was not planning to commit those files to GIT repository because they are already created automatically by IDE. 3. Auto-generated files may be changed (e.g bug fixing) by the version of PSOC Creator IDE. So, md5 sums may be different for different versions of PsoC Creator IDE. On the other hand, I can also implemented required files instead of auto-generated PsoC Creator files, and use RIOT build system. But HEX files of PsoC processors also includes HW desing code (verilog) addition to firmware output(elf, hex etc.). I dont know how PsoC Creator IDE merges Firmware code and HW design code into a single HEX file and I am not sure about PSOC Creator team share this information with me. It is the hard way and also I dont prefer to use this way. Because, in this way, we can not use advantages(ARM Core + Programmable DigitalAnalog Blocks) of PsoC processors which only available by PsoC Creator IDE. So, What is the latest decision? Should I withdraw my pull request for PsoC 5LP port? Regards. Murat. -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Matthias Waehlisch Sent: Saturday, February 21, 2015 5:09 PM To: RIOT OS kernel developers Subject: Re: [riot-devel] LGPL compliance testing Hi Kaspar, On Fri, 20 Feb 2015, Kaspar Schleiser wrote: Let me correct myself. There are no technical reasons against using LGPLed RIOT to develop proprietary applications. it depends on how you define technical reasons. Yes, it is not impossible to create separate object files. But you maybe don't want to do this for technical optimization (see for example http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL .pdf http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL. pdf). Using a weird compiler that cannot output the required object files because it is closed source and proprietary is purely political. That compiler could be changed trivially *if it would be open source* or the vendor was inclined to do so. This doesn't count as technical reason. I agree with Oleg's comment on this. And btw, if a compiler can be changed trivially depends on details I suppose. For me the sentence RIOT allows LGPL + proprietary source code at the same level of comfort compared to Linux sounds like a cheap marketing slogan making clear that the persons are not aware of the IoT diversity. Saying otherwise makes clear that the persons are not aware of the troubles embedded linux companies go through when developing proprietary devices using (L)GPLed linux + libraries. Both systems address different types of devices. From a professional point of view, I would not base strategic decisions on the discussed PR/idea. What profession would that be? Having an almost complete picture of the landscape. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehli...@ieee.org mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net http://www.link-lab.net ___ devel mailing list mailto:devel@riot-os.org devel@riot-os.org http://lists.riot-os.org
Re: [riot-devel] OTA meetup 11.2.2015
Hi, On Mon, Feb 16, 2015 at 06:41:05PM +0100, Oleg Hahm wrote: the minutes from the meeting have been added to our wiki: https://github.com/RIOT-OS/RIOT/wiki/minutes-OTA-meetup-13.2.2015 Have there any concrete next steps been identified? Did you conclude in some kind of a schedule for upcoming tasks and who is gonna work on what? There has been some preliminary scheduling, we will announce more concrete planning soon, possibly in the form of an issue. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] replace printf, puts issue
Hi Jozef, AFAIK there has been no work on a solution so far. However, I thought about this the other day in the context of the function pointer discussion and would like to propose a logging API (maybe there is an issue for that as well somewhere) for `core`, which offers things like `log.info(...)` and `log.error(...)`. Different logging modules can implement this API then, ranging from `printf` over file based logging to network messages. And then there should also be a `(void) ...` implementation which suits production and ultra low memory needs. Opinions? Cheers, Ludwig Am 23. Februar 2015 03:16:33 MEZ, schrieb Jozef Maslik ma...@binarylemon.com: Hi, Could you please give me information about actual state of replace printf and puts issues? https://github.com/RIOT-OS/RIOT/issues/994, https://github.com/RIOT-OS/RIOT/issues/641 I’m working with MKL02Z32 which has 4kB RAM. Printf or puts which are almost everywhere make a big problem. I removed them from my fork, but it is not good or nice solution. If I miss something important around “printing issue” please correct me. How others deal with this issue? (printf or puts usage like here, is not nessesary in real applications). 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
Re: [riot-devel] reserve main and let application define thread(s)
Hi, On Sat, Feb 14, 2015 at 03:28:56PM +0100, Kaspar Schleiser wrote: On 02/14/15 12:28, Ludwig Ortmann wrote: I created quickdirty branches for both methods: plain c: https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-application-init macro magic: https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-make Not sure which one I dislike better ;) ;) I 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. A possible removal of auto_init is a separate concern from my point of view, so I'd like to keep it out of the discussion for now. If you disagree you need to elaborate, because I don't see how this fits in. We could have something like ... All that we parse and auto-generate the corresponding C code. Not sure if we're entering a world of pain this way. ;) Call me bourgeois, but I would rather use macros than generating C code somewhere in the build system. (Or you could try to convince me with the power of code ;) I liked the idea with the list, though. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] redbee-econotag board
Hello and welcome Ralph, In principal, all examples should work on all boards unless the build system says otherwise. (Or there should be an issue in the tracker). I'm not familiar with this board, but if I remember correctly, there exist several hardware versions of it. Which one do you have? Also: did you try and enter commands (e.g. help)? Cheers, Ludwig Am 17. Februar 2015 22:41:36 MEZ, schrieb Ralph Droms (rdroms) rdr...@cisco.com: Is redbee-econotag board code still in active development or use? I'm new to RIOT ... tried compiling the default example for redbee-econotag and found an error (maybe more correctly a construct that doesn't work as expected) in the conditional assembly in common.s I put in a patch but now all I get from default is: .CONNECT Size: 69440 bytes Sending /home/rdroms/RIOT/examples/default/bin/redbee-econotag/default.hex done sending files. Board initialized. kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki) kernel_init(): jumping into first task... Should default work? - Ralph ___ 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] PlaceCam on Linux with echo-cancellation
Hi, On Mon, Feb 16, 2015 at 04:31:51PM +0100, Oleg Hahm wrote: PS: Open Research Topic: Find out how to automatically or at least super-conveniently (I'm thinking push-to-talk) mute the microphone when not speaking. Well, you can mute yourself, whenever you're not speaking, so it would be something like click-to-talk. I do this, but it does not qualify as super-convenient. Mainly because it requires me to navigate my mouse to the PlaceCam window and click the tiny button. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] reserve main and let application define thread(s)
Hi, On Sat, Feb 14, 2015 at 11:50:38AM +0100, Ludwig Ortmann wrote: On Fri, Feb 13, 2015 at 06:49:56PM +0100, Kaspar Schleiser wrote: On 02/13/15 15:55, Ludwig Ortmann wrote: My proposal: Let the application Makefile export one or possibly several names to be used for the initial application thread(s). kernel_init will then take care of creating those. I'd like to see a nice (idea on how to do an) implementation of this... I hope we don't end up with too much macro magic. A solution without any macro magic would be to require application_init to exist, call that from kernel_init, and let the application create its own threads. Not overly convenient, but as the usual workflow for creating applications is copy'n'paste of an existing application it wouldn't hurt much either. I created quickdirty branches for both methods: plain c: https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-application-init macro magic: https://github.com/LudwigOrtmann/RIOT/tree/wip/remove-main-make Not sure which one I dislike better ;) Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Meeting 11/02/2015
Hi Baptiste, in theory yes, in practice I am unable to contact one of the persons who can host the session. The link however is always the same. Cheers, Ludwig On Wed, Feb 11, 2015 at 09:56:58AM +0100, Baptiste Clenet wrote: Hi, Is there a meeting today? Could you provide the PlaceCam link of it (10am today)? Cheers, -- *Clenet Baptiste* ___ 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
Hi Frank, On Sun, Feb 08, 2015 at 11:47:25AM +0100, Frank Holtz wrote: i have looked into periph drivers and found a lot of single line while statements waiting for finishing things. ... 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. Wrong =) As long as the calling thread (or the respective implementation) does not disable interrupts, the caller may be preempted. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] 'defalut' example on SAMR21 Xplained Pro
Hi, Please try connecting to a different USB port, I've seen this before. Cheers, Ludwig Am 6. Februar 2015 11:42:05 MEZ, schrieb ROUSSEL Kévin kevin.rous...@inria.fr: Hello everyone, Does the 'default' example work correctly on SAMR21 Xplained Pro? I compiled and flashed successfully this application on the Xplained Pro I have; but when doing 'make term', I just can't obtain any output from the board (via the same debug USB port I used to flash). Was anyone able to run this example successfully on the SAM R21, or there a known problem? Thanks, -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ 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] Problem socket UDP
Hi Baptiste,
could you open an issue please?
Cheers, Ludwig
On Fri, Feb 06, 2015 at 03:05:05PM +0100, Baptiste Clenet wrote:
After pluging a second sender, I got the problem:
if ((socket MAX_SOCKETS) || (socket_base_sockets[socket -
1].socket_id == 0)) {
return false;
}
socket = 11534388
socket_base_sockets[socket - 1].socket_id = 64
And then the program goes to isr_hard_fault
2015-02-06 14:19 GMT+01:00 Baptiste Clenet bapcle...@gmail.com:
I have let my program running with two boards: one sender and one
receiver. It seems to work for the moment (longer than with three sender
boards)
2015-02-06 10:53 GMT+01:00 Baptiste Clenet bapcle...@gmail.com:
Hi Oleg,
I tried on native by simulating the value from sensor and it works after
one hour of running.
So it seems to be a platform specific problem.
Any clues? Which test shoud I do then? and where the variable socket is
incremented?
Cheers,
2015-02-06 8:18 GMT+01:00 Oleg Hahm oliver.h...@inria.fr:
Hi Maxence!
You mean than I should slow down the number of transmission? I send a
packet every second on three boards which means that the other board
receives three packets a second.
How may I check apart from slowing down the rate of the transmission?
Three packets every second shouldn't be a problem. Have you checked if
same
(or similar code) works on native. That would be always the first
indicator if
it's a general problem in - let's say the network stack - or if it's
something
particular to this hardware.
Cheers,
Oleg
--
panic (Splunge!);
linux-2.2.16/drivers/scsi/psi240i.c
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
--
*Clenet BaptisteFR: +33 6 29 73 05 39 %2B33%206%2029%2073%2005%2039*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*
*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
--
*Clenet BaptisteFR: +33 6 29 73 05 39 %2B33%206%2029%2073%2005%2039*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*
*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
--
*Clenet BaptisteFR: +33 6 29 73 05 39*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*
*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
___
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] Why RIOT is partner of Ubuntu? (technical cosequences?)
Hi Jan, Your fears are entirely ungrounded :) First of all, there are no concrete plans or even arrangements as of now. From our point of view, RIOT lacks human interfaces (among other things), and if Ubuntu snappy apps turn out to be a fitting front end, we will probably support it, but not exclusively. Second, as far add I know Ubuntu is criticized primarily for reasons that have to do with decision making. RIOT aims to be a proper open source project, so I'm not afraid of Canonical taking over the reins or something like that. We (the core developers) are also in contact/affiliation with several other entities (companies and institutes) that have interests in RIOT or which are already using/financing/shaping development. (This means the influence of financially involved parties is distributed and it will most likely stay this way.) In this regard: we are currently in the process of creating a legal entity (a German Verein) with the goal of catering to both, RIOT's free software and financial needs. Cheers, Ludwig PS: this is not an official statement, just my personal view on things. Am 26. Januar 2015 10:42:39 MEZ, schrieb Jan Wagner m...@jwagner.eu: Hi devs, dont know if this is right the list - but are there any technical consequences? What does RIOT want from Ubuntu? Are there any technnical plans of cooperation and how should Ubuntu help with that? What is the plan of Ubuntu? - 'market positionig' ? - just a act pure love? Beside the critic about Ubuntu that you might know or just google - I clearly ask myself what this heavy commercialized dist want from RIOT? “ The open Ninja Sphere controller based on Ubuntu Core is a perfect base for building apps that interact with devices and sensors in your home. We look forward to the growth of a new ecosystem of inventors and creators and are delighted to provide them with a blank canvas for their creativity. ” My fear: Is RIOT is assimilated into a future 'EZ CRAZY COOL NInJA Ubuntu Core soon? Regards (parnoid) Jan ___ 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] Memory Management
Hi, On Thu, Jan 22, 2015 at 10:56:22AM +0100, Martine Lenders wrote: for the native-stuff you have to ask Ludwig for the specifics as to of why, but most of the hosts system's implementation of standard functions are wrapped. I think this was because our POSIX interface would otherwise colide with the system's POSIX interface. That's mostly correct ;) In this particular case it's wrapped to guard against side effects of letting an application directly call the host implementation, though. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] PIC16 and/or PIC18 platform ?
Hi yes, every thread has it's own stack. You need to be able to store and restore a thread's context per request and on interrupts. Cheers, Ludwig On Fri, Jan 16, 2015 at 10:43:49PM +0100, gnu...@dds.nl wrote: Is it possible to port RIOT OS to PIC16 platform (no stack manipulation possible)or the PIC18 platform (limited stack manipulation possible) I have been looking into the atmel ported code to see what is all needed to do and most is not a problem but what are the stack manipulations needed ?. Does every thread have its own stack ?. thanks. ___ 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] Virtual Meeting tomorrow
Hi, On Tue, Jan 13, 2015 at 09:03:20PM +0100, Oleg Hahm wrote: I've set up a pad with a tentative agenda here: http://riot.pad.spline.de/6 Guests are not allowed to join that pad. Please sign in. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] ESP8266 WIFI transceiver
Hi, I've got two of those and they appear to be working ;) I can bring them to the university if you are interested in first hand experience. Cheers, Ludwig Am 12. Januar 2015 19:38:02 MEZ, schrieb Cenk Gündogan cenk.guendo...@fu-berlin.de: Hi *, Does anyone has any experience with this cheap WiFi transceiver (ESP8266)? May be of interest to some of you, too. http://www.ebay.de/itm/ESP8266-Serial-WIFI-Wireless-TransceiveR-Module-SPI-Send-Receive-LWIP-Arduino-/171530595640?pt=Wissenschaftliche_Ger%C3%A4tehash=item27f0052d38 Cheers, CG ___ 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] Flashing the Samr21 xpro
Hi, does anyone know if it's possible to flash this board faster in principal? Cheers, Ludwig On Sat, Jan 10, 2015 at 02:25:50PM +0100, Lucas Jenß wrote: Hey everyone, I’ve been playing around with the Samr21 xpro and flashing the device is _really_ slow, i.e. 0.481 KiB/s. Is this expected or is there a way to improve it? I’m using the current OpenOCD Git HEAD because the 0.8.0 release does not seem to contain the configs for the board yet. I tried to flash the hello-world example. Cheers, Lucas ___ 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] Open IoT Challenge
Dear Developers, The Eclipse Foundation is holding a challenge: http://iot.eclipse.org/open-iot-challenge/ The focus is on open technology and community, so by using RIOT and involving our fabulous community you've already half won ;) To participate, you'd need to register until January, 17th. The deadline for submission of the solution is February 27th. The rules: * The challenge is open to any individual aged 18 years or older * The solution submitted by the applicants must be a new solution created for this challenge * More than one individual can participate in creating a solution but any prize will be awarded to the key contact who completed the entry form The criteria: * Innovation of the solution and applicability to the application domain * Completeness of solution * Use of open standards and open source technology * Amount of community discussion from the participant when they built their solution The prices: $750 gift card $500 gift card $250 gift card In case you have an idea for a project but hesitate to do it alone, just ask others to join forces on the mailing lists or on the IRC. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Network refactoring
Hi, we've also got a Google calendar (embedded on the website under www.riot-os.org#community) you might be interested in: https://www.google.com/calendar/embed?src=k3ql8setv7l48ofnol0tfuu6ts%40group.calendar.google.com In case you are using a Google account for calendaring you could also import the calendar (in the calendar view add a new calendar with the URL k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com). Cheers, Ludwig On Wed, Jan 07, 2015 at 10:38:00AM +0100, Baptiste Clenet wrote: Great! Thanks I found the page which says when the meeting is as well. Wednesday at 10:00 AM, I'll try to attend. 2015-01-07 10:31 GMT+01:00 Ludwig Ortmann ludwig.ortm...@fu-berlin.de: Hi Baptiste, No need to register, we have a license. Please have a look at the Wiki page for further information: https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation Cheers, Ludwig On Wed, Jan 07, 2015 at 09:36:20AM +0100, Baptiste Clenet wrote: Hi, I would like to attend the meeting in order to see the progress and ask some questions, if necessary, at the end of the meeting. When is it planned? Btw, is PlaceCam a free software? It seems to have only 30 days trial ... 2015-01-06 5:59 GMT+01:00 Martine Lenders authmille...@gmail.com: Hi, Am 05.01.2015 18:06 schrieb Ludwig Ortmann ludwig.ortm...@fu-berlin.de : Hi, On Mon, Jan 05, 2015 at 06:00:34PM +0100, Oleg Hahm wrote: Maybe we can discuss a tentative schedule and set some milestones for the refactoring during a (PlaceCam) conf call this week? What do you think? How about making the milestone setting part of the bi-weekly virtual meeting next week? I guess more interested parties (me among others) can attend then ;) It would be great if there is some pre-discussed input for that topic in that meeting though, so please: do have a preliminary talk. I'll try to manage to prepare some slides. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- *Clenet Baptiste* ___ 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 -- *Clenet BaptisteFR: +33 6 29 73 05 39* *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte système temps réél embarqué* *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014* ___ 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] Network refactoring
Hi Baptiste, No need to register, we have a license. Please have a look at the Wiki page for further information: https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation Cheers, Ludwig On Wed, Jan 07, 2015 at 09:36:20AM +0100, Baptiste Clenet wrote: Hi, I would like to attend the meeting in order to see the progress and ask some questions, if necessary, at the end of the meeting. When is it planned? Btw, is PlaceCam a free software? It seems to have only 30 days trial ... 2015-01-06 5:59 GMT+01:00 Martine Lenders authmille...@gmail.com: Hi, Am 05.01.2015 18:06 schrieb Ludwig Ortmann ludwig.ortm...@fu-berlin.de : Hi, On Mon, Jan 05, 2015 at 06:00:34PM +0100, Oleg Hahm wrote: Maybe we can discuss a tentative schedule and set some milestones for the refactoring during a (PlaceCam) conf call this week? What do you think? How about making the milestone setting part of the bi-weekly virtual meeting next week? I guess more interested parties (me among others) can attend then ;) It would be great if there is some pre-discussed input for that topic in that meeting though, so please: do have a preliminary talk. I'll try to manage to prepare some slides. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- *Clenet Baptiste* ___ 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] Network refactoring
Hi, On Mon, Jan 05, 2015 at 06:00:34PM +0100, Oleg Hahm wrote: Maybe we can discuss a tentative schedule and set some milestones for the refactoring during a (PlaceCam) conf call this week? What do you think? How about making the milestone setting part of the bi-weekly virtual meeting next week? I guess more interested parties (me among others) can attend then ;) It would be great if there is some pre-discussed input for that topic in that meeting though, so please: do have a preliminary talk. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Porting other platform
Hi Shishir, can you please rephrase the question? Cheers, Ludwig On Tue, Dec 30, 2014 at 04:34:39PM +0530, shishir tiwari wrote: hi Ludwig, Is Porting for ARC600/ ARC700 (Synopsys) has been done. Any idea? Thanks Shishir tiwari On Wed, Dec 24, 2014 at 8:13 PM, Ludwig Ortmann ludwig.ortm...@fu-berlin.de wrote: Hello Shishir, Please have a look at the porting guide in our wiki: https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide Also keep in mind that all files have to have an LGPL 2.1 compatible license. Finally, you should look at the development procedures and coding conventions: https://github.com/RIOT-OS/RIOT/wiki/Development-procedures https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions Happy hacking! Cheers, Ludwig Am 24. Dezember 2014 15:24:01 MEZ, schrieb shishir tiwari sumit.tiwari1...@gmail.com: Hi All , I want to port RIOT OS to new platform (ARC 600 microncontroller ). What is need to done. Any documentation is available for this. thanks ___ 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
[riot-devel] Tomorrow's virtual meeting cancelled
Hi, Due to too few participants and low activity, tomorrow's meeting has been cancelled. The next virtual meeting is in two weeks. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Suggested new platform for RIOT: calling for volunteers
Hi Kevin, cheap starter kit is relative, but the MCU sound interesting indeed! Presumably I won't have any time to port, but I'd be happy to help with reviewing ;) In case anyone is interested in actually porting this and only held back by the investment, I'm confident a sponsored starter kit can be arranged. Jolly seasons greetings everyone! Cheers, Ludwig Am 23. Dezember 2014 14:30:11 MEZ, schrieb ROUSSEL Kévin kevin.rous...@inria.fr: Hello everyone, Since RIOT has been adapted to the AVR architecture, there is a chip that--I think--would be a great platform for development and production: the ATmega 256RFR2. The RFR2 family is presented here: http://www.atmel.com/devices/ATMEGA256RFR2.aspx but to sum it up, this MCU has the following advantages: - the well-known, low-power AVR 8-bit architecture - an integrated 802.15.4 transceiver, quite similar to the AT86RF231 - 256 Kb or Flash and, even better, 32 Kb of RAM (a huge amount for an 8-bit MCU!) - a complete set of integrated peripherals: the usual timers, PWM, UART, SPI, I2C, ADC, JTAG... as well as a some less common, very nice features like a true random number generator or a 32-bit symbol counter - it is available in a cheap starter kit board that is in itself a simple but functional mote with MCU, antenna socket, temperature sensor, and extension slots (see http://www.atmel.com/tools/ATMEGA256RFR2-XSTK.aspx) As such, it seems to make an ideal platform for future motes, and I think it is bound to be quite successful in the market. That's why I plan to make an extensive use of this device as soon as possible. As usual, I will start the port and try to have it up and running as fast as I can, but since I am now in the last year of my PhD, my time schedule is now really tight. Consequently, it will be extremely hard for me to push the porting effort further that the bare minimum (CPU and transceiver). It means that my code probably won't represent a clean, production-ready port by itself. Since running RIOT on this platform would benefit everyone in the community, it would be nice if I could receive help in this task; knowing that I will most likely be the first to use it, and as such feedback on the port is guaranteed. Thanks in advance, and best regards. -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ 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 on Arduino UNO
Hi, On Mon, Dec 22, 2014 at 08:44:55AM +0100, Martine Lenders wrote: 2014-12-21 21:13 GMT+01:00 eric fleury eric.fle...@inria.fr: On 21 déc. 2014, at 20:15, Sudarshan S sudarshans.riot@gmail.com wrote: I would like to understand the following: 1) I believe there are ways to expand RAM in Arduino UNO, using SRAM ICs and SPI bus upto 32K . So would it be feasible or make sense to port RIOT on such an expanded RAM arrangement ? I am afraid that such memory is only for data and will not be accessible via the program counter. True, but since RIOT's program is written to the Flash ROM, there would be no need for the IP to access those addresses. So the real question is: how big is the Flash ROM, and how much memory does the .text part of RIOT consume on 8-bit platforms. For our hello-world application this is 8524 bytes on the Arduino Mega 2560, for the somewhat more sophisticated default application it's ~15 KiB (without any network support). @Sudarshan is that remotely in the flash sizes of the Arduino Uno? http://arduino.cc/en/Main/arduinoBoardUno says: 32 KB (ATmega328) of which 0.5 KB used by bootloader About the original question: I don't think adding RAM via SPI makes any sense in order to work around the memory limitations imposed by RIOT's code. The way it works is that you need to actively store/load data to/from the external RAM. So you would have to rewrite code that needs more memory to work on smaller chunks and take care of loading/storing them in between steps. Such a change would most likely not be incorporated into RIOT. Now, one could think about swapping entire threads, but this would make thread switches very very slow (no acceptable realtime behavior anymore). Also, this would probably require changes in several other places like the messaging code. These changes would most likely not be incorporated into RIOT either. But the most important question is: What do you want to do with it? If you just want to drive I/O and don't need a shell, I guess this could work. What will definitely not work with this little memory is RIOT's network stack. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hi, On Thu, Dec 18, 2014 at 01:46:52PM +0100, Kaspar Schleiser wrote: BSD changes the whole picture. It makes me feel exploited if I contribute a lot of ressources building free roads and others just invest a little but profit from the combination of all roads (even charging me) instead of pooling ressources to improve the free network and finding a way to profit from something else. I don't understand where BSD changes this picture in contrast to LGPL. In either case, we provide building blocks which allow others to create proprietary applications, services and devices. Please explain without analogies and use concrete examples instead. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hi, On Wed, Dec 17, 2014 at 01:06:24PM +0100, Kaspar Schleiser wrote: Hey, On 12/16/2014 06:09 PM, Ludwig Ortmann wrote: (L)GPL tries to put some restrictions on that. Mostly, the source code cannot realistically be sold as long it's (L)GPL. This is not correct (depending on your definition of code and selling of course). I know that you know what my definition of selling is with respect to the discussion. Actually, I'm not sure this is the case, please elaborate. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hi, On Thu, Dec 18, 2014 at 02:35:58PM +0100, Kaspar Schleiser wrote: On 12/18/2014 02:10 PM, Ludwig Ortmann wrote: (L)GPL tries to put some restrictions on that. Mostly, the source code cannot realistically be sold as long it's (L)GPL. This is not correct (depending on your definition of code and selling of course). I know that you know what my definition of selling is with respect to the discussion. Actually, I'm not sure this is the case, please elaborate. If you sell (L)GPLed source code, that code *must* be under (L)GPL, so the first buyer can freely distribute it (under those libraries terms). So practically you can sell that code only once. Maybe I'm missing something, but the BSDs say: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. ... This means that if you sell BSD licensed source code to someone, they can freely distribute it just like they could with LGPL'd code. The BSD licenses do not allow you to change the license (sublicense) [1]. Cheers, Ludwig [1] Exemplary web search result: https://forums.freebsd.org/threads/how-to-sublicense.47390/ ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] AVR platform maturity
Hi Kévin, On Tue, Dec 16, 2014 at 03:05:52PM +0100, ROUSSEL Kévin wrote: It's been a few months now since an AVR device (Arduino Mega) port has been available in RIOT. Does somebody use it regularly? I would like to try some developments on AVR, and I was wondering if AVR support was production-ready, or if there was still rough edges to aware of? https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Arduino-Mega2560#state While there is basic support in RIOT, there are still some parts missing: - Timer implementation needs love (ideally simulate a 32bit timer by adding an overflow counter to the implementation) - LPM driver missing - GPIO driver missing - SPI/I2C/TWI driver missing - ADC driver missing PWM is also missing, even from the list of missing things ;) Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hi, On Tue, Dec 16, 2014 at 06:42:37PM +0100, Oleg Hahm wrote: So in that case, you can't even (legally) sell a product based on RIOT without it (and you) being mentioned. Referring to a discussion I had with Hauke over lunch: would have RIOT to be mentioned only in the code or on the sold product (let's say an Internet connected toy dinosaur)? After thinking a bit about this and searching a bit on the web [1], I conclude that the quoted MIT license requires this implicitly while the BSD licenses are explicit about it. Cheers, Ludwig [1] Exemplary result: http://info.protecode.com/bid/33956/How-you-can-comply-with-open-source-license-attribution Most licenses, open source or commercial, require that a copy of the copyright, patent, trademark, and attribution notices from the source software be distributed verbatim with the product using that software. Examples are GNU Public License (GPL), Microsoft Public License (MPL), and MIT license. Note that even if the source code is not distributed with your product, the copyright and other attribution must be distributed with your software. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hi, On Mon, Dec 15, 2014 at 01:08:24PM +0100, Kaspar Schleiser wrote: On 12/15/2014 11:10 AM, Ludwig Ortmann wrote: I'd rather add a static linking exception to our current license (or switch to GPL with linking exception which amounts to the same as far as I remember) What kind of static linking exception do you have in mind? The regular kind ;) http://en.wikipedia.org/wiki/GPL_linking_exception I'm not aware if there is another kind with different characteristics. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
