Maybe new rusefi target? TMS570

[abecedarian]

Wow, I forgot about this thread.

It's a nice board but i haven't really played with it yet.

Please do post your impressions of it.

[Nobody]

Unless I'm mistaken, they still have not published an application note or example for angle based control. It looks like a nice board, especially for price point. The 20 bit timer resolution is nice and can be cascaded.

[AndreyB]

Status update: this platform seems to be best suited for our purposes considering the freeware tool-chain requirement. I've got scared by TI HAL wizard, any takes to find or write an article on "writing a HelloWorld application with Rtos and TI HAL"?

That would be https://sourceforge.net/p/rusefi/tickets/82/

[abecedarian]

It provides most, if not all the functions some of the Freescale and ST processors provide. And the cost of the LP board ($20 USD) and software tools (free) is hard to beat.

RE: documentation and such mentioned previously.
TI's E2E forums are great resources where TI employees and engineers are often the source of solutions.
http://e2e.ti.com/search/default.aspx#q=Hercules
Register and ask away.

I might suggest foregoing the RTOS approach and work with state machine type thinking.


Looking forward to what happens next.

[kb1gtt]

I haven't heard much about this lately, how goes the battle? Any chance of an update on your progress?

[abecedarian]

I haven't heard much about this lately, how goes the battle? Any chance of an update on your progress?

My progress? Not much, actually. The thing started out with good intent, I suppose, but now it is being oriented more at one processor facilitating the timing critical things like decoding the crank and cam signals and firing injectors and ignition, with another providing oversight / supervisory functions and also running the ADC conversions and such. A little redundant? Yep. But there are people interested in what I'm doing and I do not want to be responsible for blowing the engine on a motorcycle of which only a few thousand were built.

So, having said that, there's nothing on a real board, yet. A few early ideas are out there for people to look at, if they care, but nothing firm. I'm also in no particular hurry- the bike sat for over 10 years, so what's a few more?

And I find it curious, and inspiring actually, that this chip I mentioned a while back has gained a smidgeon of traction here, and now. By no means is it a powerhouse of engine control... but it does bring ARM architecture forward, even if just a little bit.

[Nobody]

It provides most, if not all the functions some of the Freescale and ST processors provide. And the cost of the LP board ($20 USD) and software tools (free) is hard to beat.

RE: documentation and such mentioned previously.
TI's E2E forums are great resources where TI employees and engineers are often the source of solutions.
http://e2e.ti.com/search/default.aspx#q=Hercules
Register and ask away.

I might suggest foregoing the RTOS approach and work with state machine type thinking.


Looking forward to what happens next.

I’d agree the $20 is a good bang for the buck, especially since in low quantity the MPU alone costs more than that. If you are drawing a comparison between ST32 series, than only thing it has on TMS570 is MIPS. I’d think most will realize TI tried to copy Freescale TPU with their HET.

But it is a robust chip as required by AEC100 or automotive specifications and this goes far beyond temperature range. I almost chose this MPU.

As far as earlier comment on angle domain, this was based TI forum and user complaining to engineers than an app note was due years ago.

To RusEFI:
Keep in mind that this MPU only has 19 timer (HET) channels, so it will practically be limited to 6-cylinder application with electric throttle and rudimentary VVT (variable valve timing).

[abecedarian]

I’d agree the $20 is a good bang for the buck, especially since in low quantity the MPU alone costs more than that. If you are drawing a comparison between ST32 series, than only thing it has on TMS570 is MIPS. I’d think most will realize TI tried to copy Freescale TPU with their HET.

Mouser lists the TMS570LS0432 at $11.42 USD in single quantity, knock a dollar off each for 10.
1.66 DMIPS/MHz is nothing to sneeze at, and I believe TI has released newer chips capable of faster operations.
And no doubt TI pulled a page from the TPU making N2HET. But whatever your position on that, the functional operation makes sense.

But it is a robust chip as required by AEC100 or automotive specifications and this goes far beyond temperature range.

It's not just automotive / AEQ100 certifications that matter. TI even has suggestions for meeting ISO certifications for use.
The R4/R4F architecture is aimed directly at real-time operation and safety use-related designs.

