Home arrow Blog arrow Zigbee arrow Freescale MC13224 Review
Freescale MC13224 Review | Print |
Written by Akiba   
Sunday, 22 June 2008

[Akiba] I spent the weekend checking out the Freescale MC13224 datasheet and writing the review. There are a lot of features so this is going to be a long post. For my sake, I've divided it up into sections. So grab a cup of coffee and sit back 'cuz this is gonna take some time...[/Akiba]

Freescale recently announced its MC13224 Platform in Package chip. Aside from the attempt at creating a new semiconductor marketing buzzword, it's a highly integrated chip that is almost an entire 802.15.4/Zigbee module on one chip. This is Freescale's 3rd generation 802.15.4 radio and it is definitely head and shoulders above its previous 802.15.4 SoC, the MC1321x series. The chip comes in a 9.5 x 9.5 mm, 99-pin LGA package and supports a temperature range of -40 to 105 degrees Celsius, otherwise known as industrial temp.

MCU
Just as a reference, the MC1321x series was based on the HCS08 line of 8-bit micros and feature tiny amounts of RAM and flash. The largest of the series, MC13213, had 60 kB of flash and 4 kB of RAM. In terms of Zigbee, you could probably fit the stack inside it, but you wouldn't have much room for anything else. Also, with 4 kB of RAM, it'd be extremely difficult to use that chip as a router. Since a router (ideally) requires a frame buffer pool, routing table, neighbor table, discovery table, indirect transmission queue, address table, binding table, group table, and discovery cache (did I miss anything?), it'd be amazing if you could fit all of that in 4 kB of code and still have room for a decent application.

The resource issue has been addressed in the MC13224. It features an ARM7 TDMI 32-bit processor, one of the first of the SoCs to use an ARM7 in fact. If you don't know about ARM7's, you've probably been hiding underneath a rock for the past 10 years. It's an extremely energy efficient 32-bit microprocessor and there's a wealth of tools available for development on it. There is an open source JTAG tool called OpenOCD which interfaces to the GNU Debugger (GDB) and also includes schematics for building your own JTAG hardware probe. The ARM-GCC compiler is actively maintained and has been stable and well optimized for a long time for the ARM7s. Also, there are a lot of OSes that are ported to it such as uCLinux, uCOS-II (RTOS), eCOS (RTOS), and FreeRTOS (RTOS). And that's just some of the open source OSes!

Also for those that believe that 8-bit micros are easier to use than 32-bit ones, I'd beg to differ. If you've ever programmed an 8051 using Keil, you'd know that you have to use a lot of non-ANSI compiler specific extensions due to limitations of the microcontroller. On the other hand, you can program an ARM7 in (almost) 100% ANSI C and have it portable to an AVR, MIPS, x86, or any other chip that supports an ANSI compiler.

Okay…enough with the microcontroller architecture preaching…let's get back to business...

 MCU Memory Configuration
As mentioned, the MCU consists of an ARM7 that can run at up to 26 MHz. It'd be funny to try overclocking this chip, but that's another post. According to the specs, this chip comes with 128 kB of flash memory and 96 kB of RAM. Wow…that's a lot of RAM. However if you look at the datasheet more closely, you'll see that they are using serial flash. This means that on startup, the MCU will need to copy the serial flash into RAM and run out of RAM. That means that if you are using 60 kB of flash for your stack, then you're available RAM will be 36 kB because the other 60 kB of RAM will be used as an image of your code.  One interesting question is why they used a 128 kB serial flash, but only include 96 kB of RAM. This means that if you're stack is greater than 96 kB, your SOL (shit out of luck) because your stack won't fit into RAM.

They also included 80 kB of mask ROM in which they burned their 802.15.4 MAC stack. Code can be run directly from the ROM so none of your RAM will need to be wasted to image the ROM code. I need to get more information regarding the ROM code because if you need to hook into it via compiler to use it, then it will be incompatible with the GPL. According to the GPL, all source code that is statically linked will itself fall under the GPL. This is called reciprocation and it prevents people from using open source code without opening up their own code. It also means that GPL code can only be used with other GPL-compatible code. This is only an issue with my project though and probably won't affect the larger WSN community much.

There is a bigger issue that I can see in using the 802.15.4 stack in the ROM and that is customer lock-in. If you use the Freescale MAC, the stack of your choice will need to be written on top of it and that creates a reliance on the Freescale MAC services. This will create a fairly large deterrent in changing platforms since the code would need to be re-written or at least ported to use a different MAC and PHY layer. I can easily imagine the pain of switching from this chip to something like an Ember or TI 802.15.4 SoC. I would say that it's non-trivial so users should be aware of this issue in choosing to use the ROM'd 802.15.4 code.

Aside from my obviously paranoid issues, there are some benefits in having an 802.15.4. MAC. One of them is that 802.15.4 is becoming increasingly popular for WSN protocols. 6LoWPAN, RF4CE, Zigbee, ISA100, Wirelss HART, Synkro (RF4CE?), SimpliciTI, MiWi, and a bunch of others are gradually converging on this method of transport so it might make the user's life easier to have built-in software support for the MAC.

In regards to the memory configuration, I would say that Freescale should have scrapped the serial flash, scrapped the ROM, implemented a 128 kB parallel flash on the memory bus so they can run directly off of it, reduced the RAM to something like 32 kB, and offered an option to have the 802.15.4 MAC code preprogrammed in the flash. That way, they get rid of the serial flash, ROM, and reduce the RAM. Doing this would have allowed them to offer the same functionality (ie: pre-programmed MAC code) at a lower die cost due to reduced RAM and trashing the ROM. The flash would have been a wash since you'd be replacing 128 kB serial flash with 128 kB parallel flash. Also, there's almost no cost advantage to using mask ROM versus flash these days. Just my 010'b cents.

MCU Peripherals
The MC13224 is rich on peripheral features. I won't spend a huge amount of time on them, however here's a brief overview:

Probably one of the most important of the peripheral features is the ADC. The MC13224 contains dual on-board 12-bit ADCs and 8 analog input channels that can be assigned to either one. As a lot of you know, achieving full 12-bits of ADC resolution is difficult, however according to the datasheet, you can get a very nice 10.5 equivalent number of bits (ENOB) of resolution.

There are many different serial interface options: I2C, SPI, dual UARTs, and even I2S. The I2C interface is good for sensors since it's a common sensor interface. The I2S interface is a little bit unusual in that it's normally associated with audio applications but it can enable easy interfacing to audio chips and DSPs.

There is also a 4x4 matrix keypad interface. It's not surprising that this exists because people that are following the news on my site should know that Freescale is also a principal member of RF4CE. This group is targeting a standard wireless protocol for RF remotes based on 802.15.4. A keypad interface will allow easy design of RF-based remote controls.

And, in my opinion, one of the most important features of an MCU is the development environment. As I mentioned, since the chip is ARM7 based, then we can just use the standard ARM-GCC to write software for it. However Freescale has teamed up with IAR for software development tools which is a bit annoying. This means that their stack and possibly even the ROM code requires an IAR ARM compiler. More research needs to be done on the development environment, however this should only apply to the Freecale Beestack and it's ROM'd MAC. It's too bad though because they'll lose a lot of grassroots support by not providing their Beestack on GCC.

They also mention that they are using a Nexus interface for JTAG debug support. This interface is supposed to provide more functionality for debugging, but it may require a special debugger to access these capabilities. I need to also do research on this to see if the Nexus interface can support OpenOCD. As I mentioned above, OpenOCD is a JTAG debugger that supports ARM chips and is both open source and open hardware. It's also GDB compatible which is a huge, huge, huge benefit. Many years ago, you could only debug ARM micros using the Multi-ICE debugger from ARM which cost about $3,000 and the ADS compiler which was an additional couple thousand.

802.15.4 MAC
Now that the MCU stuff is out of the way, we can get to the nitty-gritty of the chip. The part that most of the readers probably care about is the RF circuitry; more specifically the MAC and radio.

