On Wed, Apr 23, 2014 at 1:08 AM, Thomas Schmid <[email protected]>wrote:
> The rf233 driver has been modified and tested, not just renamed. But I am > not 100% sure if we did all the mods mentioned in that app note. > On Apr 22, 2014 4:48 PM, "Martin Cerveny" <[email protected]> wrote: > >> Hello. >> >> Thanks for answers. >> >> On Tue, 22 Apr 2014, András Bíró wrote: >> >>> Is there some progress or stable/final/tested code for Atmel newer >>> RF chips on ZigBit (ATZB) modules ? >>> We used the ATZB900 and ATZB24 modules without a problem, with a new >>> platform of course. We dropped the atzb24 in >>> favor of the rfa1, and we dropped the atzb900, because it was very hard >>> to get it in larger quantities, it's >>> expensive, hard to solder on, and we want to use the rfa1's better timer >>> stack. >>> >> >> I am using http://www.an-solutions.de/products/900_mhz.html(mega1281+rf212) >> and preparing migration to rf212b. >> And original zigbit/meshbeen (mega1281+rf230). >> >> >>> RF: >>> - AT86RF233 - compatible with RF230 ? >>> - Atmel module - http://www.atmel.com/tools/ >>> ATZB-RF-233-1-C.aspx >>> Some references: >>> - http://wiesel.ece.utah.edu/projects/10/ >>> - git://wiesel.ece.utah.edu/tinyos/tinyos-prod.git (branch >>> wiesel) >>> >>> With small modifications: >>> http://www.atmel.com/ja/jp/Images/Atmel-42198-Migration- >>> from-AT86RF230-to-AT86RF233_AP-Note_AT02601.pdf >>> The problematic parts: PREP_DEEP_SLEEP, TX_AUTO_CRC_ON, probably more, >>> especially with HWACK. >>> >> >> Is the WIESEL/WREN project driver modified acording to this pdf or only >> "renamed" files & components (Can http://wiesel.ece.utah.edu/ answer >> this question?) ? >> >> >>> I don't know much about xmegas, but they seemed very different from >>> atmegas, so it will probably hard work to make >>> the basic drivers. It's probably doesn't worth it: The ARM based MCUs >>> are much more intresting, and it seems the >>> industry moves towards ARM. >>> >> >> Yes, Xmega is different but it may be possible to implement TinyOS on it >> (with atmel bundles). Yes, ARM (Cortex M0+/M3) is probably right way. >> >> This leads me to new questions: >> >> What is the timeframe of updating https://github.com/tinyos/ >> tinyos-main/tree/master/packaging ? >> >> AVR - to newer toolchain to support new devices (TinyOS: AVR binutils >> 2.22 + gcc 4.6.2 + libc 1.8.0) (Atmel: AVR binutils 2.23.2 + gcc 4.8.1 + >> libc 1.8) >> ( http://distribute.atmel.no/tools/opensource/Atmel-AVR- >> GNU-Toolchain/3.4.3/ ) >> I do some tests on my Solaris/OpenSolaris platform with some issues >> ( https://github.com/tinyos/tinyos-main/issues/139 ). >> >> I saw discussion @dev, any progress/timeline ? >> > I'm waiting for Miklos' code review to push the needed modifications. The toolchain itself might came out after 2.1.3, I'm not sure. But after the modifications, you can use the binaries from atmel - the official package would be the repackaging of that anyway. I'm really impatiant too, at least the progmem fixes should be in 2.1.3. > >> ARM - add & check support for ARM Cortex (not only Atmel) >> (for example http://distribute.atmel.no/tools/opensource/Atmel-ARM- >> GNU-Toolchain/4.7.4/ ) >> >> Does ARM toolchain need special patching for TinyOS/nescc ? >> > Thomas Schmid might have better answer for this, he's the developer for the cortex parts of tinyos. He used CodeBench ARM Toolchain. It works, but the ARM drivers are in a very early stage, and nobody seems to working on them. We tried to make an atmel cortex-m3/cortex-m4 based mote, but developing the drivers to a mature state would take a lot of time, so we shelved the plan. Best, Andras Biro http://ucmote.com >> Thanks, M.C> > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