I almost chose this MPU.

Too bad you didn't. I'm sure the research you'd put into it could at least open up some avenues for others even if you did't release code for it.

As far as earlier comment on angle domain, this was based TI forum and user complaining to engineers than an app note was due years ago.

I know. And as of June 2013 I believe, the only thing TI has released, and it's not on their websites for some reason, is an app note for the HET on a TMS470 device with HWAG. I suspect there may be some agreement with an OEM that has TI's hands tied regarding release of sample code and such.

To RusEFI:
Keep in mind that this MPU only has 19 timer (HET) channels, so it will practically be limited to 6-cylinder application with electric throttle and rudimentary VVT (variable valve timing).

Not entirely true.
For engine operation, two of those channels will be synchronizing triggers- cam and crank, leaving 17 channels.
Now given that, the programmer / developer has the option of allowing N2HET to control everything, or can offload some of the work back onto the core, meaning N2HET isn't turning things on and off on its own, but rather only telling the core that some event has to happen. A few N2HET channels could be used to tell the core to fire (A) injector (B) ignition and maybe (C) VVT and stop (A), (B) or (C), leaving the core to determine which (A), (B) or (C) to affect.

We could get even more trivial and have N2HET simply "run", and using the cam and crank signals, fire an event at every 1 or 0.1 degree, and leave the core to figure things out.

And I'd rather the core use a TPS on the pedal along with either another TPS or some quadrature encoder on the throttle butterfly do the throttle positioning, than delegate that to the N2HET module.

Quite literally, N2HET can't do everything. So what matters is using its channels effectively.

[Nobody]

First I realize that AEC Q100 is not limited to temperature and guarantied performance across the board, but regrettably that is the focus here (rusEFI), and memory error detection, latch-up resistance, safety considerations… don’t get factored in. As far as ISO certification, I’m currently living in SIL 3, CAT 4, PL D/E hell for my day job, lockstep operation is one of the best ways to get there.

Now let’s not blow above comment out of proportion, because I don’t believe ChibiOS even supports watchdog timer which is so low on food chain it’s not even funny. So no basic safety is assumed.

As far as angle domain, I’ve done that before many times - search on my posts… In simplest terms, you need a modulus counter being incremented by timer (over simplified), but it chews up lots of resources.

Now as far as 19 HET timers, I referring to MPU that is populated on board you referenced, same goes for MIPS as 300 MHz versions are available.

Now I’m not here to compare HET to TPU.

Channel usage is simply:
- 6 injectors.
- 6 coils.
- 2 - crank + cam (best case)
- 1 electric TB (best case, usually 2 outputs).
- 1 evap solenoid
- 1 VVT (single PWM - best case).
- 1 EGR
- add in engine specific variables here...

Now since this is being tailored towards older vehicles you have auto trans interface that can include shift pressure PWM at a minimum not to mention easily another 4 PWM depending on make.

So it’s easy to peg 19 HET channels, I’d almost say it’s good for a robust 4-cylinder. Please don’t say software timers for spark, because an internal combustion engine is not a steady state machine, it’s always accelerating and decelerating depending on cylinder pressure generated by combustion and that’s never uniform.

Oh, I went with MPC56xx mostly because of past experience with MPC55xx and the built in decimation filter and other peripherals that TI did not offer. I will say that choices are fairly limited and only 3-4 real players in powertrain applications.

[abecedarian]

TI has recently introduced a few TMS570 chips. This one here might be of significant interest. Up to 300MHz, FPU and 2 N2HET modules. It's like the TMS570LS0432 on the TI Hercules LaunchPad board X 2.

[AndreyB]

Exactly! I think that back when this thread was started these higher frequencies were not available. Couple months ago - around the time I've got my TMS57004 board - I've seen the 300MHz with FPU and since then TMS570 family is my official dream.

@ has mentioned that he has placed an order for some TI board and he is hoping to move https://sourceforge.net/p/rusefi/tickets/82/ forward.

[abecedarian]

Am looking forward to the results.

[AndreyB]

