Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Peter, Do you mean I should get an address on my interface without having to configure it manually? If so, which module (USEMODULE) is it exactly that has this effect? /Adeel > -Original Message- > From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter > Kietzmann > Sent: Monday, July 25, 2016 8:40 AM > To: RIOT OS kernel developers > Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > Hi Adeel, > > generation of the CPUID shouldn't be a problem. I checked it on an > stm32f4discovery board. Can you try it with examples/gnrc_networking? > "ifconfig" works there as well. > > The f4 board usually has no network interface and now you're about to > initialize two. I could imagine it's just a configuration problem but to be > sure, > please check gnrc_networking first. > > Best > Peter > > > > Am 21.07.2016 um 12:11 schrieb Adeel Mohammad Malik: > > Hi again, > > > > I think I got the SPI connection right now. I just configured an address > > using > ifconfig and was able to change the address. I am still not getting an address > automatically which as Thomas mentioned I should be getting using the cupid > module. Seems like I am missing a module in my Makefile. > > > > /Adeel > > > >> -Original Message- > >> From: Adeel Mohammad Malik > >> Sent: Thursday, July 21, 2016 11:29 AM > >> To: 'RIOT OS kernel developers' > >> Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > >> > >> Hi again, > >> > >> I just used the following pin configuration for the AT86RF233 > >> transceiver > >> now:- > >> > >> #define AT86RF2XX_PARAMS_BOARD { > >>.spi = SPI_0, \ > >>.spi_speed = SPI_SPEED_5MHZ, \ > >>.cs_pin = GPIO_PIN(PORT_E, 0), \ > >>.int_pin = GPIO_PIN(PORT_E, 1), \ > >>.sleep_pin = GPIO_PIN(PORT_E, 2), \ > >>.reset_pin = GPIO_PIN(PORT_E, 3)} > >> > >> I still have the same problem. I have the following relevant modules > >> included in my Makefile:- > >> > >> ... > >> USEMODULE += gnrc_netdev_default > >> USEMODULE += auto_init_gnrc_netif > >> GNRC_NETIF_NUMOF := 2 > >> USEMODULE += ethos gnrc_netdev2 > >> CFLAGS += '-DETHOS_UART=UART_DEV(0)' -DETHOS_BAUDRATE=115200 > - > >> DUSE_ETHOS_FOR_STDIO USEMODULE += at86rf233 ... > >> > >> Any hints/clues would be appreciated. > >> > >> /Adeel > >> > >>> -Original Message- > >>> From: Adeel Mohammad Malik > >>> Sent: Wednesday, July 20, 2016 6:33 PM > >>> To: RIOT OS kernel developers > >>> Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > >>> > >>> Hi Peter and Thomas, > >>> > >>> I was quite skeptical about my pin connections/configurations. I did > >>> realize that the default pin mapping of the Atmel driver could be a > >>> problem so I had already defined my own pin mapping in the file > >>> "/boards/stm32f4discovery/include/board.h" before writing to the > >>> mailing list. I defined it as follows:- > >>> > >>> #define AT86RF2XX_PARAMS_BOARD { > >>> .spi = SPI_0, \ > >>> .spi_speed = SPI_SPEED_5MHZ, \ > >>> .cs_pin = GPIO_PIN(PORT_A, 0), \ > >>> .int_pin = GPIO_PIN(PORT_E, 0), \ > >>> .sleep_pin = GPIO_PIN(PORT_E, 1), \ > >>> .reset_pin = GPIO_PIN(PORT_E, 2)} > >>> > >>> After reading the thread that Peter referred to, I checked the file > >>> "/boards/stm32f4discovery/include/board.h" and saw that there is an > >>> overlap on PA0:- > >>> > >>> #define BTN_B1_PIN GPIO_PIN(PORT_A, 0) > >>> > >>> The reason I defined AT86RF2XX_PARAMS_BOARD as above is the link > >>> https://github.com/RIOT-OS/RIOT/wiki/Board%3A-STM32F4discovery > >> where a > >>> picture of the STM32F4DISCOVERY board shows the different pins. I > >>> just assumed that GPIO_0 (PA0), GPIO_1 (PE0), GPIO_2 (PE1), GPIO_3 > >>> (PE2), as shown in the picture, are not connected to anything and > >>> hence free to > >> use. > >>> My assumption was obviously wrong. > >>> > >>> I will fix my pin configuration tomorrow and see if it works for me. > >>> Thanks for your replies. You guys are really helpful. > >>> > >>> Regards, > >>> Adeel > >>> > -Original Message- > From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter > Kietzmann > Sent: Wednesday, July 20, 2016 4:48 PM > To: RIOT OS kernel developers > Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > Hi, > > just as a side note: @Nordzisko has a pretty similar setup wich > worked (except the button issue) > > https://github.com/RIOT-OS/RIOT/issues/5407 > > Best > Peter > > Am 20.07.2016 um 16:22 schrieb Thomas Eichinger: > > Hi Adeel, > > > > the transceiver uses the cpuid module to generate hwaddr. If your > > port is based on the stm32f4discovery board it should be > > configured already which makes me think there might still be some > > nit in your SPI > >>> connection. > > > > You could try to issue `ifconfig set addr `. If you > > then do `ifconfig` aga
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Adeel, not sure I fully understand you previous mail. The driver will generate a default hardware address which is based on the CPUID. USEMODULE += at86rf233 AFAIK one of these modules is actually responsible for that USEMODULE += gnrc_netdev_default USEMODULE += auto_init_gnrc_netif You already have this in. Otherwise there won't be any hardware access. If you try examples/gnrc_networking (maybe at first in native) and type "ifconfig" you will see that the network interface has some ipv6 addresses. The local unicast address is based on the hardware address which was explained previously. I currently don't know which module attaches these ip addresses, maybe @miri64 can say more? Anyway, please try to get the transceiver running with tests/driver_at86rf2xx and examples/gnrc_networking before using it on a border router. Best Peter Am 27.07.2016 um 09:36 schrieb Adeel Mohammad Malik: Hi Peter, Do you mean I should get an address on my interface without having to configure it manually? If so, which module (USEMODULE) is it exactly that has this effect? /Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Monday, July 25, 2016 8:40 AM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Adeel, generation of the CPUID shouldn't be a problem. I checked it on an stm32f4discovery board. Can you try it with examples/gnrc_networking? "ifconfig" works there as well. The f4 board usually has no network interface and now you're about to initialize two. I could imagine it's just a configuration problem but to be sure, please check gnrc_networking first. Best Peter Am 21.07.2016 um 12:11 schrieb Adeel Mohammad Malik: Hi again, I think I got the SPI connection right now. I just configured an address using ifconfig and was able to change the address. I am still not getting an address automatically which as Thomas mentioned I should be getting using the cupid module. Seems like I am missing a module in my Makefile. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Thursday, July 21, 2016 11:29 AM To: 'RIOT OS kernel developers' Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi again, I just used the following pin configuration for the AT86RF233 transceiver now:- #define AT86RF2XX_PARAMS_BOARD { .spi = SPI_0, \ .spi_speed = SPI_SPEED_5MHZ, \ .cs_pin = GPIO_PIN(PORT_E, 0), \ .int_pin = GPIO_PIN(PORT_E, 1), \ .sleep_pin = GPIO_PIN(PORT_E, 2), \ .reset_pin = GPIO_PIN(PORT_E, 3)} I still have the same problem. I have the following relevant modules included in my Makefile:- ... USEMODULE += gnrc_netdev_default USEMODULE += auto_init_gnrc_netif GNRC_NETIF_NUMOF := 2 USEMODULE += ethos gnrc_netdev2 CFLAGS += '-DETHOS_UART=UART_DEV(0)' -DETHOS_BAUDRATE=115200 - DUSE_ETHOS_FOR_STDIO USEMODULE += at86rf233 ... Any hints/clues would be appreciated. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Wednesday, July 20, 2016 6:33 PM To: RIOT OS kernel developers Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Peter and Thomas, I was quite skeptical about my pin connections/configurations. I did realize that the default pin mapping of the Atmel driver could be a problem so I had already defined my own pin mapping in the file "/boards/stm32f4discovery/include/board.h" before writing to the mailing list. I defined it as follows:- #define AT86RF2XX_PARAMS_BOARD { .spi = SPI_0, \ .spi_speed = SPI_SPEED_5MHZ, \ .cs_pin = GPIO_PIN(PORT_A, 0), \ .int_pin = GPIO_PIN(PORT_E, 0), \ .sleep_pin = GPIO_PIN(PORT_E, 1), \ .reset_pin = GPIO_PIN(PORT_E, 2)} After reading the thread that Peter referred to, I checked the file "/boards/stm32f4discovery/include/board.h" and saw that there is an overlap on PA0:- #define BTN_B1_PIN GPIO_PIN(PORT_A, 0) The reason I defined AT86RF2XX_PARAMS_BOARD as above is the link https://github.com/RIOT-OS/RIOT/wiki/Board%3A-STM32F4discovery where a picture of the STM32F4DISCOVERY board shows the different pins. I just assumed that GPIO_0 (PA0), GPIO_1 (PE0), GPIO_2 (PE1), GPIO_3 (PE2), as shown in the picture, are not connected to anything and hence free to use. My assumption was obviously wrong. I will fix my pin configuration tomorrow and see if it works for me. Thanks for your replies. You guys are really helpful. Regards, Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Wednesday, July 20, 2016 4:48 PM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi, just as a side note: @Nordzisko has a pretty similar setup wich worked (except the button issue) https://github.com/RIOT-OS/RIOT/issues/5407 Best Peter Am 20.07.2016 um 16:22 schrieb Thomas Eichinger: H
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi again, I was talking about the HWaddr. I want to run the CCN stack directly over the radio without any IP stack. Does the CPUID module also configure the hardware addresses? /Adeel > -Original Message- > From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter > Kietzmann > Sent: Wednesday, July 27, 2016 10:25 AM > To: RIOT OS kernel developers > Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > Hi Adeel, > > not sure I fully understand you previous mail. The driver will generate a > default hardware address which is based on the CPUID. > > USEMODULE += at86rf233 > > AFAIK one of these modules is actually responsible for that > > USEMODULE += gnrc_netdev_default > USEMODULE += auto_init_gnrc_netif > > You already have this in. Otherwise there won't be any hardware access. > If you try examples/gnrc_networking (maybe at first in native) and type > "ifconfig" you will see that the network interface has some ipv6 addresses. > The local unicast address is based on the hardware address which was > explained previously. > > I currently don't know which module attaches these ip addresses, maybe > @miri64 can say more? Anyway, please try to get the transceiver running > with tests/driver_at86rf2xx and examples/gnrc_networking before using it > on a border router. > > Best > Peter > > > Am 27.07.2016 um 09:36 schrieb Adeel Mohammad Malik: > > Hi Peter, > > > > Do you mean I should get an address on my interface without having to > configure it manually? If so, which module (USEMODULE) is it exactly that has > this effect? > > > > /Adeel > > > >> -Original Message- > >> From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter > >> Kietzmann > >> Sent: Monday, July 25, 2016 8:40 AM > >> To: RIOT OS kernel developers > >> Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > >> > >> Hi Adeel, > >> > >> generation of the CPUID shouldn't be a problem. I checked it on an > >> stm32f4discovery board. Can you try it with examples/gnrc_networking? > >> "ifconfig" works there as well. > >> > >> The f4 board usually has no network interface and now you're about to > >> initialize two. I could imagine it's just a configuration problem but > >> to be sure, please check gnrc_networking first. > >> > >> Best > >> Peter > >> > >> > >> > >> Am 21.07.2016 um 12:11 schrieb Adeel Mohammad Malik: > >>> Hi again, > >>> > >>> I think I got the SPI connection right now. I just configured an > >>> address using > >> ifconfig and was able to change the address. I am still not getting > >> an address automatically which as Thomas mentioned I should be > >> getting using the cupid module. Seems like I am missing a module in my > Makefile. > >>> > >>> /Adeel > >>> > -Original Message- > From: Adeel Mohammad Malik > Sent: Thursday, July 21, 2016 11:29 AM > To: 'RIOT OS kernel developers' > Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > Hi again, > > I just used the following pin configuration for the AT86RF233 > transceiver > now:- > > #define AT86RF2XX_PARAMS_BOARD { > .spi = SPI_0, \ > .spi_speed = SPI_SPEED_5MHZ, \ > .cs_pin = GPIO_PIN(PORT_E, 0), \ > .int_pin = GPIO_PIN(PORT_E, 1), \ > .sleep_pin = GPIO_PIN(PORT_E, 2), \ > .reset_pin = GPIO_PIN(PORT_E, 3)} > > I still have the same problem. I have the following relevant > modules included in my Makefile:- > > ... > USEMODULE += gnrc_netdev_default > USEMODULE += auto_init_gnrc_netif > GNRC_NETIF_NUMOF := 2 > USEMODULE += ethos gnrc_netdev2 > CFLAGS += '-DETHOS_UART=UART_DEV(0)' - > DETHOS_BAUDRATE=115200 > >> - > DUSE_ETHOS_FOR_STDIO USEMODULE += at86rf233 ... > > Any hints/clues would be appreciated. > > /Adeel > > > -Original Message- > > From: Adeel Mohammad Malik > > Sent: Wednesday, July 20, 2016 6:33 PM > > To: RIOT OS kernel developers > > Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > > > Hi Peter and Thomas, > > > > I was quite skeptical about my pin connections/configurations. I > > did realize that the default pin mapping of the Atmel driver could > > be a problem so I had already defined my own pin mapping in the > > file "/boards/stm32f4discovery/include/board.h" before writing to > > the mailing list. I defined it as follows:- > > > > #define AT86RF2XX_PARAMS_BOARD { > > .spi = SPI_0, \ > > .spi_speed = SPI_SPEED_5MHZ, \ > > .cs_pin = GPIO_PIN(PORT_A, 0), \ > > .int_pin = GPIO_PIN(PORT_E, 0), \ > > .sleep_pin = GPIO_PIN(PORT_E, 1), \ > > .reset_pin = GPIO_PIN(PORT_E, 2)} > > > > After reading the thread that Peter referred to, I checked the > > file "/boards/stm32f4discovery/include/board.h" and saw that there >
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi, as said, the radio driver uses the CPUID for hardware address generation, so yes. See this line and following: https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L77 Best Peter Am 27.07.2016 um 10:35 schrieb Adeel Mohammad Malik: Hi again, I was talking about the HWaddr. I want to run the CCN stack directly over the radio without any IP stack. Does the CPUID module also configure the hardware addresses? /Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Wednesday, July 27, 2016 10:25 AM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Adeel, not sure I fully understand you previous mail. The driver will generate a default hardware address which is based on the CPUID. USEMODULE += at86rf233 AFAIK one of these modules is actually responsible for that USEMODULE += gnrc_netdev_default USEMODULE += auto_init_gnrc_netif You already have this in. Otherwise there won't be any hardware access. If you try examples/gnrc_networking (maybe at first in native) and type "ifconfig" you will see that the network interface has some ipv6 addresses. The local unicast address is based on the hardware address which was explained previously. I currently don't know which module attaches these ip addresses, maybe @miri64 can say more? Anyway, please try to get the transceiver running with tests/driver_at86rf2xx and examples/gnrc_networking before using it on a border router. Best Peter Am 27.07.2016 um 09:36 schrieb Adeel Mohammad Malik: Hi Peter, Do you mean I should get an address on my interface without having to configure it manually? If so, which module (USEMODULE) is it exactly that has this effect? /Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Monday, July 25, 2016 8:40 AM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Adeel, generation of the CPUID shouldn't be a problem. I checked it on an stm32f4discovery board. Can you try it with examples/gnrc_networking? "ifconfig" works there as well. The f4 board usually has no network interface and now you're about to initialize two. I could imagine it's just a configuration problem but to be sure, please check gnrc_networking first. Best Peter Am 21.07.2016 um 12:11 schrieb Adeel Mohammad Malik: Hi again, I think I got the SPI connection right now. I just configured an address using ifconfig and was able to change the address. I am still not getting an address automatically which as Thomas mentioned I should be getting using the cupid module. Seems like I am missing a module in my Makefile. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Thursday, July 21, 2016 11:29 AM To: 'RIOT OS kernel developers' Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi again, I just used the following pin configuration for the AT86RF233 transceiver now:- #define AT86RF2XX_PARAMS_BOARD { .spi = SPI_0, \ .spi_speed = SPI_SPEED_5MHZ, \ .cs_pin = GPIO_PIN(PORT_E, 0), \ .int_pin = GPIO_PIN(PORT_E, 1), \ .sleep_pin = GPIO_PIN(PORT_E, 2), \ .reset_pin = GPIO_PIN(PORT_E, 3)} I still have the same problem. I have the following relevant modules included in my Makefile:- ... USEMODULE += gnrc_netdev_default USEMODULE += auto_init_gnrc_netif GNRC_NETIF_NUMOF := 2 USEMODULE += ethos gnrc_netdev2 CFLAGS += '-DETHOS_UART=UART_DEV(0)' - DETHOS_BAUDRATE=115200 - DUSE_ETHOS_FOR_STDIO USEMODULE += at86rf233 ... Any hints/clues would be appreciated. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Wednesday, July 20, 2016 6:33 PM To: RIOT OS kernel developers Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Peter and Thomas, I was quite skeptical about my pin connections/configurations. I did realize that the default pin mapping of the Atmel driver could be a problem so I had already defined my own pin mapping in the file "/boards/stm32f4discovery/include/board.h" before writing to the mailing list. I defined it as follows:- #define AT86RF2XX_PARAMS_BOARD { .spi = SPI_0, \ .spi_speed = SPI_SPEED_5MHZ, \ .cs_pin = GPIO_PIN(PORT_A, 0), \ .int_pin = GPIO_PIN(PORT_E, 0), \ .sleep_pin = GPIO_PIN(PORT_E, 1), \ .reset_pin = GPIO_PIN(PORT_E, 2)} After reading the thread that Peter referred to, I checked the file "/boards/stm32f4discovery/include/board.h" and saw that there is an overlap on PA0:- #define BTN_B1_PIN GPIO_PIN(PORT_A, 0) The reason I defined AT86RF2XX_PARAMS_BOARD as above is the link https://github.com/RIOT-OS/RIOT/wiki/Board%3A-STM32F4discovery where a picture of the STM32F4DISCOVERY board shows the different pins. I just assumed that GPIO_0 (PA0), GPIO_1 (PE0), GPIO_2 (PE1), GPIO_3 (PE2), as shown in the
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Dear release-preparing IOTlers, do we have an Etherpad with an agenda for today's meeting? If not, do we need one? Cheers, Oleg On Tue, Jul 26, 2016 at 12:00:07PM +, Google Calendar wrote: > This is a notification for: > > Title: Biweekly virtual meeting > Developer discussions that will only happen if a proposed agenda exists. > Some instructions and a link to the agenda can be found in the RIOT wiki > (https://github.com/RIOT-OS/RIOT/wiki/Meetings). Remote participation will > be provided. > When: Wed Jul 27, 2016 2pm – 3pm Berlin > Calendar: RIOT Events > Who: > * Ludwig Ortmann - creator > > Event details: > https://www.google.com/calendar/event?action=VIEW&eid=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA3MjdUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn > > Invitation from Google Calendar: https://www.google.com/calendar/ > > You are receiving this email at the account peterschme...@gmail.com because > you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings for > this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn more at > https://support.google.com/calendar/answer/37135#forwarding > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel -- panic("aha1740.c"); /* Goodbye */ linux-2.2.16/drivers/scsi/aha1740.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Hi, as always you can find the link to an etherpad here: https://github.com/RIOT-OS/RIOT/wiki/Meetings under point "Agenda for the next virtual meeting". There is not topic on the agenda so we skip this meeting. Best Peter Am 27.07.2016 um 14:01 schrieb Oleg Hahm: Dear release-preparing IOTlers, do we have an Etherpad with an agenda for today's meeting? If not, do we need one? Cheers, Oleg On Tue, Jul 26, 2016 at 12:00:07PM +, Google Calendar wrote: This is a notification for: Title: Biweekly virtual meeting Developer discussions that will only happen if a proposed agenda exists. Some instructions and a link to the agenda can be found in the RIOT wiki (https://github.com/RIOT-OS/RIOT/wiki/Meetings). Remote participation will be provided. When: Wed Jul 27, 2016 2pm – 3pm Berlin Calendar: RIOT Events Who: * Ludwig Ortmann - creator Event details: https://www.google.com/calendar/event?action=VIEW&eid=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA3MjdUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this email at the account peterschme...@gmail.com because you are subscribed for notifications on calendar RIOT Events. To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Hello! Not in my knowledge… Do you want to discuss something special? As the release is taking place I don’t know about the availability of people to discuss. Cheers, -- Francisco Javier Acosta Padilla Research Engineer at INRIA Saclay INFINE Team On 27 July 2016 at 14:02:56, Oleg Hahm (oliver.h...@inria.fr) wrote: Dear release-preparing IOTlers, do we have an Etherpad with an agenda for today's meeting? If not, do we need one? Cheers, Oleg On Tue, Jul 26, 2016 at 12:00:07PM +, Google Calendar wrote: > This is a notification for: > > Title: Biweekly virtual meeting > Developer discussions that will only happen if a proposed agenda exists. > Some instructions and a link to the agenda can be found in the RIOT wiki > (https://github.com/RIOT-OS/RIOT/wiki/Meetings). Remote participation will > be provided. > When: Wed Jul 27, 2016 2pm – 3pm Berlin > Calendar: RIOT Events > Who: > * Ludwig Ortmann - creator > > Event details: > https://www.google.com/calendar/event?action=VIEW&eid=Z2tqN2ZyY3NmdnEzOWFkbDdmMXJkb2hrbzhfMjAxNjA3MjdUMTIwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn > > > Invitation from Google Calendar: https://www.google.com/calendar/ > > You are receiving this email at the account peterschme...@gmail.com because > you are subscribed for notifications on calendar RIOT Events. > > To stop receiving these emails, please log in to > https://www.google.com/calendar/ and change your notification settings for > this calendar. > > Forwarding this invitation could allow any recipient to modify your RSVP > response. Learn more at > https://support.google.com/calendar/answer/37135#forwarding > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel -- panic("aha1740.c"); /* Goodbye */ linux-2.2.16/drivers/scsi/aha1740.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] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Hi Peter! On Wed, Jul 27, 2016 at 02:09:22PM +0200, Peter Kietzmann wrote: > as always you can find the link to an etherpad here: > > https://github.com/RIOT-OS/RIOT/wiki/Meetings Thanks! Didn't know that there was a permanent link. (Or I forgot.) > under point "Agenda for the next virtual meeting". There is not topic on the > agenda so we skip this meeting. +1 Cheers, Oleg -- The worst thing about Perl jokes is that next morning you can't understand why they seemed so funny. signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Hey Paco! On Wed, Jul 27, 2016 at 02:10:41PM +0200, Francisco Javier Acosta Padilla wrote: > Not in my knowledge… Do you want to discuss something special? As the > release is taking place I don’t know about the availability of people to > discuss. No reason for meeting from my side. Cheers, Oleg -- The four hard things in CS are cache invalidation, naming, and off-by-one errors. signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jul 27, 2016 2pm - 3pm (RIOT Events)
Hi all, the link is not static but it needs to permanently point to a fresh etherpad, according to this explanation in the wiki: Minutes from past meetings are listed further below. If a meeting actually took place, the link to the minutes will move downwards to the archive and a new link for the next meeting will be opened and listed here by a maintainer. Best Peter Am 27.07.2016 um 14:14 schrieb Oleg Hahm: Hi Peter! On Wed, Jul 27, 2016 at 02:09:22PM +0200, Peter Kietzmann wrote: as always you can find the link to an etherpad here: https://github.com/RIOT-OS/RIOT/wiki/Meetings Thanks! Didn't know that there was a permanent link. (Or I forgot.) under point "Agenda for the next virtual meeting". There is not topic on the agenda so we skip this meeting. +1 Cheers, Oleg ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel