Maybe new rusefi target? TMS570

[AndreyB]

Code Composer Studio, is free to download, and there is no code size limit

Yes and no Looks like CCS is only free as long as you are using it with a dev board. If we want to have the chip right on our board suddenly we are not in the free part of the spectrum. I am basing this on:
http://processors.wiki.ti.com/index.php/Licensing_-_CCS#Free_Licenses
http://processors.wiki.ti.com/index.php/Licensing_-_CCSv6#License_Types

[abecedarian]

Code Composer Studio, is free to download, and there is no code size limit

Yes and no Looks like CCS is only free as long as you are using it with a dev board. If we want to have the chip right on our board suddenly we are not in the free part of the spectrum. I am basing this on:
http://processors.wiki.ti.com/index.php/Licensing_-_CCS#Free_Licenses
http://processors.wiki.ti.com/index.php/Licensing_-_CCSv6#License_Types

Well, yes and no, but mostly yes. CCS free supports XDS100v2 debuggers which are available for purchase, or one could design the programmer / debugger into the target board, or create a separate, stand-alone device. Schematics, Gerbers, et cetera available from download links on that page, but registration is required to access the downloads.

*Edit to add- there are license restrictions involved in designing your own debugger. It might be more apropos to purchase it directly from TI for your own use and provide code updates to users to be installed over USB DFU or similar interface.

[abecedarian]

If anyone other than I are serious about this, I'll buy 2 TMS670LS12x LaunchPad and send one to Sr. russian, and the other to Jared.

[AndreyB]

I'll buy 2 TMS670LS12x LaunchPad and send...

That would not solve any problem

I've got mine TMS570 board on Jul 16, all I've done since is taking it out of the box and placing it back into the box.
@'s effort is totally opaque to me.

Help is needed with laying the groundwork on the software side.
0) what is the name of the default compiler which comes bundles with CCS?
1) what is the licensing situation with said compiler?
2) if it's not free with non-LaunchPad usage, we need to compile existing Hello World application with something free.

I am tied by trying with all kinds of stupid hardware and trying to setup assembly in China. At this point I need to get as many units and as many developers involved as possible. While TMS570 is a MUST in my opinion, it is still a long-term goal - it does not add much of the cool factor into this platform, and right now in my opinion this needs some cool factor to attract more developers.

[abecedarian]

The board I'm speaking of now isn't the same board you opened a few months ago.

The kit you have:

launchpad-hercules1-02.jpg (321.34 KiB) Viewed 22120 times

The kit I'm now looking at:

hercules-tms57ols.jpg (303.51 KiB) Viewed 22120 times

[kb1gtt]

Free hardware, sure send it my way

The unfortunate reality is that I probably won't get to do much with it. So it might be best to hold off on getting me hardware. By the time I can spend time on it, the board will probably have developed into a new platform. As is, I only have someone else's broken Frankenstien 0.1 board, so it would likely be a while before I can get new hardware and new processes setup and operational. Would seem 40hours, kids, and the normal life stuff tend to gobble up my time. I work on things like this 10 minutes at a time.

What would probably help is to write a kind of tutorial on how to compile, and what limitations that compiler environment has. For example, is the compiler free as in beer, or free as in freedom? Can it be use it for hobby, home, commercial, other? Is it windows based, linux, OSx ect. Does it include a compiler for the sub processors? Once we have a compiler environment, we still need to port ChibiOS stuff over to it, and do significant re-writing of the code. Is there a similar OS to ChibiOS for this processor? Does this come with a IDE and ICE, can you stop running code and inspect registers? Right now there are several basic questions about how to use it that are unknown. It's easy for a project to get squashed by feature creep, so the focus has been on smaller steps which directly contribute to a feature. I agree with russian about focusing smaller efforts on direct features, and that long term this processor is likely a good fit. The issue is that it's a significant amount of resources for features we already mostly have. Some day this will probably be bumped up in priority. If that required effort can be deceased, than it will probably be bumped up in priority sooner rather than later.

To help this effort, I think it would help to have something that outlines the basic compile process steps. Perhaps an outline similar to the below would be a handy chunk of the effort.

1: get compiler from here XXXXXXXXXXXXXX
2: Agree to licences which specifies blah blah blah (list basic constraints)
3: Open project
4: enter this code in the main loop XXXXXXXXXXXXXXXXXXXX
5: compile
6: download with XXXXXXXXXXXXXX cable
7: See LED blah blink from MCU
8: See LED blah2 blink from sub MCU
9: Add break point in code and wait for it to stop
10: inspect live registers

