• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 85 subscribers
  • Views 671 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.

Original question:

TMS320F28388D: About IPC communication CPU1 to CM

TMS320F28388D: Syntax Issue with Latest DSP2000 IC in CCS

Eric Yuan
Prodigy 125 points

Part Number: TMS320F28388D
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

Tool/software:

Dear TI experts,

I have a simple question regarding the syntax in the latest DSP2000 IC. In my previous code for DSP28335 and even DSP2812, I used the following code to configure the register:

GpioCtrlRegs.GPAMUX1.bit.GPIO0 = 1;

GpioDataRegs.GPASET.bit.GPIO20 = 1;

EPwm1Regs.TBCTL.bit.PHSEN=TB_DISABLE;

However, when I switched to DSP28388, DSP28377, and DSP280049, this syntax no longer works in CCS. Could you explain why?

Best regards,

Eric

  • 0
    TI__Genius 10061 points

    Hi Eric,

    Our expert is Out Of Office, please expect a delay in response.

    Thanks

    Aswin

  • 0 in reply to Aswin P
    TI__Genius 17311 points

    Hi Eric, the devices you have switched to are a newer generation of devices.  They offer better performance, cost, software support, etc. but the software is not 100% portable.  I would recommend checking out our C2000 Academy which offers training on our 'Gen3' devices and I would like to highlight our migration resources from Gen1 to Gen3 devices.  We also have a Sysconfig tool which can be used to help create your peripheral initialization code:

    C2000 Academy: Getting Started with Sysconfig

    SysConfig Video Series

    I hope this helps!

  • 0 in reply to Joe Prushing
    Prodigy 125 points

    Hi Joe,

    Thank you for your response. I am already quite familiar with the new generation of devices. However, I have just confirmed that these new devices no longer support the grammar type XXX.XXX.XXX for configuring the registers. Is that correct?

    Thanks,

    Eric

  • 0 in reply to Eric Yuan
    TI__Mastermind 25250 points

    Hi Eric,

    While there may be some differences in syntax for bitfield accesses (or register field differences) when switching to a different device, this should not be the case for the specific examples and devices you've mentioned. On the F2838x, F2837x, and F28004x, the syntax to access the GpioCtrlRegs, GpioDataRegs, and EPwm1Regs registers should all be what you have shown. What is the issue you are seeing exactly? Do the registers not update in the Register view after you write to them? 

    Note: The bitfield examples from C2000ware can be used to check the syntax for each peripheral and device. They are in C2000ware path: [C2000ware install]/device_support/[device]/examples/.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 125 points

    Hi Delaney,

    I've been checking the examples in C2000ware's device support and noticed they work well. Is this because I'm required to use the library in device_support, specifically including headers like "#include 'f2838x_device.h'" and "#include 'f2838x_examples.h'"?

    Previously, I was using the headers "#include 'driverlib.h'" and "#include 'device.h'". Could this change be the cause of my compilation failure? The specific error I encountered is "gmake: *** [main.obj] Error 1". But it will be no problem if I use syntax like "GPIO_setPadConfig()".

    Thanks,

    Eric

  • +1 in reply to Eric Yuan
    TI__Mastermind 25250 points

    Hi Eric,

    This is likely the cause of the compilation error. Yes, you would need to include #include 'f2838x_device.h'" and "#include 'f2838x_examples.h'" to use bitfield code. Here is an overview of the includes:

    All of the examples in the device_support folder are bitfield examples whereas the examples in the driverlib folder are driverlib examples. They are functionally the same but use different included files and different syntax. Driverlib projects have built-in functions that can be called by source code which configure the necessary registers, whereas bitfield code has to make register accesses manually (like the code you have in your original post). The older devices (like F28335 and F2812) only have bitfield support whereas the newer devices (like F28388, F28377, and F280049 have both bitfield and driverlib support). 

    Since F2838x is a newer device, you can write programs using driverlib or bitfield code. For driverlib code, you would need to include "driverlib.h" and "device.h" which contain definitions for the driverlib functions. For bitfield code, you would need to include #include "f28x_project.h" which then includes "f2838x_device.h" and "f2838x_examples.h". 

    See the programming guide for more information linked here. Also, when migrating devices it is usually easier to start with the empty_project for that device (from the device_support/[device]/examples/ folder if using bitfield code or from the driverlib/[device]/examples folder if using driverlib code), and copying the code over. This way all of the necessary includes and paths are already set up. Let me know if you have any more questions.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 125 points

    Thanks very much! It helps me a lot!

    Eric

  • 0
    TI__Mastermind 20225 points

    Hi Eric,

    Glad to hear it, I will go ahead and close the thread now. 
    Best Regards,

    Aishwarya