Re: [riot-devel] Adding new Wifi hardware support in RIoT
Hi, hm from my impression RIOT/drivers/include/netdev is the place to implement the driver/stack. I think even without exact documentation the structure is easy to understand. f.e. if you take a look at the implementation of RIOT/drivers/include/cc110x/* - netdev. I just took a quick look at chipKIT Network and USB Libs-20150115.zip from vendor - DWIFIck looks like a GREAT place to start a GPL version (beside that i cleary question that the vendor is not using GPL parts in this source). never the less this source has high value - compared to some binary only blobs by other vendors. since a couple of weeks a so called network stack task force was setup. I think it would be great to work in collaberation. but in my personal view i think a implementation of a full 802.11 stack is quite a huge task. i think many devs ordered some ESP8266 WIFI transceiver, but they did not arrive yet (?) have fun ps. of course you not talking about SPI only access right? jan shishir tiwari sumit.tiwari1...@gmail.com hat am 4. Februar 2015 um 07:57 geschrieben: Hello, We are using a PMODWifi device [PmodWiFi - 802.11b WiFi Interface (MRF24WB0MA, b/g/n compatible)] on Synopsis ARC board and have succeded in initial port for RIoT on it. We wish to add support for the PMODWiFi module within RIoT stack. We see that there is a support for sixlowpan device (ieee802154) and the corresponding driver nrf24l01p into the stack. Current documentation on the portal or web doesn’t say anything about how we can add new network driver support. We wish to add 802.11 a/b/g support. It would be good if anyone would elaborate on how do we proceed with, and what kind of changes are required. Thanks BR, Shishir tiwari ___ 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] Adding new Wifi hardware support in RIoT
Hello, We are using a PMODWifi device [PmodWiFi - 802.11b WiFi Interface (MRF24WB0MA, b/g/n compatible)] on Synopsis ARC board and have succeded in initial port for RIoT on it. We wish to add support for the PMODWiFi module within RIoT stack. We see that there is a support for sixlowpan device (ieee802154) and the corresponding driver nrf24l01p into the stack. Current documentation on the portal or web doesn’t say anything about how we can add new network driver support. We wish to add 802.11 a/b/g support. It would be good if anyone would elaborate on how do we proceed with, and what kind of changes are required. Thanks BR, Shishir tiwari ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] 802.15.4 for Linux
Hi Christian, I plan to test the RPL router daemon on Linux. Currently we want to use the sticks as interface not as node/platform. Best regards, Martin On 03.02.2015 19:30, Christian Mehlis wrote: Am 02.02.2015 um 18:16 schrieb Martin: There is also a RPL Edge router daemon available [2], which we want to test with the boards. Hi Martin, do you plan to test the RPL edge router in Linux or in the contiki on the stick? Best Christian ___ 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
Hi everybody, we are also interested in this feature, and we are willing to collaborate to achieve it. We have already looked at LWM2M and find it quite suitable for our needs. Plus it's telco-friendly. Best Regards, Joaquín. El 22/01/2015 a las 21:20, Joakim Gebart escribió: 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 -- Adevice Solutions http://www.adevice.es/ Joaquín Cabezas Director Comercial (CCO) Adevice Solutions SL C/ Leonardo da Vinci, nº 18 Edificio Tecnoincubadora Marie Curie, 3ª planta Parque Científico y Tecnológico Cartuja 93 41092 Sevilla Tfno: +34 644 297 831 Tfno: +34 954 463 170 www.adevice.es http://www.adevice.es AVISO SOBRE CONFIDENCIALIDAD: Este documento se dirige exclusivamente a su destinatario. Puede contener información confidencial sometida a secreto profesional y su divulgación está prohibida en virtud de la legislación vigente, se informa que si no es usted el destinatario o la persona autorizada por el mismo, que la información contenida en este mensaje es reservada y su utilización o divulgación con cualquier fin está prohibida. Si ha recibido este documento por error, le rogamos que nos lo comunique por teléfono, o e-mail y proceda a su destrucción. En el envío de e-mail no se puede garantizar la seguridad ya que esta información puede ser modificada, interceptada, o incompleta. El remitente no acepta responsabilidad por los errores u omisiones en el contenido o anexos de este e-mail. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Network Stack Task Force
Hi RIOTers, sry for my late reply. I would like to attend the Network Stack Task Force personally and will be in Berlin on Thursday and Friday. Oleg told me that the meeting will most likely take place at the University instead of C-Base. Could someone provide the location and time for the meeting? Tanks, Best Jonas On 29.01.2015 19:23, Hauke Petersen wrote: Hi RIOTers, as Martine already posted, the network stack task force will meet next week Thursday and Friday (Feb 56). Following I tried to draft the main goals as well as a preliminary schedule: GOALS: -- - synchronize everyone involved on the ongoing activities - collect use cases - map them on the current state of the architecture and see if the architecture holds - refine the network stack architecture - detail out a concrete work-plan As mentioned earlier, the goal is not to end up with a prototypical implementation or similar - we should really focus on the concepts and architecture, so we end up with a clear idea (and plan) for the implementation afterward. PRELIMINARY SCHEDULE: -- Thursday before lunch: Martine and me will present in detail the current state of the network stack architecture and concepts, so everyone involved is synchronized. The current state can then be used as a base-line for further discussion and refinement (or we end up by completely re-designing it...) Thursday after lunch: We collect use cases for the network stack (as in: what happens in this situation, what module is needing what kind of data, who is talking to whom). We then map these use cases to the proposed architecture to identify short-comings and come up with a list of open topics that need to be discussed further. Friday: Based on the open topics and design short-comings, I suggest we go through them item by item and come up with solutions :-) Please append anything that we should add to the discussion or any ideas for making the 'workshop' as efficient as possible! See (hear) you next week, Hauke On 27.01.2015 08:26, Martine Lenders wrote: Hello Paul, the workshop will be held at Freie Universität Berlin and (probably, as far as I can see from the attendees) HAW Hamburg, simultaneously, but will also provide the PlaceCam-Link [1] that will connect the two events and allow for remote participation. Details for the schedule will be posted in the next few days. Cheers, Martine [1] placecam.de http://placecam.de Am 26.01.2015 19:05 schrieb gnu...@dds.nl mailto:gnu...@dds.nl: Is this a webbased meeting or a meeting in Berlin ?. Paul. Peter Kietzmann peter.kietzm...@haw-hamburg.de mailto:peter.kietzm...@haw-hamburg.de schreef: Hi, I'm fine. Cheers, Peter Am 26.01.2015 um 10:56 schrieb Martine Lenders: Hi, looks like it's gonna be February 5th and 6th (a Thursday and a Friday). Martin is the only one that is not available on Thursday. Is everyone okay with that? Cheers, Martine 2015-01-19 17:30 GMT+01:00 Hauke Petersen hauke.peter...@fu-berlin.de mailto:hauke.peter...@fu-berlin.de mailto:hauke.peter...@fu-berlin.de mailto:hauke.peter...@fu-berlin.de: Hi everyone, sandwiching the HA is indeed not a good idea, I agree. Thanks Martine for the doodle, let's wait until Thursday and decide on the dates based on the outcome of the doodle then. Cheers, Hauke On 19.01.2015 13:17, Martine Lenders wrote: Hi, Since this thread has gained some traction now I would propose to use to dudle it out. The two days adjacent to each other where most are available would be the date: https://dudle.inf.tu-dresden.de/RIOT-NSFT1/ Cheers, Martine Am 19.01.2015 12:29 schrieb Emmanuel Baccelli emmanuel.bacce...@inria.fr mailto:emmanuel.bacce...@inria.fr mailto:emmanuel.bacce...@inria.fr mailto:emmanuel.bacce...@inria.fr: Hi Thomas, damn, your right, I misread the dates. So Hack'nAck would be sandwiched inside the workshop, and I guess that's not great. How about 28-29, or 29-30, then? Best Emmanuel On Mon, Jan 19, 2015 at 11:24 AM, Thomas Eichinger thomas.eichin...@fu-berlin.de mailto:thomas.eichin...@fu-berlin.de mailto:thomas.eichin...@fu-berlin.de