[abecedarian]

Free hardware, sure send it my way ...

I know you jest, but I'm serious. PM your address and I'll send you one.


And I know changing hardware spec's in the middle of development is a PITA. BUT...!
You and russian have already developed quite a stash of known, working hardware, and there aren't A LOT of users at this point. Will people be frustrated with a change? Obviously. But would you rather delay the switch to what you and he have already admitted is probably inevitable, or get it done and over with now, before an entire ecosystem has to face a paradigm shift?
Also, the shift from M4F to R4F isn't a deal breaker regarding the code. For the most part, code will translate over well, only requiring changing GPIO and such... oh, and dealing with the N2HET timers the TMS570 provides, which might actually make the code more flexible once the port is complete... but I digress.


TI provides several tools for using the TMS570LS12x LaunchPad. This board's page is here.
The kit comes pre-loaded with code that demonstrates how the processor can detect main oscillator faults, detect memory ECC faults and sample an ambient light sensor. More details about that code can be found here.

The board has convenient mounting holes, access to nearly every pin brought out to holes along two sides of the board and an on-board debugger / emulator interface based around a TM4C129 ARM M4 processor. It allows, from within Code Composer Studio and possibly other IDE's, to single-step through code, inspect and modify variables, and do other debugging related tasks.

The primary IDE is Code Composer Studio, which is available for download at http://www.ti.com/ccs It does require registration at TI's site, and may be subject to export restrictions so may not be available for download everywhere. The license for use is fairly permissive, however any libraries used within projects may have their own restrictions regarding distribution, but that can typically be avoided by distributing "shell" code and linking the user to the download site for the library.

TI has a CMSIS DSP library for their R4 processors here. Not sure exactly how that could be leveraged for an ECU, but who knows?

Other tools TI provides for free include tools for ECC, PLL, HAL and HET configuration, diagnostics libraries and a stand-alone FLASH tool to provide for updating firmware and such. More information about these can be found either on, of by way of hyperlinks contained on the product's page linked in the first line of this post.

TI also has an excellent support community with forums where people can posit questions regarding anything related to anything TI: hardware, software and such. Registration required to post (same registration credentials as used to download CCS and other tools), but no registration required to read: http://e2e.ti.com

Regarding RTOS, I don't know if a port of ChibiOS has been made to the TMS570; their site doesn't list it. However, as the R4 is based on M4, porting it over should be possible, but it would require additional work to implement the RTOS friendly features R4 provides. TI does provide TI-RTOS, and there is a port of FreeRTOS IIRC. Micrium's uOS is available for the TMS570, as are other non-free RTOS.

And to wrap things up....
I'm working on developing little boards compatible with TI's "BoosterPack" setup, which would allow, among other things, CAN interface, VR sensor interface, MAP and Baro sensor, low-impedance injector drivers (a pet peeve of mine ) and such... even contemplating putting an MC33814 on one to drive two injectors, ignition and O2 amongst other things. The goal being to, as Jared once envisioned and I supported, a configurable, stackable ECU. These new TI boards enable that and more, in a relatively inexpensive yet quite high-performing package.

[AndreyB]

And to wrap things up....
I'm working on developing little boards compatible with TI's "BoosterPack" setup, which would allow, among other things, CAN interface, VR sensor interface, MAP and Baro sensor, low-impedance injector drivers (a pet peeve of mine ) and such... even contemplating putting an MC33814 on one to drive two injectors, ignition and O2 amongst other things. The goal being to, as Jared once envisioned and I supported, a configurable, stackable ECU. These new TI boards enable that and more, in a relatively inexpensive yet quite high-performing package.

Does not free version Eagle have some limitations on board size or complexity? What is your plan once all your modules are proven and tested? How would you merge them into one integrated board, if you plan that?

On the other hand, if you migrate to KiCad, you can re-use existing rusEfi by DAECU modules and reuse Frankenso board if you match discovery footprint

[abecedarian]

Yeah, Eagle free has board limitations: 1 sheet, 2 layers and 100x80mm layout area. I'm looking at going 'up' to the "hobbyist" which has 99 sheets, 6 layers and 160x100 board area.
Either one fulfills the idea of having "BoosterPack" sized things, as those are typically 50x50mm. Since they would be of relatively limited functionality, multiple layers shouldn't be a concern either.
Matter of fact... I've actually laid out an entire ECU for my motorcycle based on using the MC33814 chip from FreeScale using only 2 layers and within the 100x80mm limits, with about 1/3 of the area unused.