I am trying to figure out which trademark name is what.

Stellaris - is that the name for TI ARM M3 & M4 micro-controllers?

Hercules - that's a safety micro-controller platform - there are three kinds. What's the difference between TMS570 and RM? Different voltage? The temperature rating is the difference, we need the TMS570.

[AndreyB]

TI has recently introduced a few TMS570 chips. This one here might be of significant interest. Up to 300MHz, FPU and 2 N2HET modules. It's like the TMS570LS0432 on the TI Hercules LaunchPad board X 2.

The fastest version in LQFP package seem to be TMS5702125BPGEQQ1 - 160 MHz, LQFP-144 ~$35

TMS570LC4357 is a 300MHz version with single and double (!) precision FPU but it's only available in BGA package. 337-Ball Grid Array, is it an option for DIY?

See http://rusefi.com/wiki/index.php?title=Hardware:Texas_Instruments

[abecedarian]

BGA is not something most DIY would attack but I've known of a few people that do use them with reflow ovens and/or hot plate method to reflow. Similar techniques have been used by people to fix the XBOX360 RROD issue.

Note that the TMS570LS03xx/4xx, TMS570LS2xxx and 3xxx chips do not have PWM module(s) so if you were planning on that for throttle / h-bridge control some other method would be needed; TMS570LS1xxx do have PWM. Also, the 100LQFP chips max at 80MHz; 144LQFP @ 160MHz; BGA @ 180 for most, but the 4137 hits 300.
Part numbers ending with 7 have 10/100 Ethernet MAC also.

Here's a pretty thorough, though still somewhat basic comparison matrix of the various chips:
http://www.ti.com/product/TMS570LC4357/compare

[abecedarian]

New USD $20 TI dev kit based on TMS570LS1224 is available.
- Automotive qualified processor (unlike STM32F4)
- 180 MHz dual core / lockstep ARM R4F with single / double precision floating point unit
- 1.25 MB program Flash, 192 KB RAM, 64 KB FLASH for EEPROM emulation <- the latter sounds like a good place to store tables, et cetera for tuning purposes no?
- two N2HET timers / co-processors (analogous to the eTPU on similar Freescale / STM processors)
- 16 bit EMIF (external memory interface), also usable for some peripherals, ECC enabled,* only on BGA processor, not on this kit
- UARTS with LIN support, 3 CAN controllers, I2C, SPI
- two 10/12 bit ADC buffered modules
- two N2HET modules (one more than the TMS570LS0432)
- supports two TI's "BoosterPack" headers for those add-on boards
- all MCU pins brought out to single-row headers along the long edges of the board

Just saying....

[AndreyB]

Good stuff! It's probably worth mentioning that there is a bit of progress RE: TMS570 on the Russian part of the forum - see http://rusefi.com/forum/viewtopic.php?f=9&t=748

[kb1gtt]

Cool. Do I recall that this also comes with a compiler? I seem to recall it does come with a free as in beer compiler, which works for me.

[AndreyB]

I seem to recall it does come with a free as in beer compiler, which works for me.

That russian dude is trying to figure this out. His current understanding is that Ti Code Composer Studio is and IDE and non-totally-free compiler bundle, he is looking into using the IDE part of CCS with a free gnu compiler.

Anyone who can contribute to https://sourceforge.net/p/rusefi/tickets/82/ should do so. AFAIK there is some code but no Makefile yet.

[abecedarian]

As far as I know:
- Code Composer Studio, is free to download, and there is no code size limit
- HalCoGen, the N2HET development stuff, is free to download, and has no limit for code size.

HalCoGen would be used to configure N2HET and such; and its output files would be the basis for a CCS project.

If you dig deep, there is a CLI for the N2HET compiler, which HalCoGen invokes. It is very poorly documented, as in there is NOTHING to find on the Internet about it. For instance, TI advertises these chips as having a "hardware angle generator" but good luck finding anything, anywhere, about how to use that.

I can't say what is going on.

[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 21604 times

The kit I'm now looking at:

hercules-tms57ols.jpg (303.51 KiB) Viewed 21604 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?