Hello.
On 01/06/15 15:38, Alexander Aring wrote:
Hi,
On Wed, May 27, 2015 at 12:04:14PM +0200, Stefan Schmidt wrote:
Hello.
On 24/05/15 14:37, Alexander Aring wrote:
This patch adds support for the rzusbstick for the atusb firmware.
More detailed information about this usb stick:
http://www.atmel.com/tools/rzusbstick.aspx
Thanks a lot for working on this. Given that it is still available and the
price is good it can help people to play around with ieee802154 a bit more.
Original I have the rzraven kit:
http://www.atmel.com/tools/rzraven.aspx
Which comes with a special cable and avr dragon programmer. You need
some programmer and wires to the programmers pins. To lookup how to
connect the programmer to the rzusbstick pinout, see:
http://www.atmel.com/Images/doc8117.pdf
page 22 (schematics of the rzusbstick).
Difference between atusb and rzusbstick(rzusb) is mainly the at86rf231
vs at86rf230 one. The rzusb contains the at86rf230 which is a little bit
hard to deal with it (and has a huge errata inside the datasheet).
Nevertheless with small schanges the atusb firmware can run now on the
rzusb. The rzusb contains also a bigger mcu, so we can maybe cache more
pdus for receive handling.
To compile the rzusb firmware call:
make NAME=rzusb
this will generate the rzusb.bin
then call the programmer (in my case avrdude):
avrdude -P usb -c dragon_jtag -p usb1287 -U flash:w:rzusb.bin
Is there any chance we can get the DFU part of the atusb firmware also
running on the rzusb? Sure, it would only work after the initial loading but
updating would be more convenient without the need of a dedicated programmer
cable. Nothing of priority, just thinking out loud here.
Using DFU is possible. On the avr device exists room for Bootloader and
Application code. I need to figure out how this space is set in the atusb.
This setting is done by a fuse setting (BOOTSZ bits), I really don't
like to set fuse bits when I do have one rzusb only. :-) Maybe I can get
some more from the same source where I get the current one.
But then I think running DFU in the bootloader section should be
possible, maybe without change if we can do exact bootloader space like
the atusb. Currently this is also why we don't moving the interrupt vectors
in case of rzusb build of atusb firmware.
Fair enough. No a high priority task anyway. Getting it working fine
first is more important. I just think that in long term it would be more
convenient to update using DFU instead of avrdude. But this really can wait.
NOTE: currently there is no chance (I suppose) to ensure that the atusb
receive the correct firmware, so don't try to flash the atusb with the
rzusb firmware! Also the vendor and product id is the same.
Actually there is some logic inside dfu-util which could handle this.
Firmware wise we don't check as far as I know.
With the 0.2 atusb release I added the DFU suffix which has the vendor and
product id coded inside the suffix of the firmware to validate if we flash
to the correct device and abort if not.
This obviously clashes with re-using same vendor and product ID for rzusb.
Something we should avoid anyway as they are two different devices. It
should be no problem to get another product id for rzusb (vendor stay same
as atusb). Werner should know how the "USB registry" of Qi hardware works.
Most likely a simple text file or wiki page.
That way we get a new product id for the firmware image build for rzusb and
are able to verify the flashing with DFU. Adding the new product id to the
driver table in the atusb driver is easy enough. What so you think?
This currently a RFC, it's a quick hack and I think we should update
more the documentation to support the rzusb.
General comment as Werner already stated. Less ifdef's :)
Try to factor out the parts which are different and have different init
calls for example. Some ifdef's will always stay but reducing them would
already help.
ok. I will clean it up. Then I would be happy if I can upload a
"experimental" firmware on wpan.cakelab.org.
Yes, that sounds like a good plan.
regards
Stefan Schmidt
Signed-off-by: Alexander Aring <alex.aring@xxxxxxxxx>
Cc: Stefan Schmidt <stefan@xxxxxxxxxxxxxxx>
Cc: Werner Almesberger <werner@xxxxxxxxxxxxxxx>
---
atusb/fw/Makefile | 6 ++++++
atusb/fw/atusb.c | 2 ++
atusb/fw/board.c | 24 +++++++++++++++++++++---
atusb/fw/board.h | 30 +++++++++++++++++++++++++++++-
atusb/fw/board_app.c | 18 ++++++++++++++++--
atusb/fw/mac.c | 34 +++++++++++++++++++++++++---------
atusb/fw/spi.c | 29 ++++++++++++++++++++---------
atusb/fw/usb/atu2.c | 15 +++++++++++++++
8 files changed, 134 insertions(+), 24 deletions(-)
diff --git a/atusb/fw/Makefile b/atusb/fw/Makefile
index fb7d9a4..4153859 100644
--- a/atusb/fw/Makefile
+++ b/atusb/fw/Makefile
@@ -18,7 +18,13 @@ CFLAGS = -g -mmcu=$(CHIP) -DBOOT_ADDR=$(BOOT_ADDR) \
-Wall -Wextra -Wshadow -Werror -Wno-unused-parameter \
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
+ifeq ($(NAME),rzusb)
+CHIP=at90usb1287
+CFLAGS += -DRZUSB
+else
CHIP=atmega32u2
+CFLAGS += -DATUSB
+endif
HOST=jlime
BOOT_ADDR=0x7000
diff --git a/atusb/fw/atusb.c b/atusb/fw/atusb.c
index f526844..1f65d53 100644
--- a/atusb/fw/atusb.c
+++ b/atusb/fw/atusb.c
@@ -37,11 +37,13 @@ int main(void)
usb_init();
ep0_init();
+#ifdef ATUSB
timer_init();
I don't know why this timer runs on atusb. This is maybe useful for
timing measures, but currently this increments a uint64_t inside some
timer isr. I don't think that is really necessary to have some system
clock. This will increase overhead when doing atusb main tasks.
Maybe its a leftover from some debugging or such? Werner would know I think.
/* move interrupt vectors to 0 */
MCUCR = 1 << IVCE;
MCUCR = 0;
+#endif
sei();
...
-
+#ifdef ATUSB
spi_begin();
spi_send(AT86RF230_REG_WRITE | REG_TRX_CTRL_0);
spi_send(CLKM_CTRL_8MHz);
spi_end();
+#endif
+#ifdef RZUSB
+ spi_begin();
+ spi_send(AT86RF230_REG_WRITE | REG_TRX_CTRL_0);
+ spi_send(0x10);
+ spi_end();
+
This produdes that the at86rf230 will do no clock at CLKM ping but I saw
in the rzusb schematic that this is connected to some clock source of
AT90USB128x. But it's also connected to an 8 Mhz osc. I don't know the
electrical things what they did there, but getting the clock from
at86rf230 it's much cleaner clock source I think.
I lookup the contiki code, so far I see, they disable the pin. I already
tried to run with a 8Mhz clock and there no much changes, both works.
:-)
ok
+ /* TX_AUTO_CRC_ON, default disabled */
+ spi_begin();
+ spi_send(AT86RF230_REG_WRITE | 0x05);
+ spi_send(0x80);
+ spi_end();
I move this out of clkm setting, it's just a hack.
Good.
I looked around to find places to get a rzusb dongle the best offer with
stock I found is this:
http://www.digikey.de/product-search/de?vendor=0&keywords=ATAVRRZUSBSTICK
Is this reasonable? Thinking about getting one to have it for testing.
regards
Stefan Schmidt
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