The part comes with an encryption engine which I believe is a required component on all 802.15.4 chips now. Wireless is too easy to sniff and hack unless encryption is employed. You can see this just by all the people that freeload off of unsecured wireless connections to access the internet. Actually, I do that also, but you don't want random strangers monitoring your home security system or controlling your network via a rogue node that they set up. Hence the need for encryption for any type of wireless network.

The Freescale MAC comes with automated features including Auto-ACK on received frames, auto-ACK checking on transmitted frames (retry on timeout if valid ACK is not received), and even automated beacon mode support.

Since the datasheet is still in a preliminary condition, registers and detailed specifics were not available on the automated MAC functions. The description of the MAC ran about two pages as of this post, which is not a lot of room to provide details. It's still not clear how they are handling the Auto-ACK transmission. As I mentioned in the previous review of the Atmel AT86RF23x, the Auto-ACK transmission is tricky. You need to account for the special function of the ACK to signal pending data on indirect transmissions. This is part of the 802.15.4 spec. This requires some sophistication on the hardware logic. If this feature is not implemented correctly, then having Auto-ACK is almost meaningless. In that case, you would need to check every frame to see if it's a data request and if so, do a bunch of processing and finally set a flag to set the pending_data bit. The timing of doing this is tricky so it's almost easier to turn off Auto-ACK altogether and handle ACK's manually. On their datasheet, they state that they support "assist for efficient response to MAC data.request" so it remains to be seen how the assist is implemented.

Freescale implemented a DMA function to automatically transfer a frame from the Rx FIFO to data memory and the memory to the TX FIFO. This is more beneficial on the Rx side since you have no control over when frames come in. Since the FIFO size is limited, automating the movement of data from the FIFO to memory has the advantage that even if your application is heavy enough to slow the response time of the CPU, you won't have to worry about incoming frames overwriting each other in the Rx FIFO since they're automatically sent to memory. This is actually quite a nice feature to have.

A random number generator is also included in the MAC. It seems that in this latest generation of 802.15.4 chips, many companies are now implementing the random number generator. Random numbers are used a lot in the 802.15.4 and Zigbee stacks. Some examples of their usage are: initialization of MAC and NWK sequence numbers, initialization of the APS counter, random jitter of broadcast and route request frames, random delay before transmission of frames, random backoff in CSMA, and of course encryption key generation.

One problem with the random number generator in the MAC is that it's based on a linear feedback shift register (LFSR). Aside from the complicated name, it's basically a simple shift register (string of flip flops) with some XOR logic sprinkled around in a feedback fashion. This type of structure generates a pseudo-random number sequence which means that it will generate a different random number on each access until it spans its complete range at which point it will repeat (ie: for 32-bits this would be ~4 billion random numbers).

LFSRs are frequently used in encryption and communication applications because of it's pseudo-random property where for the same initial seed value, it will generate random numbers in an identical sequence. Hence you can have random numbers but in a repeatable sequence. This is a bad thing for protocol stacks though, where you don't want to have all nodes transmitting frames with the same pattern of frame sequence numbers. This means that you will need to generate a random number for the seed value to your random number generator on each node, a sort of funny catch-22. I guess a possible workaround is to use the node's extended address as the seed for the LFSR, but since this is a 64-bit value, you won't know if the bottom or top word is unique. The Atmel AT86RF23x approaches random number generation in a smarter way which is to sample noise and use that as the random number.

802.15.4 Radio
One of the things that impressed me about the MC13224 is the radio's analog circuitry implementation. They included everything on-board so you theoretically only need a straight PCB trace to a 50 ohm antenna. The PCB layout is the scariest part of designing an RF board because you're at the mercy of your discretes, PCB supplier, and (in my case) lack of RF knowledge. Thus you need to make sure your balun is designed correctly, the discretes are positioned correctly, all traces maintain the correct impedance, and the impedance is matched to the antenna. You normally need some type of simulator if you want to ensure everything is correct, and then you need to verify it with a network analyzer after the PCB comes back. In the Freescale case, everything is already on-board and matched to 50 ohms so you only need to make sure your PCB trace impedance is matched to the 50 ohm antenna. Bypass capacitors are also integrated. Excellent!

Power Management
The MC13224 supports different power down modes which, by now, should be expected of any 802.15.4 chip. It also provides a buck converter which is a nice touch. Most ICs use voltage regulators to drop input voltage from 3.3V to 1.8V (or something like that). The problem with using voltage regulators is that the excess voltage is basically burned off as resistive heat which is inefficient. The 13224 has the option to implement a buck converter which will drop the voltage by switching current on and off. This way, the efficiency is greatly enhanced which is a big advantage for wireless applications. The buck converter requires an external inductor and capacitor, however I think that the increase in battery life should be worth it.

Conclusion
Well, I think I covered most of the key parts of the MC13224. Overall, it looks like a very nice chip and I'm looking forward to a more detailed datasheet which includes the register descriptions. If anyone has anything to add, please feel free to do so. I'd like to hear actual user experiences with this chip.

Hits: 47564
Trackback(0)
Comments (2)Add Comment
...
written by Yifeng, September 27, 2008
Very good review. Thumbs up.

BTW, I didn't find your review on Atmel AT86RF23x. Would you please let me know where it is.

Regarding the auto ack for data request, there is a trick. In 15.4, there is only 54 symbols, or about 850us for you to figure out if there is a pending packet and send out the acknowledgement. Usually, that time period is tight for a MCU to respond promptly. The trick is to let the radio always respond with pending bit set for Data request command. Then the MCU will check if there is a real data for the polling end device. If there is no data pending, just send a packet without any MAC payload or let the end device timeout. Playing this trick will significantly reduce the requirement for MCU speed.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, September 27, 2008
Hi Yifeng.
Yeah, I found out about the trick in the 802.15.4 spec. Its kind of funny because it kind of defeats the purpose of the data pending flag. Looks like its a common practice though.

Here's the link to the Atmel review.
Link
report abuse
vote down
vote up
Votes: +0

Write comment

busy
 

Discuss (26 posts)

Akiba
Re:Freescale MC13224 Review
Feb 11 2009 23:17:26
Thanks for the update on the MC13224. When they say "manually copy the files out of the codebase and make all the changes to configure the stack (old school)", do they mean that the source code is available and we need to manually re-compile it using a GCC-ARM EABI variant?

One of the main issues with requiring IAR as a design tool is that the $5k investment is out of reach of most of the hobbyist/enthusiast/academic developers. Although most companies laugh at this market, they are usually the early adopters and provide feedback on blogs and newsgroups that is used by the engineers at the big companies to evaluate different chip choices. It's always been a frustration of mine that big companies never see this.

By the way, thanks for the link to the CEL module. Looks like the first one out that supports the MC13224. If its possible to bypass Freescale's built-in MAC software and use my own MAC, then I'm interested to check it out. Using GCC of course
#457

spazvt
Re:Freescale MC13224 Review
Feb 11 2009 23:24:14
I believe Freescale's policy is that they make the SMAC source code open, but only provide object files/libraries for the 802.15.4 MAC and BeeStack. If we can find the source, great, but I'm assuming it's other files being referred to.

Good reference describing the different flavors that Freescale offers: http://www.freescale.com/files/rf_if/doc/app_note/AN3403.pdf?fsrch=1
#458
Mads
Re:Freescale MC13224 Review
Feb 17 2009 09:21:06
Hi,

If you examine the FSL dev kits you will see that you get a free 32 KB version of IAR with the kit.

this is plenty for 802.15.4 MAC development as the MAC is in rom and more than pleny for the SMAC as it is very small.

so you do not have to buy a license. (other than that the license is actually not 5K but less - you can get the biggest kit for that price)

br,
Mads
#471

