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:
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
--
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
