• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 1104 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.

Transition from HV eval kit to product

Bill McConnell
Intellectual 960 points

Other Parts Discussed in Thread: TMDSHVMTRINSPIN

The eval kits and lab code are great for early design. Since transition to a product is a step that is desired by TI and its customers, a few hints might help. Here are a couple questions and hints in a transition from the high voltage kit TMDSHVMTRINSPIN.

1. Designing product hardware:

A. Downsize cost of micro. In our case, the 28069M is desired and only a dollar or so may be saved with the 80 pin version. However, comments on this process are invited as they may help others (or our low cost product). It looks like heavy hardware mods are needed to test some of the lower performance options.

B. Remove the USB emulator. The XDS100v2 has been great. To connect to the product, it looks like we may need a JTAG pattern, a cable emulator and isolated USB? There are choices on the JTAG pinout, but as far as I can tell, the simple one on the eval kit looks like it would work for an external XDS100v2 emulator, or not?

C. Redesign the balance of the hardware (no specific questions, but open for comments).

2. Making production software (other than the obvious):

A. Chris Clearman and Adam Reynolds pointed out that there are gMotorVars calls in the lab code that eat bandwidth and add to the learning project, but not to the product performance. References:

e2e.ti.com/.../489015

e2e.ti.com/.../1302921

B. Is there a list of “unnecessary” gMotorVars? I realize they vary by lab, perhaps there is a way other than searching on each name to determine usefulness, or other hints in this regard.

C. Any other comments, or examples, on streamlining or otherwise tailoring lab code to product code?

  • 0
    TI__Guru** 119680 points
    1a. You need to decide if you need InstaSPIN-MOTION or just InstaSPIN-FOC. The other variants are CLA or not (69 vs. 68) and just Flash memory sizes (69/68 vs 62; 54 vs 52; 27 vs 26)
    1b. Yes, most end products don't have an emulator on-board, but most do bring out the JTAG pins to a header so they can use an external emulator.

    2a/b. For this one I think you need to think about the gMotorVars as a way to change or monitor critical variables during development. There are also some variables that aren't in the gMotorVars structure (which you learn about in the labs) that may be interesting to monitor. What you need to decide as you move to a software product is
    1. which variables need to be hard-coded or set upon boot or some other event
    2. which variables need to be changed by a user through GPIO (button, pulse train) or ADC (ex: potentiometer)
    3. which variables need to be changed by a host through a serial port (UART, SPI, CAN, I2C)
    4. which variables need to be logged or communicated back to a host
    5. which variables are extraneous for an end product

    and that will make your decision about how to modify the software.


    I was hoping you might get more discussion on this topic, but unfortunately this forum tends to be more customer support than community!
  • 0 in reply to ChrisClearman
    Intellectual 960 points

    Here's another question: The eval kit has a PWM Overlap Protection Circuit. Seems like a feature that would already be in the 28069, maybe this is there for other processors, or? Is it needed for the product?

  • 0 in reply to Bill McConnell
    TI__Guru** 119680 points
    this is additional circuitry to protect hardware in case of the CPU hanging, which would be a potential during development. most people don't include in actual end products...but on higher cost drives they might