rusefi.com

That's a long shot and https://sourceforge.net/p/rusefi/tickets/82/ is still pending, but at some point we would need a module for TMS570 micro-processor.

The benefit of TMS570 is that it has proper automotive rating. I suggest that we make a board for a LQFP-144 TMS570 process and we keep the same general pinout as http://rusefi.com/forum/viewtopic.php?f=4&t=381 - the goal is to use this TMS570 board with existing Frankenstein and Frankenso.

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

One thing that'll be fun is mapping the TMS570's 144 pins and peripherals to the STM32's 100 pin layout and peripheral set... and what are you going to do with the other 44 pins on the TMS?

Just a quick glance at the STM board and 100 pin proc, compared to the 144 on the TMS shows things are in quite different locations on the chips.

Right... How about 100 package, would it make it any easier? In terms of peripheral the minimal set for the 1st test board would be some ADC pins, some input capture and one UART. I guess once we make one set of boards to confirm the schematics we would drop it on a full board without the discovery pinout.

In 100 pin, you'd be resigned to using either the 0432 or 0332, neither of which have FPU. The difference between those two is 384KB (0432) versus 256KB (0332) flash.

The 57004 launchpad board breaks all the pins out to the 3 headers. The underside of the board lists the default function for each pin. You can match those up with the datasheet to get an idea of where the physical pins on the chip are, then compare that to the STM's pin assignments to get an idea... which is mostly the same as what I mentioned- ST and TI have pins MCU pins in very different locations, and it looks like both brought out pins to the most convenient header locations.

I fear you'd be doing quite a bit of signal crossing and maybe even running jumper wires to get any TMS570 to match up to your Frankenboard.

Maybe I'll sit down later tonight, or in the morning, and make a pin-map between the 144 pin packages for both, after I figure out what STM's port assignments work out to regarding the peripherals multiplexed on each. One glaring difference is going to be the N2HET peripheral on the TMS570s which the STM lacks entirely.

TMS570LS0432 datasheet: http://www.ti.com/lit/ds/symlink/tms570ls0432.pdf 100LQFP
TMS570LS3137 datasheet: http://www.ti.com/lit/ds/symlink/tms570ls3137.pdf 144LQFP
STM32F405xx/407xx datasheet: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00037051.pdf 100 LQFP

Other handy information for TMS570LS31x/21x MCUs- http://www.ti.com/lit/ug/spnu499b/spnu499b.pdf

If making it compatible would turn to be a crazy idea we can simply draw our own version of the Launchpad-compatible board to prove our KiCad project.

Yep, I know - no FPU in 100 pins. My point here is the the incremental approach
original Launchpad ==>> 100% same code but our board ==>> minor change to the board & code

Sounds like what I am looking for here is a TMS570 144 pin dev board. Do they have any?

There are several dev boards / eval kits, but I don't think any are 144 pin, and don't think you'll like the prices.

Scroll down this page:
http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/c2000_performance/safety/tms570/tools_software.page

If we are looking at making an equiv of the discovery can we simply put the extra pins on visas such that we have access but start with Frank features? Also are there really that many more feature pins? The extra pins could be +v or -v. The STM is designed got two later board designs, which often results in less power and ground pins.

kb1gtt wrote:If we are looking at making an equiv of the discovery can we simply put the extra pins on visas such that we have access but start with Frank features? Also are there really that many more feature pins? The extra pins could be +v or -v. The STM is designed got two later board designs, which often results in less power and ground pins.

Honestly, it's more about what functions the Frank board requires from the MCU, routing them from the MCU to the board, and most importantly does the TMS570 actually provide peripherals that are a functional match for what you require. Extra functions from the TMS570 could, as you mention, be routed to another header or similar for future prototyping purposes.

I would wager a guess that the chips general functions can be routed reasonably well. For example, going CW around the header we generally have analog to the left top side of the header. Then misc digital IO (DIO) along the bottom like USB, SPI and CAN are along the bottom of both headers. Then digital signals like injectors and spark signals are on the top right side of the header. This separation of AN, GPIO and DIO are a reasonably commonly grouped by the chip MFG. If the grouping of these general features in a clock wise (CW) fashion around the chip, starts with AN, DIO, to GPIO, then we are in fat city. However if it's AN/GPIO/DIO then we would need to flip the chip to the other side of the board. If they are not grouped, then we could be in for a challenge.

