Maybe new rusefi target? TMS570

User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by 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.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

kb1gtt wrote:... 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.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Maybe new rusefi target? TMS570

Post by 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.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

Sorry, am battling hard drive problems. Will reply soon.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by 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.
:D

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.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by 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.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Maybe new rusefi target? TMS570

Post by kb1gtt »

The layout looks reasonably straight forward. I see 5V, 3V3 and 1V2 voltage regulators.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by 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.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by 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.
You can lead the horticulture but you can't make them think.
User avatar
AndreyB
Site Admin
Posts: 14331
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Maybe new rusefi target? TMS570

Post by AndreyB »

abecedarian wrote: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 :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

russian wrote:
abecedarian wrote: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:
russian wrote:
abecedarian wrote: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.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

abecedarian wrote:
russian wrote:
abecedarian wrote: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:
russian wrote:
abecedarian wrote: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.
You can lead the horticulture but you can't make them think.
a-seely
Posts: 2
Joined: Fri Feb 06, 2015 4:41 pm

Re: Maybe new rusefi target? TMS570

Post by 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
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Maybe new rusefi target? TMS570

Post by 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?
Welcome to the friendlier side of internet crazy :)
a-seely
Posts: 2
Joined: Fri Feb 06, 2015 4:41 pm

Re: Maybe new rusefi target? TMS570

Post by a-seely »

Hi kb1gtt,
kb1gtt wrote:I'm more of a hardware guy
me too :)
kb1gtt wrote: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.
kb1gtt wrote: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
User avatar
AndreyB
Site Admin
Posts: 14331
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Maybe new rusefi target? TMS570

Post by AndreyB »

a-seely wrote: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
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Maybe new rusefi target? TMS570

Post by 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.
Last edited by kb1gtt on Fri Feb 06, 2015 10:05 pm, edited 1 time in total.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14331
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Maybe new rusefi target? TMS570

Post by AndreyB »

kb1gtt wrote: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.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by 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.... "
You can lead the horticulture but you can't make them think.
User avatar
AndreyB
Site Admin
Posts: 14331
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Maybe new rusefi target? TMS570

Post by AndreyB »

"Is stm32f4 the right chip?" discussion extracted into separate thread http://rusefi.com/forum/viewtopic.php?f=13&t=816
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
DaWaN
Posts: 51
Joined: Sat Sep 20, 2014 6:54 pm
Location: Benschop, Netherlands

Re: Maybe new rusefi target? TMS570

Post by DaWaN »

a-seely wrote: 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.
In order to make this MCU a good target for an open source project it would require the following things in my opinion:
-Build the firmware with a generic ARM toolchain on any platform (windows / linux), such that the firmware can be built with free and always available tools
-Being able to support multiple crank/cam patterns from run time software (would require run time reconfiguration of the timing engine and good documentation from the timing engine)
-MCU should be easily sourced and available for >5 years, preferably cheap too

I have not looked into the documentation of this chip, maybe I should spend some time on it soon :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Maybe new rusefi target? TMS570

Post by kb1gtt »

We have a need / desire for a faster / lower latency chip than the STM we are using. I agree that these TI chips seem to fit most of our needs / desires. I also understand the concern about licensing, as that is often overlooked and has often caused major problems for projects. It sucks when paper work issues obsoletes a project. So I agree with the scrutiny of the compiler. It would be cool if these compiler concerns get resolved.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

ARM GCC (Linaro) is available for download as an add-on in CCS6 App Center.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/384089/1356263#1356263
GCC tools are supported in the latest version of HALCoGen (v 4.01.00). When setting up the project, choose the correct "family" of MCUs and then the Tools to be used for that project.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Maybe new rusefi target? TMS570

Post by kb1gtt »

What features does the TMS chip have that make functional safety better, or decrease the chances of EMC issues?

Functional safety
-- redundant CPU with validation across the two processors to ensure the code is executing the same. AKA neutrinos are not manipulating the CPU's execution.

EMC
-- Does the chip have a published IBIS or equiv electrical model? These are handy when checking SPI lines for bit error rates, and allow you to layout a good PCB.

@abecedarian Eagle has an option for generating s-parameter files and such that will allow you to simulate and tune your PCB design to ensure you don't have eye diagram problems. AKA SPI lines and via's are a common problem, as well longer SPI lines tend to have some inductance that causes overshoot, which results in bit error rates. Video about jPCBsim found here sorry not audio, I guess you can't directly hear RF ;)
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

kb1gtt wrote:What features does the TMS chip have that make functional safety better, or decrease the chances of EMC issues?

Functional safety
-- redundant CPU with validation across the two processors to ensure the code is executing the same. AKA neutrinos are not manipulating the CPU's execution.

EMC
-- Does the chip have a published IBIS or equiv electrical model? These are handy when checking SPI lines for bit error rates, and allow you to layout a good PCB.
I replied, then retracted my response, and have spent some time pondering.

What I think would be appropriate is you post the specifications for the chip(s) you are using, along with your criteria justifying their usage. Only then can I post anything regarding comparisons between that and TMS570.

It might be easy to compare an orange to a kumquat, but trying to compare a Navel orange to Nagami kumquat requires much more details be presented.
You can lead the horticulture but you can't make them think.
sordfish
Posts: 2
Joined: Sun Apr 12, 2015 9:56 pm

Re: Maybe new rusefi target? TMS570

Post by sordfish »

Any progress with the TMS570? Ive fallen in love with it so I've got a launchpad2 to have a play with.

It seems erika rtos has support for it so when I get chance I'm going to read up on it.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: Maybe new rusefi target? TMS570

Post by abecedarian »

sordfish wrote:Any progress with the TMS570? Ive fallen in love with it so I've got a launchpad2 to have a play with.

It seems erika rtos has support for it so when I get chance I'm going to read up on it.
Erika (http://erika.tuxfamily.org) also supports STM32F4DISCOVERY board too. That might make it easier to cross port things.
It's also undergoing ISO26262 certification.
You can lead the horticulture but you can't make them think.
User avatar
AndreyB
Site Admin
Posts: 14331
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Maybe new rusefi target? TMS570

Post by AndreyB »

sordfish wrote:Any progress with the TMS570? Ive fallen in love with it so I've got a launchpad2 to have a play with.
No progress :( All my time goes towards stm32 port (technically all my time goes towards 'business logic' on controlling an engine)

It's all human resources availability. Would you be available to figure out TMS570 port skeleton and some HW integration? For instance, get the shell code running on top of TMS570 serial implementation?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14331
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Maybe new rusefi target? TMS570

Post by AndreyB »

roccomarco wrote:I suppose that is far from Cortex M since they are two core in lock step. ChibiOS is moving in that direction. The idea is to start the support of Trust Zone so we will move in the Cortex R and Multi-core MCU for sure.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply