Actions
Forum Thread Details
  • Replies 17 replies
  • Subscribers 2567 subscribers
  • Views 1564 views
  • Users 0 members are here
Related

Freescale RD3803MMA7660FC review issues

gandrewstone

Hi 7660 reviewers,

 

I've been holding off on my review because I haven't had time to put the device in my own circuit.  Lack of code really is the issue isn't it?  I mean, frankly all that software they gave us and the USB->serial->i2c board is just a cute toy.  Or more realistically they probably made all that for marketing reasons and figured that it could be pawned off as a dev kit.


It would be pretty easy for them to give us a nice API that calls into an unimplemented I2C "underface".  What I mean is that they wouldn't provide the I2c implementation; all the uPs have those anyway... they just provide calls into a "prototypical" I2c library (read, write, etc) and you would translate their calls into your uP's I2C library.


I've been holding off on my formal review on my blog until I can get some code written.  But its interesting I kind of feel like they are getting free labor here... I mean its worth more then $35 bucks of my time to write that code.  But it bugs me that Freescale has clearly already written that code, but for some reason only released an incomplete header file (for example, it does not mention that the I2c address is 0x4c).  Ultimately Freescale is really losing out; the quality of our reviews would be much better and would come out much sooner if they had provided that code.

 

Here are my initial observations for you other reviewers, summarized.

 

0. No code: see rant above :-)


1. There seems to be no way to program the uP on the USB->Serial board.  So I can't change the code to try out my application.


2. The USB protocol is documented, so I could write my program to run on the laptop and use that protocol.  But that would be a lot of throwaway code, and not really test issues like whether my uP can handle the data stream.


3. Putting the chip on its own .1" daughterboard is great!  I can prototype with it.


4. You can buy that little daughter board separately for $35, vs $130 for the whole kit.  Since that's really the only valuable part for real engineering eval, that's what I would buy.


5. I have a handy 5v uP, other uPs have 1.8v.  Wouldn't it have been a lot more useful if their helper board did logic level conversion instead of USB to serial?


In sum, seems like a nice little chip, with a poorly conceived "development" toolkit.  I guess the magic of open source will eventually fix that, esp. if I get some time this weekend! :-)


If you have managed to upload code to the uP or solve any of these other issues, send me a message!

 

Cheers!