If things progress as I hope, I don't immediately foresee the board size limit as an issue, but even then, Eagle drawings can be brought into KiCad with few issues.

If KiCad had the "integration" between functions Eagle has, I'd switch in a heartbeat.

[kb1gtt]

I don't follow the integration between functions thing. I know KICAD can do things like select a pin in the schematic and it will highlight the net and put the curse over the pin in the PCB, ect. The beta (or what ever they call it) has some really sweet things like pushing other traces as you route a new trace, and very realistic 3D. However that's typically compile from source kind of stuff and isn't available on Windows yet.

Can you post your gerbers? If so I can likely back port to a functional KICAD layout and schematic. I don't know any other platform where that is an option. It's mostly not an option in KICAD because you have access to name nets manually. It's typically not an option in other packages because they don't compress or encrypt the back end data.

About an OS port, right now russian is relying heavily on the OS to deal with most of the portability and low level issues. The OS is providing pretty much all the low level interfacing with things like timers, and misc ADC registers and such. These drivers are a huge part of what ChibiOS is offering. Perhaps a list could be made of the OS specific function calls (or drivers or what ever) then compare them against another OS to see what might already exist. How similar are freeRTOS and ChibiOS? I believe many function calls are the same, so many drivers might already exist. I don't think the extent of the re-writing is known at this point.

How hard would it be to attached with a bunch of jumper wires this board to the Frankenso board? I could probably change the brain board area to include a different pinout that would accommodate this board. This might allow a fast track option for getting some functional hardware out there that uses this board as the brain. However I'm also reasonably ignorant about this board, so I might be oversimplifying it in my head. But I think it would be possible. If that happened how likely would it be to get the software functional?

[abecedarian]

Kicad has several programs, and getting from one to the next is required for development but they are all separate, as in not really well put together.
If the folks at cern can fix it, you have a convert.

[abecedarian]

... About an OS port, right now russian is relying heavily on the OS to deal with most of the portability and low level issues. The OS is providing pretty much all the low level interfacing with things like timers, and misc ADC registers and such. These drivers are a huge part of what ChibiOS is offering. Perhaps a list could be made of the OS specific function calls (or drivers or what ever) then compare them against another OS to see what might already exist. How similar are freeRTOS and ChibiOS? I believe many function calls are the same, so many drivers might already exist. I don't think the extent of the re-writing is known at this point.

please forgive me as I'm typing with my tablet.

I can't comment regarding how similar rtos are. The tms570 does provide a tick for scheduling tasks; as mentioned TI does have an rtos of their own.
Access to hardware peripherals isn't much different whether rtos or not. Can't get much more real time than not using rtos, actually.

How hard would it be to attached with a bunch of jumper wires this board to the Frankenso board? I could probably change the brain board area to include a different pinout that would accommodate this board. This might allow a fast track option for getting some functional hardware out there that uses this board as the brain. However I'm also reasonably ignorant about this board, so I might be oversimplifying it in my head. But I think it would be possible. If that happened how likely would it be to get the software functional?

Likely not too hard but it would be a rat's nest since pins aren't in the same location.

On the up side, since most pins are GPIO capable, it would be relatively easy to start there, ADC being a big hang up though, then incorporate the hardware peripherals later, provided the board signals are routed accordingly, taking that into consideration.

Hopefully my home pc will be online quickly and I'll try to map the discovery board pins to this.

[kb1gtt]

Do they post a gerber of the PCB some where? Or schematic? I see some nasty notes about how this eval board is not for products. As far as I can tell that's mostly just CMA. I think they do it that way as they don't want to be liable if they make a change to the PCB, don't want FCC issues and they don't want you to buy up all their stock on the PCB's. However we would need to have at least a plan for how to remove the eval board from the stack. I see the core chip is between $26 and $19, while the eval board is $20.

http://octopart.com/partsearch#!?q=TMS5701224BPGEQQ1

I wonder what those other chips are, and how much they cost. I suspect the board could be built ourselves for around $30 to $40. Which is not a bad price for an automotive grade, multi core platform.