Perhaps a picture of the chip with some blobs of color to show AN/GPIO/DIO would help show how routing issues might be dealt with. I'd love to volunteer for such a picture, however I'm ignorant about these chips so it would be a large amount of work and I feel I wold be best used focusing on other priorities.

About PGA, I would recommend avoiding it, as it's hard to get the design to play nice with large temperature variations. Flying leads is easiest to design with. If we can use flying leads I would suggest it. Often with PGA you need to control the reflow curves very specifically to prevent stressing as the solder cools down. Yuck. Flying leads is far more tolerant of a less controlled reflow process.

Proper routing can easily be solved with more layers as well. Then it's more of a cost issue then a routing challenge.

kb1gtt wrote:I would wager a guess that the chips general functions can be routed reasonably well. For example, going CW around the header we generally have analog to the left top side of the header. Then misc digital IO (DIO) along the bottom like USB, SPI and CAN are along the bottom of both headers. Then digital signals like injectors and spark signals are on the top right side of the header.

Maybe they could be routed reasonable well. But, if you look at the pins on the TMS570LS3137 (most other TMS570LSxxxx are very similar), the pins don't lay out the same way. (datasheet linked earlier). Multiple layers is probably required, or at least highly suggested, in order to maintain some semblance of compatibility with the Frankie board.

This separation of AN, GPIO and DIO are a reasonably commonly grouped by the chip MFG. If the grouping of these general features in a clock wise (CW) fashion around the chip, starts with AN, DIO, to GPIO, then we are in fat city. However if it's AN/GPIO/DIO then we would need to flip the chip to the other side of the board. If they are not grouped, then we could be in for a challenge.

By default, on the LS3137 (most other 144 pin TMS570 are very similar) pins are arranged around the chip:
... communications (SPI, CAN, LIN, FlexRAY, et cetera): 1-5, 13,14, 32, 37, 40, 51-55, 89-100, 105, 126, 128-133, 142.
... analog / ADC: 58-86.
... GPIO: 9, 14, 16, 22.
... N2HET: 6, 15, 23-25, 30, 31, 33, 35, 36, 38, 39, 41, 91, 92, 106, 107, 118, 124, 125, 127, 139-141.
... the remaining pins are VCC (1.2v), VCCIO (3.3v), VSS (ground), and error / status pins.

Perhaps a picture of the chip with some blobs of color to show AN/GPIO/DIO would help show how routing issues might be dealt with. I'd love to volunteer for such a picture, however I'm ignorant about these chips so it would be a large amount of work and I feel I wold be best used focusing on other priorities. ....

Default assignments are bold and colored differently than alternate functions.

Is there a diagram representing which pins on the Frankie board do what?
Power supply? (Kudos to Jared for using the P-channel MOSFET thing I suggested 01/2014 (google it if you doubt it) for reverse voltage protection. )

Did you use drivers that can report open / short / under/over-current... maybe need ADC to sample that?
... pull-ups to the sensor V+ rail on the resistive sensors?
... op-amp isolation / buffering on sensors?


*no, I don't sleep. I just blink a lot.

https://docs.google.com/spreadsheet/ccc?key=0Arl1FeMZcfisdEdsa01mTW9YV0pRU29POUE4QUlma0E&usp=drive_web#gid=0 & https://docs.google.com/spreadsheet/ccc?key=0Arl1FeMZcfisdE1JN0pfSFV0Yk1RcGFyVjA0ZDkxdFE&usp=drive_web#gid=0 are hopefully the pages you are looking for

We need to create a nice starting page for everything hardware

Yep, this is going to be fun.

For those interested:
TMS570LS3137 Cadsoft Eagle part: It does, as of now, only list the default pin functions. I hope to add the alternate pin functions to an upcoming version.
If you have a different part in mind, let me know and I'll see what I can do.

It should be easy enough to import to Kicad for those using it.

Might be worth noting it does require 2 voltages- 1v2 and 3v3, so that has to be considered.
This might be a consideration for some future revision / power source.
AEQ, multiple voltage level outputs, short to ground/battery protection, under/over voltage monitoring, and more.