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 <your_addr>`. If you > >>>>> then do `ifconfig` again and nothing changed I guess it would be > >>>>> the SPI connection. Else you might miss some configuration still. > >>>>> > >>>>> Best, Thomas > >>>>> > >>>>> On 20 Jul 2016, at 15:16 CEST(+0200), Adeel Mohammad Malik wrote: > >>>>> > >>>>>> Hi Thomas, > >>>>>> > >>>>>> I did as you said. I have 9 wires connected between my > >>>>>> STM32F4Discovery board and the AT86RF233 ZigBit Xplained Pro > >>>>>> Extension board. 4 SPI wires, 3 GPIO wires and 2 for power (+3.3V > >>>>>> and > >>>> GND). > >>>>>> > >>>>>> Now doing an "ifconfig" gives me the following result:- > >>>>>> > >>>>>> ifconfig > >>>>>> Iface 3 HWaddr: 00:00 Channel: 0 Page: 0 NID: 0x0 > >>>>>> Long HWaddr: 00:00:00:00:00:00:00:00 > >>>>>> TX-Power: -17dBm State: IDLE max. Retrans.: 15 > >>>>>> > >>>>>> Source address length: 2 > >>>>>> > >>>>>> Iface 4 HWaddr: 00:15:01:00:40:e4 > >>>>>> > >>>>>> Source address length: 6 > >>>>>> > >>>>>> I was expecting to see a valid HWaddr but this doesn't look right. > >>>>>> Should I be able to see a HWaddr if the connection is alright? > >>>>>> > >>>>>> /Adeel > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of > >>>>>>> Thomas Eichinger > >>>>>>> Sent: Wednesday, July 20, 2016 2:17 PM > >>>>>>> To: RIOT OS kernel developers > >>>>>>> Subject: Re: [riot-devel] Connecting STM32F4Discovery & > >>>>>>> AT86RF233 > >>>>>>> > >>>>>>> Hi Adeel, > >>>>>>> > >>>>>>> please see my answers inline. I hope this helps, let us know if > >>>>>>> there is further open questions. > >>>>>>> > >>>>>>> Best, Thomas > >>>>>>> > >>>>>>> On 20 Jul 2016, at 13:46 CEST(+0200), Adeel Mohammad Malik > wrote: > >>>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> I am struggling a bit to understand how to connect my > >>>>>>>> STM32F4Discovery board with my AT86RF233 ZigBit Xplained Pro > >>>>>>>> Extension board (http://www.atmel.com/tools/ATZB-X-233- > >>>> XPRO.aspx). > >>>>>>>> I have a few questions that I list as follows:- > >>>>>>>> > >>>>>>>> > >>>>>>>> * When connecting the SPI interface, is it enough to connect > >>>>>>>> SCK, MISO and MOSI? Or should I also connect SS? > >>>>>>> What you refer to as SS (Slave Select) is called CS (Chip > >>>>>>> Select) in RIOT. So yes, you have to connect this pin too to > >>>>>>> actually activate the slave's SPI interface. > >>>>>>> > >>>>>>>> > >>>>>>>> * I see that the file > >>>>>>>> https://github.com/RIOT- > >>>>>>> > >> OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_params.h > >>>>>>>> has some PIN configuration parameters. What is > >>>> AT86RF2XX_PARAM_CS? > >>>>>>>> Looking at the manual for my AT86RF233 board > >>>>>>>> (http://www.atmel.com/Images/Atmel-Wireless-ATZB-X-233- > >>>>>>> XPRO_design_documentation.PDF), > >>>>>>>> on page 3 I see the RESET (AT86RF2XX_PARAM_RESET), SLP_TR > >>>>>>>> (AT86RF2XX_PARAM_SLEEP) and the IRQ > >> (AT86RF2XX_PARAM_INT) > >>>> pins. I > >>>>>>> do > >>>>>>>> not seem to find the corresponding pin for > AT86RF2XX_PARAM_CS. > >>>> Any > >>>>>>>> clues? > >>>>>>> See above. > >>>>>>> > >>>>>>>> > >>>>>>>> * Should I include anything besides USEMODULE += at86rf2xx > >> to > >>>>>>>> be able to use the transceiver? > >>>>>>> In your particular case you will want to include `USEMODULE += > >>>>>>> at86rf233`. > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>> > >>>> -- > >>>> 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 > > _______________________________________________ > > 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 _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