How far along are you with your board designs? Are you thinking you might be close to doing a spin of the hardware? The eval board price is a minor point for me. In terms of hardware, the boards to connect it to my snow blower or something are the big hold up for me. I have 4 potential projects. A snow blower, a Jawa 72ish motorcycle, a 95 YJ 4 cyl jeep, and a little red suby. I would need to be able to connect that board to at least one of these potential platforms. AKA up to 4 cyl, high Z, Hall crank, and the typical sensors.

Does eagle have footprint builders and symbol builders? KICAD has a couple including these. They allow me to copy and paste the pin outs from the datasheet to make a module that I don't have. Making a module for the TMS chip would be around 15 mins perhaps as much as 30 mins if I double check lots of things.

http://kicad.rohrbacher.net/quickmod.php
http://kicad.rohrbacher.net/quicklib.php

Perhaps you mean the entire thing were KICAD has relied on flexibility before efficiency tools. For example, When I make a change in the schematic, I have to hit the netlist tool instead of it being automatically linked. Doing it that way allows flexibility. Often you can have one schematic / netlist with multiple layouts (say thru hole vs SMT). Both have similar netlists, but different modules. KICAD has allowed for that option, which can slow down more common layouts with one set of modules. The issue is that they haven't yet developed a check box for automatic netlist linking. I call these kinds of things efficiency tools, which KICAD has put on a lower tier then flexibility. I agree that KICAD is missing some efficiency tools, which I think is what you are talking about.

Also might be worth noting, I only use the schematic capture and PCB layout. That CMP footprint thing does not need to be used. As well they include some calculators for figuring out striplines and such, which does not need to be used. Also the Gerber viewer is separate, but last I checked that's pretty much standard, or non existing in other package. The "advanced format" has allowed things to be more typical of these EDA tools. The CMP program was that flexibility thing. but does not need to be used. Perhaps you looked at this before the "advanced format" was in the stable build. In today's stable build, once you learn the keyboard short cuts and if you use the advanced format, I don't think the efficiency tools are much of an issue any more. There is still room for growth, but it's becoming less of an issue.

[abecedarian]

Sorry, am battling hard drive problems. Will reply soon.

[abecedarian]

Okay, computer's back online. Issues were related to HDD read errors which somehow resulted in making the computer unable to boot reliably. Now have nearly 4TB of storage.


I agree the lack of FCC approval and other blurbs are typical cover-their-ass things.

Anyhow, I haven't come across schematics / layout files for the new TMS570 board. Other chips on the board are a TM4C129 (ARM M4F) used to provide USB PHY and emulation / debugging / programming (XDS110 class) for the TMS570 chip, and some miscellaneous voltage regulators to provide 3v3 for the TM4C and TMS570 and 1.2v for the TMS570. Firmware for this hasn't been released, as far as I can tell, so even if we had schematics, duplicating this board with our own layout would be a fruitless endeavor.

The TMS570LS1224 are expensive, and TI doesn't currently offer samples of this, but they do have TMS570LS1227 which is mostly identical save for offering an Ethernet MAC and FlexRay at the expense of six GPIO. I haven't done a side-by-side comparison of the pin functions to verify this, but it's likely something designed against the 1227 would accept the 1224 without modification if those functions weren't implemented.

To explain a little more about the TMS570LS1224 chip:
- They are dual-core ARM R4F, intended to target real-time, safety oriented products, with the TMS570 targeting automotive use; they have gone through several processes to achieve certification for use in such products. Though they are dual-core, they are not multi-thread capable. Both cores run the same code and a compare unit checks the outputs from both cores to verify they produce the same results:

Code: Select all

       /-- CORE 1 -> two cycle delay --\                             /-- core outputs match, proceed as normal
CODE- <                                 >--- core compare module ---<
       \-- two cycle delay -> CORE 2 --/                             \-- core outputs do not match, throw an error, maybe re-execute the code in question