Andrew

  • Good morning Andrew.

     

    Your comments summarise the issues that I am also having with this kit.

     

    All it really demonstrates is that, yes it's an accelerometer, and yes it actually works.

    Before I can really do anything useful with it, I will need to design and implement my own board. Unfortunately this is not going to happen any time soon.

     

    Being able to program the processor would have been a great feature.

    At least they did manage to put the device on it's own sub board, which will make it much easier to interface into my own design.

  • Hi,

     

    Totally agree with you. But if something is called as a development kit then programming with that development kit should be provided as well as development platform and sample source codes. As far as i know, it is not a development kit, just an evolution or demonstration kit. So we only have a chance to try it out, that is all. Not sure but if it was announced as a development kit then there is a big wrong here. Invalid naming happens then.

     

    Anyway, as you have already stated, being the sensore a .1 inch socket type makes it great to unplug and plug in a self made board, even on a breadboard.

     

    FIRAT KOCAK

  • Ok, I've got it interfaced to an AVR 328p and am receiving X,Y and Z data and interpreting the shake, tilt, tap register.  I'm going to take a few days to do some cleanup and then attempt to abstract the underlying i2c into the "underface" I described in my first post.  At that point I'll put a link up here for you all to use!

     

    Cheers!

    Andrew

  • Hi guys,

     

    I have worked with some of the Freescale parts and yes, the demo firmware coming with this kit could have been better. Probably, they just put something in the hurry in order to promote the accelerometer part.

    Too bad, because they also added that QG8 uC. They could have put a simple bootloader in it, so the interested parties would have had the possibility to create their own application and use either uC's serial port or the entire kit USB-serial and custom firmware for this. After all the uC has some 8KB of flash and would be quite enough for some custom applications.

     

    I had a look onto the schematic and there's hope. I saw they left the BDM port connection. So, the QG8 part can pe reprogrammed. This would need a BDM type of debugger. Here, there are a few options:

    - buy a BDM kind of debugger

    - build your own

     

    The 2nd option is much more interesting. Freescale has been sampling a version of their uC (having USB device peripheral) which was used as the building brick for a BDM debugger. I myself built one and it works fine. The BOM is very short and beside the uC (I got it in the sampling program), I only had to add a 74VHC125 as the active parts. Otherwise there are a few resistors, caps and that would be all. And last but not least, it is supported in CodeWarrior.

    So, if your interested in programming the uC on that kit, I'll be glad to help you.

     

    Cheers,

     

    Bogdan

  • in reply to bbolo1

    Hi Bogdan,

     

    Yours is beyond a review. Probably many receipient will want to make their own BDM programmer like me. So, please add me to your help list.

     

    Firat Kocak

  • in reply to firatkocak

    Yes please send the details!  I've got the 7660 working on an AVR, but actually I'd like to eval that uP as well!

  • in reply to firatkocak

    Hi Firat,

     

    I don't have a MMA7660 kit, so I cannot review it. I just saw its pictures and read the reviews and it felt the same as I felt when I wanted to change the firmware in a S08 uC but had no tools to do it. SO, I decided to post a message and share my experience for the interested parties.

     

    The starting point in my case was the Freescale forum which is a very good resource of information and tips. (http://forums.freescale.com/)

    There I found out that there are quite a few versions of the BDM debuggers that can be built from samples and they can be used on a wider family of uCs. All the debuggers presented here are open source and that is great!

     

    I started with a simple BDM debugger/programmer based on MC68HC908JB16JDWE which was on the sampling program. I've received the samples in a few days and I was so keen to have my own version so I made a simple one layer PCB and soldered the parts. The neat thing about the JB16 is the fact that it has ROM routines for USB firmware updates. So, when you plug in first your board, it is recognized by the OS and then you can program your own firmware to it. There are some XP utilities (GUI) available on the Freescale website you can use to upload the desired firmware image. Also, the guys on the forum posted additional tools that can be used for diagnosis and programming.

    After programming the BDM debugger, it can be used with CodeWarrior tools (you can download a codesize limited version from the Freescale website; 32KB, I believe) and you have a cheap USB programmer that you can use with the whole S08 family of uCs and as a bonus you an use the same CodeWarrior to program and debug their 32bit family of Coldfire V1 uCs. I've used my debugger with the MCF51JM128 uC and it works fine.

     

    Right now, there's an advanced open source version of the BDM debugger called OSBDM. I haven't built it but I might do it in the future. For time being I am using my JB16 debugger.

     

    Bogdan

  • Now the details

     

    Here's the link where you can find all the necessary resources for building the JB16 BDM debugger (like in my case) http://forums.freescale.com/t5/OSBDM-JM60-Open-Source-BDM-for/USBDM-Version-2-JB16-Version/td-p/49363

     

    Thanks to pgo, the Freescale forum user who spent so much of its time having this neat thing working and being open source).

     

    As a personal advice please check the Freescale website for available samples. JB16 is still in sampling program so you can have a few chips of this kind. I personally got more than one and used some other in a small USB I/O expander project of my own. Quite a handy tool.


    I want to try to build the OSBDM version of the debugger since this kind of debugger supports some other families of Freescale uCs (HCS08, RS08, Coldfire V1 - V4, and the 56F series of DSCs). I think the idea of having a unified debugger is great!

    The OSBDM is based on the MC9S08JM60 uC, which is in sampling program as well. So, if you want a simple version of the debugger, go with the JB16 version. On the other hand the OSBDM is more versatile but the final decision on which one to start is yours.

    Being open-source, you have access to the firmware source code as well as the host DLLs. And there's support for Linux as well.

     

    Keep in touch

     

    Bogdan

  • in reply to bbolo1

    Hello,

     

    just wanted to point out that the OSBDM in its present form is "unified" only in hardware, but the firmware has to be reprogrammed every time you want to work on a different type of target.

     

    The USBDM by pgo has a single firmware that works for HCS08, HCS12, Coldfire V1 (CF1), but the OSBDM has to be reprogrammed with different firmware for each of these target families. And naturally you need some other BDM pod to do the reprogramming ...

     

    best regards,

    Robert

  • in reply to Former Member

    Hi Robert,

     

    I have only built the 908JB16 debugger so far. The OSBDM (having the JM60) would be a much better choice due to at least the higher clocking. The idea of reprogramming the OSBDM with another pod anytime you need a target change (different CPU family) seems a little bit odd. A bootloader in the OSBDM would do a much better job. I have found a document on the Freescale website detailing the OSBDM and its internals.

     

    http://cache.freescale.com/files/soft_dev_tools/doc/user_guide/OSBDM-JM60_Users_Guide.pdf?fsrch=1

     

    Have a look onto page 16 on this document. Jumper J3 is used for bootload mode enable. So, I don't see a need for a separate pod to do the OSBDM firmware reprogramming.

    I am planning to build/buy the OSBDM since I am working quite often with a few CPUs from Freescale. I'll let you know about it when I'll have it. Maybe write a review about it ... image Would this be of any use for the other members?

     

    Cheers,

    Bogdan