Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Thomas, I am not sure if I completely understand what you say. I debugged the code to see what the "in" pointer gets. It gets a value 0xff which as I mentioned before does not match with AT86RF233_PARTNUM. I think the SPI communication doesn’t work as it should. /Adeel > -Original Message- > From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Thomas > Eichinger > Sent: Thursday, August 04, 2016 3:17 PM > To: RIOT OS kernel developers > Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > Hi Adeel, > > you could try to add a printf() in the `spi_transfer_byte` function in > stm32f4/periph/spi.c for the `in` pointer and see if there are reasonable > values shown > - to make sure SPI communication is working. > > Best, Thomas > > On 3 Aug 2016, at 19:24 CEST(+0200), Adeel Mohammad Malik wrote: > > > The part number is 0xff. It does not match with AT86RF233_PARTNUM > > (0x0b) defined here > ___ > 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] Connecting STM32F4Discovery & AT86RF233
Hi Adeel, you could try to add a printf() in the `spi_transfer_byte` function in stm32f4/periph/spi.c for the `in` pointer and see if there are reasonable values shown - to make sure SPI communication is working. Best, Thomas On 3 Aug 2016, at 19:24 CEST(+0200), Adeel Mohammad Malik wrote: The part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined here ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hey, I asked @Nordzisko for advice. https://github.com/RIOT-OS/RIOT/issues/5407#issuecomment-237543456 As said, I currently won't find time to study the hardware in detail. But I'm pretty convinced that your problems are about configuring the driver or maybe the device itself. About the jumper cables: They do work :-) but I often had loose connections, broken plugs and also confused connections myself. So just be careful ;-). Best Peter Am 04.08.2016 um 14:11 schrieb Adeel Mohammad Malik: Hi Peter, I tried the branch you referred to. I still face the same issue. My guess is that ATZB-X-233-XPRO is a bit different from ATZB-A-233-XPRO in terms of pin configurations. Unfortunately I do not have a logic analyzer. If cheap jumper cables can be a problem, then this can get a bit hard to troubleshoot. /Adeel -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter Kietzmann Sent: Thursday, August 04, 2016 11:44 AM To: RIOT OS kernel developers Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Adeel, please note that issue #5407 is about the F3 discovery so the pin configuration might differ. I connected an openlabs transceiver http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio (basically containing an Atmel AT86RF233) to the stm32f4discovery. This is the configuration that I have used https://github.com/PeterKietzmann/RIOT/tree/stm32f4discovery_add_at86 rf233_config examples/gnrc_networking worked as expected. Could you take that branch, connect your device accordingly and try gnrc_networking again? I currently don't find the time to look into the details of that device but the ATZB-A-233-XPRO basically worked for @Nordziski and from what you describe I have the impression it is a peripheral problem. Do you have a logic analyser to see what is on the SPI bus and the additional pins? I experienced the usage of these cheap jumper cables as a big source of trouble pretty often... Best regards Peter Am 04.08.2016 um 10:17 schrieb Adeel Mohammad Malik: Hi again, By the way, I bought the ATZB-X-233-XPRO module (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx?tab=overview) and not ATZB-A-233-XPRO (http://www.atmel.com/tools/ATZB-A-233- XPRO.aspx?tab=overview). This could possibly be the problem. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Wednesday, August 03, 2016 7:24 PM To: RIOT OS kernel developers Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Peter, What PIN configuration do you use with AT86RF233? I went through the thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for RESET. I want to use PA2 for UART TX. I keep my config same as yours except that I use PE2 for RESET. I still have problems with my SPI connection I presume. I debugged my code and I get a problem here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38. /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` 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: [
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Peter, I tried the branch you referred to. I still face the same issue. My guess is that ATZB-X-233-XPRO is a bit different from ATZB-A-233-XPRO in terms of pin configurations. Unfortunately I do not have a logic analyzer. If cheap jumper cables can be a problem, then this can get a bit hard to troubleshoot. /Adeel > -Original Message- > From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Peter > Kietzmann > Sent: Thursday, August 04, 2016 11:44 AM > To: RIOT OS kernel developers > Subject: Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > Hi Adeel, > > please note that issue #5407 is about the F3 discovery so the pin > configuration might differ. I connected an openlabs transceiver > > http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio > > (basically containing an Atmel AT86RF233) to the stm32f4discovery. This is the > configuration that I have used > > https://github.com/PeterKietzmann/RIOT/tree/stm32f4discovery_add_at86 > rf233_config > > examples/gnrc_networking worked as expected. Could you take that > branch, connect your device accordingly and try gnrc_networking again? > > I currently don't find the time to look into the details of that device but > the > ATZB-A-233-XPRO basically worked for @Nordziski and from what you > describe I have the impression it is a peripheral problem. Do you have a logic > analyser to see what is on the SPI bus and the additional pins? > > I experienced the usage of these cheap jumper cables as a big source of > trouble pretty often... > > Best regards > Peter > > Am 04.08.2016 um 10:17 schrieb Adeel Mohammad Malik: > > Hi again, > > > > By the way, I bought the ATZB-X-233-XPRO module > (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx?tab=overview) and > not ATZB-A-233-XPRO (http://www.atmel.com/tools/ATZB-A-233- > XPRO.aspx?tab=overview). This could possibly be the problem. > > > > /Adeel > > > >> -----Original Message- > >> From: Adeel Mohammad Malik > >> Sent: Wednesday, August 03, 2016 7:24 PM > >> To: RIOT OS kernel developers > >> Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > >> > >> Hi Peter, > >> > >> What PIN configuration do you use with AT86RF233? I went through the > >> thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for > >> RESET. I want to use PA2 for UART TX. I keep my config same as yours > >> except that I use PE2 for RESET. > >> > >> I still have problems with my SPI connection I presume. I debugged my > >> code and I get a problem here https://github.com/RIOT- > >> OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The > >> part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) > >> defined here https://github.com/RIOT- > >> > OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38. > >> > >> /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` 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 b
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Adeel, please note that issue #5407 is about the F3 discovery so the pin configuration might differ. I connected an openlabs transceiver http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio (basically containing an Atmel AT86RF233) to the stm32f4discovery. This is the configuration that I have used https://github.com/PeterKietzmann/RIOT/tree/stm32f4discovery_add_at86rf233_config examples/gnrc_networking worked as expected. Could you take that branch, connect your device accordingly and try gnrc_networking again? I currently don't find the time to look into the details of that device but the ATZB-A-233-XPRO basically worked for @Nordziski and from what you describe I have the impression it is a peripheral problem. Do you have a logic analyser to see what is on the SPI bus and the additional pins? I experienced the usage of these cheap jumper cables as a big source of trouble pretty often... Best regards Peter Am 04.08.2016 um 10:17 schrieb Adeel Mohammad Malik: Hi again, By the way, I bought the ATZB-X-233-XPRO module (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx?tab=overview) and not ATZB-A-233-XPRO (http://www.atmel.com/tools/ATZB-A-233-XPRO.aspx?tab=overview). This could possibly be the problem. /Adeel -Original Message- From: Adeel Mohammad Malik Sent: Wednesday, August 03, 2016 7:24 PM To: RIOT OS kernel developers Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 Hi Peter, What PIN configuration do you use with AT86RF233? I went through the thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for RESET. I want to use PA2 for UART TX. I keep my config same as yours except that I use PE2 for RESET. I still have problems with my SPI connection I presume. I debugged my code and I get a problem here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined here https://github.com/RIOT- OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38. /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` 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/Atm
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi again, By the way, I bought the ATZB-X-233-XPRO module (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx?tab=overview) and not ATZB-A-233-XPRO (http://www.atmel.com/tools/ATZB-A-233-XPRO.aspx?tab=overview). This could possibly be the problem. /Adeel > -Original Message- > From: Adeel Mohammad Malik > Sent: Wednesday, August 03, 2016 7:24 PM > To: RIOT OS kernel developers > Subject: RE: [riot-devel] Connecting STM32F4Discovery & AT86RF233 > > Hi Peter, > > What PIN configuration do you use with AT86RF233? I went through the > thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for > RESET. I want to use PA2 for UART TX. I keep my config same as yours except > that I use PE2 for RESET. > > I still have problems with my SPI connection I presume. I debugged my code > and I get a problem here https://github.com/RIOT- > OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The part > number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined > here https://github.com/RIOT- > OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38. > > /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` 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:- > > >>>> > > >>>> > > >>>> *
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Hi Peter, What PIN configuration do you use with AT86RF233? I went through the thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for RESET. I want to use PA2 for UART TX. I keep my config same as yours except that I use PE2 for RESET. I still have problems with my SPI connection I presume. I debugged my code and I get a problem here https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined here https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38. /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` 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)
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 (PA
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-
&
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` 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
Tho
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
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` 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
&
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
Adeel, we're happy to help and please keep us posted about your progress. Best, Thomas On 20 Jul 2016, at 18:33 CEST(+0200), Adeel Mohammad Malik wrote: I will fix my pin configuration tomorrow and see if it works for me. Thanks for your replies. You guys are really helpful. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
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` 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 hav
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` 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
Re: [riot-devel] Connecting STM32F4Discovery & AT86RF233
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
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