- single bit error correction and two-bit error detection is available for RAM and FLASH access / transfers.
- self-test functionality available for all peripherals and crystal / oscillator fault detection is possible.
- N2HET module is an embedded microcontroller. Each N2HET module (2 on the TMS570LS1224), once programmed by the main core, operates independently of the main core. N2HET is capable of responding to and generating events on its associated pins, and transfer information to and from the main processor through registers and memory. It uses a "very long instruction word" architecture where each instruction it executes contains the instruction and any data the instruction needs. It is analogous to the eTPU peripheral as seen on many Freescale and STM processors. Additionally, the N2HET module has a 'hardware angle generator' which utilizes its timers in such a way that it can interpolate rotational position from toothed wheels, including simple, "missing tooth" type such as 60-2, 36-1, et cetera; it cannot easily work with more complex wheels having multiple, non-adjacent, missing tooth configurations. That's not to say it can't be done, but it would be difficult to accomplish without main processor intervention.
- ADC are 12 bit and 5v compatible, i.e.: -0.3v < ADCREF(-) < ADC_VALUE < ADCREF(+) < 5.5V. Any ADC input below ADCREF(-) -0.3v will generate 0h00 (0 decimal) as a result; any input above ADCREF(+) will generate 0h3FF (4095 decimal).

I have noticed that with the issues affecting my computer, some of the files were lost in the recovery process.

My thoughts and designs were oriented based on my requirements- two cylinders and such; shouldn't be too hard to adapt to at least 4 cylinders. But, the designs used an MC33814 to interface to injectors, ignition and Lambda sensor heater amongst other things. That chip is pretty much dedicated to two cylinder operation only with little hope of going beyond that. Maybe MCZ33810 to run 4 cylinders; O2 via external WBO2 UEGO module.

I'm open to suggestions.

First board spin will be a Frankenboarder of sorts, maybe something to allow plug-in modules for things and the LP on top. We'll see, I guess.

[abecedarian]

Okay... found schematic (PDF), Eagle schematic / layout, Gerbers, BOM and a little more info here. Schematics reference RM46 chip but that chip is pin-compatible with TMS570LS1224 and both LP's use the same board. Links to download Code Composer Studio and HalCoGen on that page as well.

[kb1gtt]

The layout looks reasonably straight forward. I see 5V, 3V3 and 1V2 voltage regulators.

[abecedarian]

5v supplies the 3v3 and 1v2 systems.
3v3 is for the TM4C as well as the TMS570's GIO; 1v2 is for the TMS570's internal, core logic.

actually quite straight forward. the 570 doesn't have anything resembling tight power up timing, i.e. IO can come up before core and vice-versa. Proper "standards" compliance would probably require more strict power up and monitoring than that board provides.

[abecedarian]

Tools, software, BSDL models and more for the TMS570LS1224 chip available here and on linked pages from there.
I.e. links to Code Composer Studio and other development tools including the NHET assembler, and debugger probes amongst other things.

[AndreyB]

If anyone other than I are serious about this, I'll buy 2 TMS670LS12x LaunchPad and send one to Sr. russian, and the other to Jared.

Is this still on the table? I'll take a LAUNCHXL2-TMS57012 and make a meaningful attempt to get it up & running I would even take two of these just in case I burn one

[abecedarian]

If anyone other than I are serious about this, I'll buy 2 TMS670LS12x LaunchPad and send one to Sr. russian, and the other to Jared.

Is this still on the table? I'll take a LAUNCHXL2-TMS57012 and make a meaningful attempt to get it up & running I would even take two of these just in case I burn one

After you said:

I'll buy 2 TMS670LS12x LaunchPad and send...

That would not solve any problem

I let the idea go so don't have it budgeted at the moment. I'll see what I can come up with though.

[abecedarian]

N2HET register list: http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/312/5483.NHET_5F00_REG_5F00_HWAG_5F00_DRAFTONLY.pdf
Rough graphical example of N2HET operation for angle determination: http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/312/1856.N2HET_5F00_Images.pdf

Still looking for sample code....

[abecedarian]

If anyone other than I are serious about this, I'll buy 2 TMS670LS12x LaunchPad and send one to Sr. russian, and the other to Jared.

Is this still on the table? I'll take a LAUNCHXL2-TMS57012 and make a meaningful attempt to get it up & running I would even take two of these just in case I burn one

After you said:

I'll buy 2 TMS670LS12x LaunchPad and send...

That would not solve any problem

I let the idea go so don't have it budgeted at the moment. I'll see what I can come up with though.

Okay, I have the "sister" board of the TMS570LS12xx, RM46x. The TI page for it is here. It uses RM46L852 MCU instead of the TMS570LS1224. The main differences are the RM46L852 MCU supports Ethernet and USB, is not automotive rated, is rated -40 to 105C, and runs 220MHz in 144LQFP package compared to 160MHz for the LS1224 in 144LQFP; the lower temp rating is probably due to the extended operating frequency. I scanned over the two processors' datasheets and as far as I can tell they are pin compatible, at least with default pin mapping; the RM's USB and Ethernet are multiplexed on top of other pins. Both boards are identical, according to TI, so given the RM46L852 is a superset of the TMS570LS1224, if the RM is programmed as if it were the TMS, the code should port without problems.