Akiba
Re:Freescale MC13224 Review
Feb 17 2009 09:41:55
Hi Mads.
Any idea if Freescale will ever come out with a GCC port of their Beestack?
#472
Mads
Re:Freescale MC13224 Review
Feb 20 2009 10:36:25
Hi,
You would have to ask Freescale that question.

But i doubt that you will see big coorporations support such compilers due to support reasons. the IAR compilers used by both Freescale and TI are supported and if you got issues you have a place to turn to for support, which is not garanteed with gcc.

other than that you got the hole license issue of mixing open source with closed source

br,
Mads
#489

Akiba
Re:Freescale MC13224 Review
Feb 20 2009 14:27:56
Okay. Just wanted to check, since the IAR compiler is out of range of most of the hobbyist/enthusiast community.

Just as an FYI, GCC has no open source implications on the final compiled binary. Its just that if the libraries were able to be compiled with GCC, it would make it easier for individuals to try out BeeStack as well.
#490

Umberto
Re:Freescale MC13224 Review
Feb 28 2009 18:13:36
It would be interesting to know which kind of issues could arise with a compiler. Typically problems related to a misunderstanding of C language, compilation process and compiler options.

The company where I work is a DAP for Freescale and received some samples of MC13224V since July. I must admit that making that platform to work with GCC is becoming harder day after day.

We are trying to make it work as a bare-metal system, without any use of the embedded ROM and BeeKit libraries: there is a lot of work to do! We succeeded into starting the platform and making some leds flashing.

It would have been very nice to completely use the on-board drivers for all the modules, but we did not succeed in linking BeeKit-IAR libraries with Codesourcery-GCC.

Next step is to make that silicon to be managed by Contiki.
At the end of the roadmap, the user could choose between (Sics)6LoWPAN and/or FreakZ!
#505

Akiba
Re:Freescale MC13224 Review
Mar 09 2009 03:32:52
I would agree that GCC is a better way to go simply because the audience is bigger. The code size and performance differences between GCC and IAR, at least for ARM, are either negligible or very small. However I think the most companies aren't too concerned with catering to the hacker and hobbyist markets that surround GCC. They usually have the opinion that any serious company would purchase IAR if they were going to make a product.

From my experience in sales, it's actually the opposite. At the crucial stages where the decision on chip and platform is first made by the engineers (contrary to popular belief, the decision is not made by managers), being able to use GCC is a big plus because the engineers can compile and test the libraries immediately. Otherwise, the engineers need to fill out additional paperwork for a purchase req for the compiler. And you all know how engineers love paperwork and bureaucracy. This has killed many projects that I have seen.
#517
Chris Herzog
Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Mar 16 2009 21:41:30
It is possible to link the Freescale supplied ABI with GCC generated code but changes to the linker are needed. The relocation formats used are not compatible with the GCC linker out of the box. We've made the changes needed and fed them back to the Code Sorcery folks - we can make them available if someone else wants them as well.

To date, we've experienced much better code density with the IAR compiler compared to GCC - we've spent some time looking into various options to improve this but there no obvious low hanging fruit; more a lot of small things that need to be tried and evaluated.

It'd be nice because saving money on dev tools appeals to everyone but in the end; time is money and getting something done faster and smaller has real value as well...


Chris Herzog [email protected]
#527

Umberto
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Mar 17 2009 09:00:49
Obviously, it would be very interesting to have those patches, in order to compiler IAR-BeeKit libraries with GCC.

I think that the core of this thread is more philosophical than practical. The code size - sometimes - depends on how you write code and on the knowledge of the platform and the optimizations the compiler uses.

It is straightforward that using opensource tools can be awkward and could make code to grew of some kilobytes; but at the end, I think it is strictly related to what you consider the real value of a company: development tools (and speed-up in creating new solutions) or people working on that solutions.
#528

Akiba
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Mar 17 2009 11:53:02
On one hand, IAR's ARM compiler can actually produce tighter compiled code. However especially for ARM architectures, GCC is the weapon of choice. By forsaking this compiler, you're making it very difficult for the majority of the ARM users to evaluate the stack, and in my opinion, shooting yourself in the foot.

