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:[email protected]] 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:[email protected]] 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:[email protected]] 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:[email protected]] 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 > >>>>>>>>> [email protected] > >>>>>>>>> https://lists.riot-os.org/mailman/listinfo/devel > >>>>>>>> _______________________________________________ > >>>>>>>> devel mailing list > >>>>>>>> [email protected] > >>>>>>>> https://lists.riot-os.org/mailman/listinfo/devel > >>>>>>> _______________________________________________ > >>>>>>> devel mailing list > >>>>>>> [email protected] > >>>>>>> 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 > >>>>>> [email protected] > >>>>>> https://lists.riot-os.org/mailman/listinfo/devel > >>> _______________________________________________ > >>> devel mailing list > >>> [email protected] > >>> 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 > >> [email protected] > >> https://lists.riot-os.org/mailman/listinfo/devel > > _______________________________________________ > > devel mailing list > > [email protected] > > 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 > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