If you're willing to accept that, PM your address and I'll do what I can to get it over to you. Otherwise, I can't get anything to you for a few weeks, at the earliest.


If you're serious about this, I'd like to suggest a sub-forum for these where things could be discussed and agreed upon before spinning any hardware, with other sections added as necessary. I.e. start with a "request for comments" regarding what engine configurations, sensors, and such should be accommodated for in the first revision, possibly with a slant towards full custom, not trying to interface with factory systems. Then develop against that simple baseline configuration and get some engines running. Once there are a few engines running "full-custom", start working back towards OEM harness and sensor compatibilities... but if the initial design is well designed, it should flexible enough to accommodate other configurations and shouldn't be too difficult, no?

Just a thought.



I should add that you could start working with the LS0432 board, wiring up modules to it, so as to get coding started, and then migrate that to the other when that hardware is available to you. 0432 ADC is not 5v compatible so that needs to be considered. N2HET code should be similar between them, with the exception of actual pin / channel assignments and I think the 1224 has a larger code size for N2HET programs. Mapping MCU core functions using the pre-defined preprocessor macros would probably simplify things.

[a-seely]

Hi, full disclosure - I'm a TI employee working on Hercules.

Is this still on the table? I'll take a LAUNCHXL2-TMS57012 and make a meaningful attempt to get it up & running I would even take two of these just in case I burn one

Obviously can't make this a standing offer everyone who reads this (I'd go broke if I wind up paying out of pocket but for 2 boards you can send me a direct mail w. your address etc.
http://e2e.ti.com/members/33558 should link to my E2E profile and I think there's a button their to email. If you don't see it I think if you 'friend request' then you can send a private message.

You probably are better off with the TMS570LS1224. Much bigger memory and higher frequency than the LS0432. The CPU on the 1224 also has an FPU. And there are 2x N2HETs and 2x MibADCs
as well as the other points about the ADC being 5V capable on the LS1224 (correct).

I am really behind on getting the HWAG documentation out for the N2HET. Kind of inherited this from someone who left and I'd love to get a real world example of this in operation.
So especially interested if you are going to play with that module. It allows you to count based on the crank angle (instead of time) and you can fire off a pulse starting at an angle value and
lasting for a duration measured in time. Between teeth, the angle is updated based on a simple (linear) estimate that uses the time between the last two teeth to count off estimated ticks until the
next tooth ... and then the angle counter re-syncs again when an actual tooth edge is detected. I have no idea how well this would work in the real world but really interested in finding out.

Regarding the RM46L852 versus TMS570LS1224 - for the launchpads they are the same pretty much except for operating condition specs, frequency (the industrial part is rated at a higher freq. than the automotive grade) and then the biggest difference is that the TMS570 is big-endian as it's a upgrade from the legacy TMS470 (ARM7 big endian parts). Since most of the ARM community is now using little endian, the RM46 is made little endian. This is mainly important if you are using a toolchain like GCC as I think the libraries are better supported in little endian.

The XDS110 firmware source code isn't given out but the binary is available in the CCS download. It is in the C:\ti\ccsv6\ccs_base\common\uscif\xds110 folder. There's a utility there called xdsdfu that allows you to program it into a blank TM4C part over USB. If you wanted to copy this design from the launchpad you'd need to know that RBIAS is actually required for USB DFU programming even if ethernet isn't used. (our first batch of launchpads doesn't have it, and it's a bit of a problem to program them). So add a 4.7K resistor from RBIAS to GND. And there are some other errors in the schematic related to measuring the voltages on the board. I won't get into them yet as there isn't support yet for power measurement. Anyway you might just want to stick with the XDS100v2 for now, it works just as well w. Hercules and it's design is available on the TI embedded processor wiki. http://processors.wiki.ti.com/index.php/XDS100

[kb1gtt]

Hello a-seely and thank you for the info.

About FPU, what are the compiler options? Do we need to use pre-made binaries or is there an option to compile our own FPU code? We are hoping for very low cost compiler AKA free is good

I'm more of a hardware guy, russian is the primary software guy. Last I knew russian was struggling with a hello world application. Are there any examples or similar that will help get a hello world setup working?