Even though IAR can produce tighter code, saving a couple of kilobytes doesn't matter in many ARM designs, especially if the designer is already familiar with GCC. And since GCC is the compiler used for embedded Linux, which is particularly strong on ARM9 chips, I would say that the installed base of GCC ARM users is much larger than the installed base of IAR ARM users.

It's none of my business, and I don't really care which compiler is supported by Freescale, however if you ask me about IAR vs GCC for ARM architectures, then I would definitely say GCC-ARM...hands down...
#529
Heiko Witthoeft
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Apr 24 2009 10:58:17
Hi,
i have ported the mc13224 on an GCC compiler (Rowley Crossworks) it runs very fine now, the last device missing is the Modemdevice, they havent described all the registers, so we have to reengineer a bit ^^. Well just wanted to say that it is possible to use the device under GCC.

But there is no way to use the ROM-functions. If someone has completed the work with the modem without any freescale software, im glad for an solution. if there are questions from your site:
[email protected]
#673

Akiba
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Apr 24 2009 11:46:28
Wow, that's great that you got the MC13224 working on GCC. I wish Freescale would provide native support for it. There's an open source project for the MC13224 by RedWire as well. Here's the url: http://mc1322x.devl.org/
#674

Umberto
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Apr 24 2009 20:38:18
It is possible to use ROM functions, but you cannot get the "benefits" of ROM-patching!
The code stored in http://mc1322x.devl.org seems quite good. I think Mariano Alvira did a great job with reverse-engineering of radio initialization functions.

In order to employ the ROM functions, you should use the code as provided by Mariano and the header files provided with Freescale's Beekit (both MAC and SMAC based solutions).

To use ROM functions you have to perform a few steps:

  1. extract the ROM symbols from the provided libraries
    Code:

    arm-elf-objdump -t LLC.a | grep ABS | awk '{printf( "0x%s, %s\n", $1, $6 )}'

    and keep only those symbols whose address is below 0x00400000 and - at the same time - are listed into Freescale's headers


  2. for each pair <address, symbol>, you should put an entry in an assembly file, following this example:
    Code:

    .global uart_open
    .type uart_open, %function
    .thumb_set uart_open, 0x00002a98
    .weak uart_open


    The listed example shows the definition of a symbol "uart_open" (aka UartOpen) as a thumb function for MC1322X revision 2.0.



We succeeded in making the MC1322X to run a complete Contiki image, but we enjoyed the work at mc1322x.devl.org for the radio initialization!

In case you need some more information, do not hesitate to contact me
([email protected])!
#676

Akiba
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Apr 25 2009 01:58:57
Wooo...that's right...show Freescale who's boss (of GCC). Excellent post Umberto and thanks for sharing your experience with everyone. Now I'm excited to try out the code from RedWire...just need to get back in gear with this damn stack...
#678
Heiko Witthoeft
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Apr 25 2009 08:06:19
Well in Crossworks i could import the LLC.a directly in the Linker options, so i can use the Rom functions directly. But if i use any of them at the end nothing happens and my µC is running in the "undef handler"...

I can debug that he jumps to the right adress to use the rom function, but it isnt working for me.
#680

Mariano Alvira
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Apr 25 2009 11:35:58
Heiko,

Make sure that you have the proper code located at the RP vectors and that you've reserved space for the ROM variables
(see http://git.devl.org/?p=malvira/mc1322x-tests.git;a=blob_plain;f=src/start.S):

/* these vectors are used for rom patching */
.org 0x20
.code 16
_RPTV_0_START:
bx lr /* do nothing */

.org 0x60
_RPTV_1_START:
bx lr /* do nothing */

.org 0xa0
_RPTV_2_START:
bx lr /* do nothing */

.org 0xe0
_RPTV_3_START:
bx lr /* do nothing */

.org 0x120
ROM_var_start: .word 0
.org 0x7ff
ROM_var_end: .word 0
.code 32

So far, they don't seem to use the patch vectors for anything yet, but the ROM services I've tried so far jump into them. (except for rom_data_init)

Also, the services I've tried are in THUMB and _do not_ interwork with ARM code (except for rom_data_init which is in ARM --- I haven't tried calling it from THUMB code but I can guess the answer!)

