Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by TI_Trey

  1. Sam, There is a single pin that 5V may be applied to and that is J5.1. Applying 5V to any other pin may potentially damage your LaunchPad. A CR2032 may power a MSP430 for years but it would only power a Piccolo for a little while. It should work though... How did you have it connected? Trey
  2. Tim, Currently there is no driver library for the 06x devices, but the 02x library should work. Almost all of the peripherals are the same, but some have additional functionality. Driver libraries for the other devices are in the works, but there is no schedule for when these will be released.
  3. Nice to meet you Mihir! Happy Hacking!
  4. TI_Trey

    Program size

    No I don't believe there is a way to do that. Information like this on the compiler and linker can be found in the Assembly Language Tools User's Guide (SPRU513). Trey
  5. TI_Trey

    Program size

    Check out your map file. The map file basically shows how each part of your program was allocated to the available memory. This makes it easy to tell which parts of memory you are filling up and which parts you have more space. Opening the map file can easily be done by looking in the build folder. Typically in CCS these are named "Debug" or "Release" by default, but in the LaunchPad projects these are named "RAM" and "Flash". Look for the file with the "map" extension and open it. Let me know if you need help interpreting it.
  6. I agree that we could be more hobbyist friendly by being supported in tools like Energia, but I respectfully disagree on a few of your points. We are working on cross platform support for our compilers. We already have Windows and Linux support, so all we are missing is OSX support. C code that is compiled with a GCC compiler can easily be recompiled with a TI compiler. C is C. The only thing that changes between compilers are thinks like compiler pragmas. These are typically very easy to swap over between compilers. The one point I will concede here is that our memory width is 16 bits w
  7. Currently the C2000 compiler is available for download for free here: https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm We've looked at the exact approach you suggested, and I agree that is the best path moving forward. The issue becomes that we are missing several other things we would need for cross platform support...mainly a flash programming tool. For now I've shelved Energia support for the C2000 LaunchPad, but I'm not completely writing it off. I'm planning to revisit the idea as more of the pieces of the puzzle become available.
  8. Zborgerd, Appreciate your kind words...lots of work has gone into the C2000 LaunchPad and I've got even more cool stuff in the works! I am definitely pushing for improved open source support for the entire C2000 family of devices, but a full blown GCC compiler is still not planned. I completely agree that we need improved cross platform support for all aspects of the development tool chain (IDE, Compiler, Debug tools). This is something our teams are working toward and we hope to see the whole tool chain running on OSX in the future. I understand that GCC has a cult like followin
  9. No, nothing yet. The teams that develop CCS and our compiler know that everyone wants OSX support, but they have a lot on their plate right now. As soon as I hear anything more, you'll be the first to know.
  10. w00t w00t! If you have any questions on USB on the F2806x...send them my way! I was responsible for porting the USB stack and examples to the 28x architecture. FYI, the USB controller is VERY similar to the Stellaris USB controller.
  11. Jesada, Glad to have you on board! Check out the new boosterpack design contest: www.ti.com/byob
  12. Pheo, Your edit is 100% correct. I actually reviewed this boosterpack prior to manufacturing to make sure it would work with the C2000 LaunchPad.
  13. Cristiano, Absolutely yes! In the C2000_LaunchPad out of box demo application I associate STDOUT to SCIA to allow for easy transmission of characters, but you could also associated STDIN. I don't have the exact code for how to do this, but the CIO functions are discussed in detail in the compiler users guide (search for spru514 on the TI website). You'll find the information in section 8.3 "The C/IO Functions". There is also information on how to add other low level device drivers. Regards, Trey
  14. Yep...datasheets and reference manuals are all we have right now. Sorry
  15. Hi Skinny, Sorry for your troubles, these examples and the driver they use are relatively new and I've had very little help testing and making sure everything works. I sincerely apologize for any bugs you may find, and I'm happy to work with you to fix them. On to your problem: There are a few minor issues that need fixed before the example will work. I'll file a bug for these and get this fixed in the next release. Warnings: SCI_read and SCI_write are functions defined in sci_io.c. These were added to allow me to register the SCI as a STDOUT stream. This allows us to use the printf f
  16. Certainly that is the hope, but I have no guarantees on when this might be done. Hopefully I'll get some free time to nerd out during the holidays...
  17. Well, we don't actually have FatFS running on this yet. I've been meaning to do the port, but just haven't had the time.
  18. MK, Let me talk to our fulfillment people. I think we can probably make a trade. I'll get back to you.
  19. Mikhail, I'm wondering if maybe something got zapped by ESD. Have you tried using this board on another computer? That may be a good test to determine whether something is wrong in hardware or on the host PC.
  20. They are to allow muxing of those GPIOs. Basically on two of the physical pins on the right side of the board there are two GPIOs connected to each. This was done so that we could stay compatible with the BoosterPack standard. You are correct that you can cut the trace inbetween the pads to disconnect one of the GPIOs, and a zero ohm jumper could be placed on top to reconnect. For most users this will never be needed though because by default all the pins are Hi-Z inputs. As long as you only configure one GPIO per each of those pins you'll be fine without any board rework.
  21. Sch, Thanks for the heads up. I think I've already fixed the first two in our internal version control system, but not the third. I'll go ahead and file bugs for these to make sure I double check them.
  22. Pjkim, You're absolutely right. I certainly could have worded that better. Thanks for better explaining that!
  23. MK, That's odd. There are a couple things to check. Make sure the right most boot switch is in the UP position (toward the emulator). Make sure the target is powered (using the jumpers JP1 and JP2 or externally through the headers). One question, you have been able to successfully connect and program the board previously, correct?
  24. Abhed, I saw your email and I have every intention of taking a look at this, but I am swamped right now. I'll try to get to this sometime this week. Trey
  25. Cool! I kinda wished we had used a part like the F28069. Maybe in the future we'll do another LaunchPad.
  • Create New...