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
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,
>
> A
nd 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:
>>
>>
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 fro
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 tim
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
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 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 d
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
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++
>> St
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++ h
, 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
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
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 firs
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 ha
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 tha
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 (se
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_PO
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
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 d
/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
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,
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 th
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
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 w
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 the
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
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
> &
ia #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 ex
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
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, Joaki
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
cess 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 fin
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
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 =)
>
&
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 start
7;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 :-) ).
>
> B
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
m_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
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
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
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"
> st
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 Atme
d 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 Geba
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,
>
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
ical.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
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
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
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, Ha
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
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 i
://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:
> He
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...@eist
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
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 year
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
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.eist
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.
>&g
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
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 Hah
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
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
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
64 matches
Mail list logo