Let me know what service you are trying to call if you are still having trouble. There very well could be something "special" about some of them.

-Mar.
#681

Mariano Alvira
Re:Using GCC with BeeStack other Freescale supplied code (was Re:Freescale MC13224 Review)
Apr 25 2009 11:46:39
Umberto,

I've started work on supporting contiki but got bogged down learning how ARM interrupts work and poking at OpenOCD support. Have you/are you going to publish any of your work here? (I have, by-the-way, timer interrupt examples done now)


-Mar.
#682

Chalo
Re:Freescale MC13224 Review
Jul 01 2009 00:19:14
I just found this review today and is very interesting!

I'm currently evaluating the MC1322 and I find annoying the fact that using Freescale's stack kind of forces the use of IAR compiler.

I was wondering if somebody out there has actually bought the IAR Compiler license... I was told that the network floating licenses have a 'feature' that locked the compiler to the user that checked out the license seat for 30 minutes and so another user couldn't use it until the lock timed out. This means that if two users are working on the same project they would have to coordinate the use of the compiler license which kind of sucks. Has anybody else heard about this? I'm curious about how an IAR user rates the licensing... other than Freescale or IAR people.

Many thanks!
#958

Akiba
Re:Freescale MC13224 Review
Jul 01 2009 00:41:10
#959

Umberto
Re:Freescale MC13224 Review
Jul 01 2009 08:49:23
Hi Chalo,
you can find some more code at http://mc1322x.devl.org. It is targeted to employ the transceiver with GCC and no need of beekit provided libraries.

Moreover, at http://www.embit.it, we are developing a GCC based solution to use MC1322x and to completely employ the rom code in order to have a working 802.15.4 stack, without the need to know the register mappings and/or initialization values.

Up to now we have completely rewritten the code for the 802.15.4 stack and we are starting the merge with Contiki OS.

Best regards,
Umberto
#961
faysal
Re:Freescale MC13224 Review
May 05 2010 13:16:16
Umberto,

Are you planning to share your work on stack implementation openly?
#2063
Mariano Alvira
Re:Freescale MC13224 Review
May 05 2010 13:39:17
Not to speak _too much_ for Umberto, but...

he did contribute his work to our project at http://mc1322x.devl.org and it was essential for us to get Contiki working in the first place.

We have since made great progress and are now working directly with the SICS team to mainline our Contiki port for the 2.5 release in June.

libmc1322x is also pretty far along and includes a pretty good radio driver with buffered receive and transmit queues to fully take advantage of the maca DMA transfers (no time wasted copying buffers). With full payloads it gets very close to 250 kbps transfers.

-Mar.
#2064
jannypan
Re:Freescale MC13224 Review
Mar 10 2011 01:06:21
Normalement si le fait de désactiver la protection en temps réel permet de régler le problème, un exclusion de l'analyse, de tous les programmes concernés devrait résoudre le soucis (également exclusion de l'Active Virus Contro depuis 'paramètres' sur l'onglet Antivirus).
#2803
GodFreak
Re:Freescale MC13224 Review
Jul 28 2011 11:14:00
Hey.
I have just started to work on CEL's ZFSM-201-1 that uses MC13224V.
Going through the data sheet of MC13224V, I couldn't figure out the use of Pin # 52 to Pin # 60
viz.
TX_ON
PA_NEG
PA_POS
RF_BIAS
ANT_1
ANT_2
RF_GND
RX_ON
RF_RX_TX


Can anyone spare some time and explain their functions.

And also, since in the module, the microcontroller is connected to the RF module, how do they communicate. I mean, through which pin does the data input/output happens.

Please help.
Thanks.
#3076
There are too many comments to list them all here. See the forum for the full discussion.

Discuss...
< Prev   Next >