• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 327 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Ideal programming, building, debugging setup for dm365 for a first-timer

T.J.41609
Prodigy 10 points


I am new to the world of DSP and system on a chip type programming, and it's a pretty big change in methodology, terminology, and well everything for me.  I currently have a DM365 evaluation model running DVSDK 2.10, the included MontaVista linux booting from a CentOS machine using nfs.  My development system has both Windows XP and Ubuntu in a dual-boot configuration with a shared drive, so programming on either system is a not a problem.  That said, I have some few questions that are much more basic than what I have found here or elsewhere on the internet.  Any insight would be greatly appreciated

Getting Started

Are there any books, documents, tutorials, blogs or likewise I should read before making the jump into programming for these types of systems?  Anything that can bring me up to speed would be greatly appreciated

Development

  1. What is the best development setup for developing code specifically for an ARM9 (or better, DM365) system.  What programs/items will I need to be as complete as possible?
  2. What is the typical development/building/debugging setup.  I have the board hooked up to a separate machine, and can write locally then deploy to that machine for debugging, but that seems like a PITA. TI's Code Composer (which it seems is the recommended development setup) appears to have the ability to connect directly to a system for running/debugging, but I can't quite figure out how that works.
  3. Are the wiki's the best source of documentation for the DM365 and programming for it?  Is there complete documentation somewhere on the XDC libraries?  Are there any additional libraries I should/could be using specific to this type of work?
  4. Are there any glaring differences between interacting with system hardware/modules on an embedded system like the DM365 as compared to standard linux machines?

DM365

I am currently running DVSDK 2.10 on the included MontaVista linux.  However, now there is the DVSDK 3.10 in beta testing which seems to include royalty-free open-source kernel/distro for the system to run on.  Which of these setups is the recommended setup and why?

Again, thanks for any and all help in clarifying things for me, this is a pretty large leap for me from just your standard development setup (where you can develop and test most things locally).

  • 0
    TI__Mastermind 37340 points

    TJ,

    These are all very good questions; I will do my best to answer them here

    Getting started:

    Since DM365 is an ARM only part + MJCP (MPEG JEPG co-processor), I will focus mostly on the ARM side as MJCP is pretty well abstracted by the software we provide.  On the ARM side, we provide a Linux environment.  Linux is very flexible (often developers have access to source code) and allows developers control of programming at various software layers depending on their need.  The tradeoff of course is that given the amount of choices, the right choice can be difficult to make since it requires undestanding of these choices along with coping with how fast the OS keeps evolving.  Therefore, to answer your question how would one get started?  Well, it would depend on your task.  If your task is to write Linux drivers, then this free online book is a great source.  If you are developing applications however, then you will have to decide on one of the various desktop managers available and buy a book more geared towards that software tool.  Since TI is a silicon vendor, we play more at the low level software enabling customers easy use of our hardware; much of the application space software choices (often silicon independant) are left to the end user.  We have wikis, forums, training (free online sessions, as well as multi-day workshops) and of course technical support.  In addition, our DVSDKs contain relevant documentation to help you understand our software (see the various doc folders in the corresponding DVSDK software components).  Finally, your feedback on what we can improve or make it easier for our customers to work with our products is always welcomed.

    Development:

    There are three main software pieces developers are concerned with under Linux:  the boot-loader (u-boot), the kernel (uImage) and the file-system.  During development phase, most developers load boot-loader from flash (NOR or NAND), the kernel from host (via TFTP) and the file-system from host (via NFS).  The bootloader enables just enough of the hardware (ethernet) to allow host (e.g. Ubuntu w/ DVSDK install) interaction and cross-development.  This way, developers take advantage of the faster PC CPU for development/build and only transfer the software to the DM365 board to run in stand-alone mode when it is pretty final.  This is common pratice in embedded systems in general. 

    That said, CCS is a great tool for DSP development, but not sure I would recommend it for ARM development.  Since DM365 does not have a DSP, this may not be the right tool for you.  For ARM development, especially in Linux see http://wiki.davincidsp.com/index.php/Linux_Debugging_Overview ; this article covers some considerations, but of course there are plenty of choices out there.  Linux normally uses serial port or ethernet for debugging, and does away with expensive JTAGs,

    To simplify your life, commercial distros normally include a limited set of options along with tools of their choosing.  For example, MV (MontaVIsta) provides their file system with GTK+ for graphics, you can download other open source graphics libraries if you wish, but by limiting your choices MV hopes to make your life easier; they also provide their DevRocker commercial IDE for development and debugging.  Of course you pay for these commercial distros which can save you time; optionally you can use the open source tools which are not as nice and will require more time and expertise on your part.

    DM365:

    DVSDK 2.10 is based on MV kernel (2.6.18 kernel) which has been our traditional Linux partner; however, many of our customers have expressed the desire to work with newer kernels and we have listened.  Therefore, the next DVSDK release will be based on a community kernel (2.6.29 or newer if I recall correctly).  FYI, commercial kernels such as MVs normally ensure stability of the software at the expense of using an older proven kernel; however, some of the newer innovation in the community kernel can take 2 years or so to trickle down into a commercial distro (e.g. 2.6.18 is over 2 years old).  Therefore, there is a tradeoff.  MV will still offer their commercial distro for those customers who wish to buy it, but we needed to offer customer a choice to use a newer kernel hence all future DVSDKs will be based on community kernels which TI is actively contributing to.

    Technically, due to open source GPL licensing, both kernels are free to use.  You typically pay MV for support, patch updates, and do not forget the DevRocket IDE tool.  I am no lawyer (disclaimer), but I believe you are free to go to production with either kernel if you do not want to pay for these value added services...