[a-seely]

Hi kb1gtt,

I'm more of a hardware guy

me too

About FPU, what are the compiler options? Do we need to use pre-made binaries or is there an option to compile our own FPU code? We are hoping for very low cost compiler AKA free is good

If you are mainly concerned about free as in 'free beer' then Code Composer Studio from TI is subsidized - it's free in an edition that is limited to use with XDS100 class emulators, so the XDS100v2 and XDS110 count in that category. And this is true regardless of whether you are using an XDS100 class emulator to connect to your own board or one of TI's eval kits.

Code Composer Studio works inside Eclipse, which is an open source IDE. The reason I say this is that inside Eclipse there are plugins for development in all sorts of environments, and Code Composer Studio is just one of these. If you start a new project in Eclipse then you get options like C/C++ Project, or Code Composer Studio CCS Project. If you pick C/C++ by mistake then it's really a project for the host (PC) that you'll be creating, and this could be one source of trouble.

Instead if you make sure to select a new "CCS Project" then our TI project wizard shows up and you can select the part # from the list or start typing the first few characters "TMS570LS12.." and the list gets filtered down. I'd strongly recommend starting out this way because if you do, then you'll already be setup for building with the FPU enabled if picking the TMS570LS1224. For the TMS570LS0432 with no FPU it's the opposite.
Once you've created the project, you can always look at the project properties and there is a tab for "ARM Compiler/Project Options' with the FPU settings. The command line option (if you need to build outside the IDE is listed there too, it's --float_support = {VFPv3D16, vfplib, ..} The LS1227 has VFPv3D16 which means it's version 3 of the VFP spec, and it comes with an additional 16 double precision or 32 single precision registers. Vector is a bit of a misnomer as it only operates in scalar mode. But the CPU can issue float and integer instructions in parallel which helps with performance too.

Whether you're working with the TMS570LS0432 (no FPU) or the TMS570LS1224 (VFPv3D16) you can still use the "C" data types float and double in your code. It's just that in the case of the 0432 this code will be translated to function calls to a floating point emulation library -- which takes much longer to execute than a native FPU instruction.

Last point I should mention is that there is a version of the CMSIS DSPLIB ported to Cortex R4F available here: http://www.ti.com/tool/hercules-dsplib and while you don't need to use this library, you might find that functions in the library are highly optimized / execute faster than generic C code.

Are there any examples or similar that will help get a hello world setup working?

One problem specific to the TMS570 / RM4x series of products that might be getting in the way is that the lockstep CPUs need to be carefully synchronized coming out of reset. Not all of the registers in the CPUs are cleared by a hardware reset, so they all need to be initialized first before really doing anything else. This includes some internal / invisible registers in the branch predictor.

The startup sequence is a no-brainer if you build a project using HalCoGen to initialize the part and get you to main(); From there you should be able to insert a 'printf("Hello World");' and it should just work by default; CCS implements 'semihosting' by putting breakpoints on stub CIO symbols. The CPU gets halted, and the strings from printf are fetched by CCS and output into the console window. You can also operate on files on your development system this way. It isn't really good for your long term goals as it stops the processor when you do it this way, but for hello world it's fine.

On the other hand, if you just startup CCS, and create a new CCS project with 'empty' or 'empty with main.c' type, and don't use the code generated by halcogen, then while the compiler options will be setup correctly, you'll link in the very generic ARM startup code that comes w. the TI ARM compiler. This normally would be capable of working on other targets, but because of the CPU initialization that is required, it doesn't work on the TMS570. You'll get trapped pretty quickly with a core compare error this way and never get past the first few instructions.

I wrote up a Wiki page for "Project 0" (which isn't "Hello World" but rather is a 'blinky'). It is specific to the TMS570LS1224 and RM46L852 launchpads. Those wiki pages are http://processors.wiki.ti.com/index.php/LAUNCHXL2-RM46 and http://processors.wiki.ti.com/index.php/LAUNCHXL2_TMS57012:_Project_0. The real point wasn't to blink the LED but instead to go through all the steps of installing CCS, HalCoGen, setting up the project, generating the HalCoGen startup code, etc. So I'd suggest starting there and if there's anything confusing just feel free to complain loudly (best to do this on the TI E2E forum for Hercules) and we'll clarify / fix as needed.

Going back to the 'free as in beer' - if you need the other type of free environment there are GCC based IDEs and toolchains available too. HalCoGen outputs code for several different toolchains (it's mainly the assembly syntax that is different, and while most of the code is "C" some of the startup code is assembly). And the HalCoGen output files themselves are available under a BSD license so should be no issue using them in an open source project. I'm not that familiar w. GCC based projects though but if that's what you really need I can try to get you in touch w. the right people.


Best Regards,
Anthony

[AndreyB]

Hi, full disclosure - I'm a TI employee working on Hercules.

Hi! Thank you for stopping by! We are just hobbyists here and it's really nice of you to offer your help!

I am Andrey and I am a software developer. Bach in high school I was programming x86 with assembler and my day job is high-performance java. The _only_ MCU I am currently relatively comfortable with is stm32, I guess that would explain half of my silly questions

Q#1: what is XDS100? I know it's something about debugging. Is it a software protocol? Is it a hardware chip implementing some protocol? I see 'XDS100 emulation' all over the place. Why emulation - what is emulating what?

Q#2: what is the role of TM4C129 on LAUNCHXL2-TMS57012?

I am planning to use the answers to fill in the gaps in http://rusefi.com/wiki/index.php?title=Hardware:TMS570_Hello_World document which hopefully would become an introduction to tms570 for java developers

With stm32f407 chip, rusEfi has started with Frankenstein board which is an I/O board for stm32f4discovery board, and then we have moved forward to Frankenso where one has an option to solder an stm32f407 chip directly on the Frankenso board ('native' stm32f407 options). I would guess we are looking to do the same with tms570.
Q#3: do I understand it right that with a tms570 chip soldered to our board, there are NO free licenses for CSS and TI compiler? If that's the case that's why I want to address this right from the beginning - I guess right after we have some HelloWorld for CSS we would need a CSS for a free toolchain.

As for complaining loudly, that's the only thing I am good at - that's just my personality.

C#1: if LAUNCHXL-TMS57004 is ACTIVE, where is a Hello World tutorial for a current version of CCS? (not that we need one - but just as an initial complaint). See also http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/395610

C#2: HALCoGen bug with enlarged Windows fonts would kills me personally. I am writing this from a 1440x900 laptop with 150% font sizes, at home I have a 22" desktop monitor where I use 125%. See also http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/398054

[kb1gtt]

Removed by kb1gtt, russian is checking the forum while on vacation. I'll let russian field the questions, he's better suited to ask and answer these questions.

[AndreyB]

rWould I be correct in considering the FPU to have low latency access to things like IRQ's and such timing critical items?

Nope. FPU is just Floating Point Unit - it's a math co-processor, nothing else. Not the low-latency co-processor as in PowerPC.

[abecedarian]

Q#1: what is XDS100? I know it's something about debugging. Is it a software protocol? Is it a hardware chip implementing some protocol? I see 'XDS100 emulation' all over the place. Why emulation - what is emulating what?

XDS100 are JTAG emulators. See XDS100 emulator wiki on TI.com In particular, we would be interested in the XDS100v2

Q#2: what is the role of TM4C129 on LAUNCHXL2-TMS57012?

On the previous 0432 LP, an FTDI chip provided the USB / serial interface and a CPLD was the XDS100 emulator.
The TM4C129 is the processor doing the XDS110 JTAG emulation on the 1224 LaunchPad; USB chip not required since TM4C129 has USB PHY.

Q#3: do I understand it right that with a tms570 chip soldered to our board, there are NO free licenses for CSS and TI compiler? If that's the case that's why I want to address this right from the beginning - I guess right after we have some HelloWorld for CSS we would need a CSS for a free toolchain.

As Mr. Seely mentioned:
"If you are mainly concerned about free as in 'free beer' then Code Composer Studio from TI is subsidized - it's free in an edition that is limited to use with XDS100 class emulators, so the XDS100v2 and XDS110 count in that category. And this is true regardless of whether you are using an XDS100 class emulator to connect to your own board or one of TI's eval kits. "

From Licensing - CCSv6
"Free License (Free Limited License): This is the license CCSv6 automatically starts using upon installation. CCS can be used for free with many of our community boards, LaunchPads, DSKs and EVMs (Evaluation Module) kits. You can download CCS and then select to use the free license for use with development boards. This CCS will only work with the onboard emulation on the board, XDS100 debug probes as well as the XDS560v2 mezzanine card available in C6000 multi-core EVM bundles. You may use this version to create production code.... "