More additional content and a few pages (#70)
* Fix for Home page and future features page added * Update Acceleration_Compensation.md * Update Fuel_Overview.md * More fuel info * More X-tau * Ongoing Tasks list Free for all list for people to update as they change track * Update Ongoing_Tasks * Hidden names on pages and multi-spark page * Update X-tau_Wall_Wetting.md * Update * Update AlphaN.md * Update Speed_Density.md * Fuel control overview improvement, added wide band page * Update Wide_Band_Sensors.md * Update Fuel_Overview.md * Update MAF.md * Update MAF.md * Update rusEFI_console_directory.png * Delete rusEFI_console_directory.png * Delete wall_wetting.md * Fuel Index + Formats Also old wall wetting page kill * Update Pages_Fuel.md * Update Pages_Fuel.md * Create Pages_Hardware.md * Update Pages_Hardware.md * Sensor and Actuators index * Start of Ignition Index * Create Fuel_Injectors.md * Moved file * Added PNP72 jumper info * More updates + Software pages * Update MREAdapter72.md * Create Roadmap_Fuel.md * Created Kit Instruction link * Dev_Hardware_Guidelines * Images and links update * Update Dev_Hardware_Guidelines.md * Update Dev_Hardware_Guidelines.md * Update .gitignore * Ignition FAQ and start of what we cannot do * found by **Serching the forum** update * Searching at top of side bar * Photo fixes * Create Vault_Of_Ignition_Parts.md * Update Pages_Ignition.md * Update FAQ_Ignition.md * D is for DISTRACTION * stuff * Added Pages_FAQ_and_HOWTO * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * Update Dev_Status.md * FSIO * Labeled A/C Fan to Low-side, Labeled IAC Feed as 12v, Labeled 3A/3B GNDs as Power grounds, Labeled VVT Feed as 12v, Labeled EGR boost sensor as AV/MAP, Labeled TPS * Added in VVT control row, Added in IDLE valve control row, ensured alphabetical sorting excellence * Updated MREAdapter72 (markdown) * Added in TPS 5v power. * Added pin for * Added in instructions for making use of aux low-side. * Updated Proteus (markdown) * Updated Proteus (markdown) * Updated Proteus (markdown) * stuff * online * stepper idle * Create Vault_BMW_Info.md * Updated Proteus (markdown) * docs * docs * more checks * Update FSIO.md * Update FSIO.md * Update FSIO.md * docs * Update FSIO.md * Correction to Fuel Overview. * updates * Created TS-Plugin (markdown) * STM32 working units update * Update Hardware_Proteus_Wiring_v03.md * updates * Update D_is_for_DISTRACTION.md * Update HOWTO_help_rusEfi.md * Create START_HERE.md * added stub for creating PnP PCB * Initial version. * minor * minor typo * 8 vs 32 * Update START_HERE.md * Updated MREAdapter55 (markdown) * Updated MREAdapter55 (markdown) * Updated MREAdapter55 (markdown) * Updated MREAdapter72 (markdown) * Updated MREAdapter72 (markdown) * Updated MREAdapter72 (markdown) * FE3 * Ion Sense * Create ProteusAdapter72.md Co-authored-by: ByteVenom <5294819+ByteVenom@users.noreply.github.com> Co-authored-by: Matthew Kennedy <matthewkennedy@outlook.com> Co-authored-by: rusefi <rusefillc@gmail.com> Co-authored-by: rusefi <rusefi@users.noreply.github.com> Co-authored-by: Dave Blundell <blundar@gmail.com> Co-authored-by: rusefi <rCbUkxuY64GWzD2>
This commit is contained in:
OrchardPerformance
GitHub
parent
72f27fa0bf
commit
15be407e2d
|
|
@ -17,8 +17,7 @@ We probably would not articulate the guiding principles better than https://gith
|
|||
|
||||
#### Last but not least
|
||||
|
||||
Since 2012 until today, this is just a hobby project with zero paid employees. Test PCBs, forum hosting,
|
||||
damaged hardware and etc. costs money
|
||||
Since 2012 until today, this is just a hobby project with zero paid employees. Test PCBs, forum hosting, damaged hardware and etc. costs money
|
||||
|
||||
There are two ways to help financially:
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 91 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
|
|
@ -1,4 +1,41 @@
|
|||
|
||||
Looking for a motivated beta tester.
|
||||
|
||||
[Forum thread](https://rusefi.com/forum/viewtopic.php?f=4&t=1668)
|
||||
[Forum thread](https://rusefi.com/forum/viewtopic.php?f=4&t=1668)
|
||||
|
||||
|
||||
# E30 fitment notes
|
||||
|
||||
pin fixes needed:-
|
||||
Pin 6 is marked as fan but is a lowside output, this will work fine for tacho as it is a 12v grounded.
|
||||
pin 9 speed sensor needs jumping to pin 29 with the stepper input disabled/left floating.
|
||||
pin 15 lambda sensor heat is just a lowside to turn on relay, this should work for CEL
|
||||
pin 17 EGR valve is another lowside, this can work with the injectors just fine.
|
||||
pin 20 left floating as single coil on E30
|
||||
pin 21 left floating as no stepper on E30
|
||||
pin 22 is check lamp but icv on E30, should be fine as both are lowsides.
|
||||
pin 23 is injectors but lambda heater on e30, should be fine as both are lowsides.
|
||||
pin 25 air con relay left floating or jumped to pin 40/41 as appropriate
|
||||
pin 26 is a problem, MAF on stepper output - don't know solution at present.
|
||||
pin 29 is a problem, VSS input on stepper output - don't know solution at present.
|
||||
pin 33 is reserved for a high current output but is cam signal on all others - don't know solution at present.
|
||||
pin 32 is extra low side, this should work for fuel rate base on Matt and my checking of fuel rate outputs
|
||||
pin 33 left floating or jumped to pin 23
|
||||
pin 34 left floating as no inj4 on E30
|
||||
pin 35 left floating as no inj3 on E30
|
||||
pin 36 is variable intake on January but main relay on E30, might work if both are lowsides?
|
||||
pin 38 high side output, no idea if this is correct for transmission output.
|
||||
pin 39 normally programming signal, best left floating not connected to high side output for risk of killing other modules.
|
||||
pin 40 and pin 42 - not sure what is going on here but this will need work
|
||||
pin 43 tacho out but is actually used for AFM/MAF on euro motronics (vauxhall or M30 engine)
|
||||
pin 46 left floating on E30 or jumpered to use as relay or fan output
|
||||
pin 47 programming voltage, this is crank -ve on E30
|
||||
pin 48 crank -v is crank -ve on E30
|
||||
pin 49 crank +ve is unused on E30
|
||||
pin 50 EGR position is input from ABS for traction intervention, this should be ok as both are signal inputs
|
||||
pin 50 power steering request is kickdown on auto E30, might be ok as both are signal inputs
|
||||
pin 52 is throttle closed on E30, should work with AN input
|
||||
pin 53 is WOT tps signal on E30, should be ok.
|
||||
- Note on pin 52/53, early motronic is a 3 position TPS not variable, standard is to convert to a M52 TPS, we could do this conversion on the board as they are a compatible plug
|
||||
pin 54 fuel rate output is auto trans lockup on E30, might work if both need lowsides.
|
||||
|
||||
|
|
|
|||
|
|
@ -60,16 +60,14 @@ https://github.com/rusefi/rusefi/wiki/Hardware/pnp_microRusEfi_nb2/hw72nb.pdf
|
|||
| 4AF | Main Relay Power| #1| 12V | +12v from Main Relay |
|
||||
|
||||
|
||||
| xx | x | x | x |
|
||||
|
||||
### x4 AUX low-side drivers ###
|
||||
There are 4 low-side drivers available. One is used for the alternator warning light on the dash.
|
||||
The following I/O is available. A jumper wire will need to be routed between the Jx hole on the board and the appropriate pin on the car-side connector.
|
||||
| Board | stm32 pin |
|
||||
|-----|---|---|
|
||||
| J3 | PB8 |
|
||||
| J1 | PB9 |
|
||||
| J2 | PC12 |
|
||||
| Board | stm32 pin |
|
||||
|---------|------------|
|
||||
| J3 | PB8 |
|
||||
| J1 | PB9 |
|
||||
| J2 | PC12 |
|
||||
|
||||
Extra pins for [353830-5 72 pin](https://rusefi.com/wiki/index.php?title=Hardware:OEM_connectors#72_pin):
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,28 @@
|
|||
I am going to make a Nissan76pin -> RusEFI "Proteus" adapter. A friend asked how I was going to do it because he was interested in making a PnP PCB for his car. These instructions are pretty general. "Proteus" can mean any RusEFI version that has enough "stuff" to run your engine. "Nissan76pin" can mean whatever OEM connector will work for your engine. I'm going to assume KiCAD is being used but there's nothing stopping you from using your CAD package of choice.
|
||||
|
||||
Steps:
|
||||
1. Make a spreadsheet. I like spreadsheets. If you don't, you can take notes. The point here is to keep a lot of information organized and be able to shuffle it around easily. Here is a [link](https://docs.google.com/spreadsheets/d/1xH6szt3SJB7AzoseS9kyFPDHr-XMuRVpYXs7gHTQ70o/edit?usp=sharing) to the spreadsheet I made to help make the N76-Proteus adapter. (incomplete at time of writing)
|
||||
1. You need a reliable and complete pinout for the OEM connector you wish to use. You will need to know the function of every pin you want to map, what kind of signal it is/how it interacts with the engine. It would be helpful if you give each OEM signal a unique and somewhat descriptive name. You will use this name to connect the OEM connector and the RusEFI board pin when building a schematic in KiCAD.
|
||||
1. Look at Proteus(or your board of choice) pinout. Identify "unique" pins that must be matched with specific functions. ("unique" i.e. Coils, Injectors, Knock sensors, Idle motors) Identify specialized pins which exist in groups - multiple interchangeable pins that have a specialized function. ("specialized" i.e. injectors, coils) Identify general purpose output pins, sort according to low side and high side drive. Note any current limitations. ****MAKE SURE THAT THERE ARE ENOUGH PINS ON THE RUSEFI BOARD YOU WANT TO USE TO MAP 1:1 WITH OEM CONNECTOR!****
|
||||
1. Identify any power distribution pins. Constant/battery +12V. Main power/switched 12V. Main relay/ASD relay control. Power ground(s). Sensor grounds. Sensor reference (+5V). Be aware that not all OEM harnesses do power distribution the same way. You can add a "main relay" or "auto shutdown (ASD) relay" on your adapter board, if need be.
|
||||
1. match up Nissan OEM pinout and Proteus resources: match unique items first - knock sensor(s), idle motors, etc. Match special function items next - coils, injectors, etc. Assign an initial 1:1 connection, or at least where you think it should go. Match GPIO functions like fuel pump, etc. to available I/O. Pay attention to high side drive vs. low side drive. Try to group pins of like function, keeping in mind interchangeability of coil/injector assignments and of GPIO pins for routing later.
|
||||
1. Fire up KiCAD. Choose/create a schematic element with 76 pins to assign to the Nissan 76 pin connector. This can be as simple or as fancy as you want. This can be an existing symbol. The important thing is that the symbol has the same number of pins as the connector you want to use for your PnP.
|
||||
1. Create symbol(s) to use for the RusEFI board that you're going to connect to the OEM connector. Again, you need to make sure that your symbol has the same number of pins on it as the connectors on the RusEFI board. On the Proteus PCB, I need 2x 35pin and 1x 23 pin for the Ampseal connectors on the PCB. You're probably ****not**** going to use a board that actually has these connectors soldered to it but it will be ****much**** easier to connect your adapter board to an existing RusEFI board if you can just set the two boards on top of each other and use a bunch of straight pins/wires to connect the two boards together - how we're going to set it up.
|
||||
1. On the schematic in KiCAD, assign all pins on Nissan76 the unique meaningful name from your spreadsheet, to keep them straight. You will use this same name later to connect Proteus pins to OEM connector pins, taking advantage of the fact that KiCAD creates an electrical connection between signals which have the same name.
|
||||
1. Use your detailed Spreadsheet to assign the same unique meaningful symbol names(tm) on the Nissan76 pin connector to Proteus pins with a compatible function. Having a pin on each connector with a signal named the same will cause the design software to assign an electrical connection between pins
|
||||
1. If you can't find a reliable PCB footprint, make one. Refer to datasheet. If you can't find a datasheet, break out the calipers and measure pin spacing and pin diameter. as a rule of thumb, you want to have PTH that are at least 15 if not 30mil larger than the pins at their largest diameter. This will give a snug and precise but not too tight fitment. If you think you "found" a decent PCB footprint (versus making one that suits your needs precisely), double check how the pins are numbered. Many PCB footprints that I've downloaded use a different numbering scheme than OEMs use. KiCAD basically only uses pin numbering to connect a schematic symbol and a PCB footprint. You can't assign pin 7 on a schematic to pin 9 on a PCB footprint very easily. ****You need to make sure that however you have your KiCAD symbol numbered EXACTLY matches how your footprint is numbered**** Failure to respect this important rule will cause your design to be totally broken.
|
||||
1. Open PCB, import netlist. Define your board outline based on physical constraints of the case that the contraption needs to fit in. Add any mounting holes and other zones dictated by the case that the contraption needs to fit in. There will be physical measuring here to come up with something that makes sense. At a bare minimum, your board outline needs to be big enough for both the OEM and RusEFI board connectors.
|
||||
1. Place OEM connector that will mate with the harness footprint (N76 in my case) in a place that makes sense for the physical case. Again, there will be physical measuring here to get it right.
|
||||
1. Use a Proteus board (or a life size print out that you cut out) to place the Proteus (or poison of choice) board in a sensible place in the case. Think about the space it will take up and how you are going to mount it. Remember, vibration is a thing and solder joints are not designed to be load bearing, particularly for long periods of time. You will want rigid connections between your adapter board and the RusEFI board that are NOT accomplished by solder. Think: holes with bolts through them, mounting screws, co-mounting with case standoffs/edges, etc. Again, there will be physical measuring here to get it right.
|
||||
1. Place the connectors for Proteus so that simple straight pins can connect the two PCBs. This means putting the connectors on your PCB where you can simply place the Proteus PCB on top. Pay attention to connector orientation!
|
||||
1. It's time to start routing connections:
|
||||
* Route unique, sensitive tracks first. knock sensors come to mind. VR sensors come to mind. Be mindful of the need for ground planes / signal return path! Cars are electrically noisy environments and failure to think about signal return paths will cause problems. If you need more of a primer on this, look up papers/videos on high speed design / controlled impedance as the same concepts will apply.
|
||||
* Route analog signals. Start with analog +5v/reference. Try to stake out an area to put a power plane for analog ground such that all analog signals can be on top of the power plane. Then move on to analog signals.
|
||||
* Remember that in most cases, ALL analog inputs will be able to be used for ALL sensors. You can swap AN1 and AN6 on RusEFI boards in order to get cleaner routing to the OE traces that can't be moved on the OEM connector.
|
||||
* Route unique signals like idle, DBW, etc. You will have extremely limited choice for these so getting them out of the way first is a good idea.
|
||||
* Route coils as a group. Remember that in almost all cases you'll be able to set the phase of the coils so any coil output can be used to drive any ignition coil. Swap signals in order to keep layout as clean as possible.
|
||||
* Route injectors as a group. Again, swap signals to keep layout as clean as possible.
|
||||
* Route any GPIO, main relay control, etc. etc. etc. Keep in mind Low Side Drivers and High Side Drivers are not compatible. Swap signals around to keep layout as clean as possible. Be mindful of any current requirements!
|
||||
* At this point, analog power/reference should already be routed along with an associated limited power plane for analog signals. It's time to route primary power and ground pins. Start with constant battery power as this is typically a low-power signal. ****FOR POWER, YOU WANT TO USE POURS/PLANES WHERE POSSIBLE.**** Typically, top-side power pour and bottom side ground pour. Keep in mind that analog signals should have ANALOG GROUND RETURN plane underneath them if possible, ****NOT**** the main ground plane.
|
||||
|
||||
Final step: go back and update your spreadsheet with what you ACTUALLY connected. Make sure your OEM coil numbers are mapped to the coil driver that is connected on the PCB. Make sure the OEM injector numbers are mapped to the drivers controlling them. Make sure that the specific sensors on the harness are mapped to the general analog inputs receiving the signal. Make sure your solenoids, relays, etc. are mapped to GPIO. When you go to configure the unit, having this information to refer to will be invaluable and save you having to chase your schematic.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# This is a version of the 72 pin adaptor board for the Proteus
|
||||
# It shares 90% of its features with the MRE version so the information [here](MREAdapter72.md) is still valid with a few additional notes as shown below
|
||||
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# This page is intended to help ease a new user into the world of rusEFI
|
||||
|
||||
## First things first
|
||||
|
||||
It is important for a new user to understand some things about rusEFI before jumping into the hardware or software.
|
||||
|
||||
RusEFI is a community project, everyone here is giving there time for free and have normal day jobs, this limits the amount of direct support we can give.
|
||||
This means that the wiki and forum should be the first port of call for any questions. Most things are covered within these two resources.
|
||||
With this in mind it is important that new users take a quick look at the [D is for distration](D_is_for_DISTRACTION.md) page and the [What rusEFI cannot do](What_rusEFI_Cannot_Do.md)
|
||||
|
||||
RusEFI is an advance system, many of the features of rusEFI are things you will only find on high end or OEM ECUs. This means that users will need to take time to understand the systems they are working on and the principals behind them, a lot of the information provided is based on the concept of "helping you to help yourself".
|
||||
You will be expected to put in the time to find information on the sensors you are using and any vehicle specific requirements of your install. (Though the team will always help where they can).
|
||||
|
||||
RusEFI is also still very much in development, the dev team provide no guarantee that any of the current features are fully working. It is important that users take a good look at the [current development status](Dev_Status.md) page. This is what we consider the most comprehensive list of the status of all the features of the rusEFI system.
|
||||
|
||||
## Identifying your hardware requirements
|
||||
|
||||
Every one coming into this p
|
||||
You are going to need to know
|
||||
|
||||
Hall or VR
|
||||
|
||||
High or low impedance injectors and flow rate
|
||||
|
||||
Trigger style
|
||||
|
||||
NTC sensor curves
|
||||
|
||||
MAF
|
||||
|
||||
MAP
|
||||
|
||||
Ignition coils
|
||||
|
||||
## What rusEFI board is correct for your engine?
|
||||
|
||||
|
||||
|
||||
|
||||
## Getting help
|
||||
|
||||
[xxx](HOWTO_ask_questions.md)
|
||||
|
||||
## Where to search for information
|
||||
|
||||
[xxx](HOWTO-Search-on-rusEFI-wiki.md)
|
||||
|
|
@ -52,6 +52,7 @@
|
|||
- [MREAdapter55: from Lada to e30](MREAdapter55)
|
||||
- [MREAdapter72: Miata NB2 Mark 2.5 72 pin](MREAdapter72)
|
||||
- [Frankenso MazdaMiataNA6 PnP](Frankenso_MazdaMiataNA6_pnp)
|
||||
- [Creating a PnP PCB](PnP_PCB_HowTo)
|
||||
|
||||
# Contributors
|
||||
|
||||
|
|
|
|||
|
|
@ -24,4 +24,191 @@ SPC563Mx, MPC563x - this one has some ChibiOS support - https://rusefi.com/forum
|
|||
|
||||
TMS570 - https://rusefi.com/forum/viewtopic.php?f=13&t=407 & https://github.com/rusefi/rusefi/issues/89
|
||||
|
||||
(in Russian) https://rusefi.com/forum/viewtopic.php?f=8&t=269
|
||||
(in Russian) https://rusefi.com/forum/viewtopic.php?f=8&t=269
|
||||
|
||||
=======================================================
|
||||
|
||||
|
||||
Rafael Matos 4:13 AM
|
||||
@Matthew Kennedy @Andrey in your opinion whats the advantage between runing a 8bit mcu and a 32 bit mcu apart from having more timers can bus, etc? (serious question)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Matthew Kennedy 4:17 AM
|
||||
You mean why is 32b better?
|
||||
|
||||
Rafael Matos 4:24 AM
|
||||
Yes on your understanding why woukd you never use 8bit or why you wouldn't use it now
|
||||
|
||||
Matthew Kennedy 4:37 AM
|
||||
That's a sort of complicated question that you could teach several full university courses about (some of which I've taken). There are some technical factors about how the CPU and peripherals actually work, then there are some economic factors that have pushed the world in the same direction.
|
||||
Technical:
|
||||
32b generally means that the native word size of the CPU core is 32 bits, which lets you do more math per cycle. For example the stm32 can add/subtract/multiply two 32bit numbers in a single cycle, but an AVR can only do 8 bits per cycle. If you want to add 32 bit numbers, it's possible, but requires issuing four instructions in sequence to complete the operation, requiring both more time and more program space.
|
||||
In addition to the native word size being longer, addresses are also larger. An 8-bit cpu can only address 8 bits worth of memory, 256 bytes. With some trickery like the AVR does, you actually extend that to 16, but that only gets you 65k of address space. An stm32 has a full 32 bit memory bus, which gives you 4.2 gigabytes of address space. This has implications in that it allows more physical memory to be installed, in addition to more peripherals like timers/usb/serial/CAN.
|
||||
Economic:
|
||||
There has been more demand for more powerful processors everywhere (phones/desktop PC/servers/MCUs, literally everything), which means that chip MFGs have more incentive to develop and produce more advanced MCUs. This results in 32 bit processors getting diffused on smaller processes (each transistor is physically smaller), which means they can run a faster clock speed.
|
||||
Since a faster 32b processor has more horsepower to play with, the development cost is reduced. You get a better "functionality per dev time" ratio when you have a bigger hammer to hit the problem with. For example MS/speeduino/etc use dedicated timers for each output - that's why they're limited on cylinder count on the AVRs, they ran out of timers. But since we had the performance available to not worry about that, we actually only use a single timer, and just emulate an infinite number of timers in software. Is it less efficient? Yep! Does it matter, since the CPU is so fast? Not really!
|
||||
4:37
|
||||
sorry for the wall of text lol
|
||||
|
||||
Gwendal Blot 4:40 AM
|
||||
Is this on the wiki ?
|
||||
|
||||
Matthew Kennedy 4:40 AM
|
||||
not yet :slightly_smiling_face:
|
||||
:heavy_check_mark:
|
||||
2
|
||||
|
||||
|
||||
Gwendal Blot 4:41 AM
|
||||
Should be imo, quite readable for semi specialists
|
||||
|
||||
Matthew Kennedy 4:44 AM
|
||||
a quick perusal of mouser says that the fastest 8b MCU they carry is 100mhz, and fastest 32b is 400mhz
|
||||
|
||||
1 reply
|
||||
Today at 9:49 AMView thread
|
||||
|
||||
Rafael Matos 4:49 AM
|
||||
@Matthew Kennedy beautiful text, good info, as you said thats what we learn at uni, but in terms. Of engine management do you believe the advantage is only the timers and the fact it requires less cycles for the same calculations?
|
||||
|
||||
Matthew Kennedy 4:50 AM
|
||||
the actual value for this project is that with a faster CPU, the ratio of tricks or cleverness required to functionality achieved is minimized
|
||||
:heart:
|
||||
1
|
||||
|
||||
|
||||
Gwendal Blot 4:51 AM
|
||||
Isn't it an automotive rating thing also ?
|
||||
4:52
|
||||
I.e. most commonly used 8 bit platform isn't regarded as the safest one that exists
|
||||
|
||||
Matthew Kennedy 4:52 AM
|
||||
plenty of 32b stuff is automotive
|
||||
4:53
|
||||
tricore, spc5, etc
|
||||
|
||||
Rafael Matos 4:53 AM
|
||||
S32
|
||||
4:53
|
||||
Mcp5
|
||||
|
||||
Matthew Kennedy 4:53 AM
|
||||
kinetis
|
||||
4:53
|
||||
etc
|
||||
4:53
|
||||
they exist
|
||||
|
||||
Rafael Matos 4:53 AM
|
||||
The future will probably be mcu+fpga
|
||||
|
||||
Matthew Kennedy 4:54 AM
|
||||
you don't really need it for stuff like engine control
|
||||
4:54
|
||||
the versatile timers they have are plenty
|
||||
4:54
|
||||
and the whole industry seems to have settled on 60-2 as the "one true trigger pattern"
|
||||
|
||||
Gwendal Blot 4:54 AM
|
||||
Multi core 32bits MCU ?
|
||||
|
||||
Matthew Kennedy 4:54 AM
|
||||
yes
|
||||
4:54
|
||||
many of the ones we listed have multi core options
|
||||
4:54
|
||||
both lockstep and true multi core
|
||||
|
||||
Rafael Matos 4:55 AM
|
||||
Yes most also have dedicated hardware for crank cam. Timing
|
||||
|
||||
Gwendal Blot 4:55 AM
|
||||
That would be neat for interruption parallelization, with possibility of running a 60-2 or even more at 15k rpm
|
||||
|
||||
Matthew Kennedy 4:55 AM
|
||||
we can do 60-2 at 15k (edited)
|
||||
4:56
|
||||
the point of the fancy timer hardware is that you don't need per-tooth interrupts
|
||||
|
||||
Rafael Matos 4:56 AM
|
||||
Exaclty
|
||||
4:56
|
||||
Which the OEM manufacturers really prefer
|
||||
|
||||
Matthew Kennedy 4:56 AM
|
||||
everybody prefers fewer interupts
|
||||
|
||||
Rafael Matos 4:57 AM
|
||||
And also makes it easier to be plaved in several different cars
|
||||
|
||||
Matthew Kennedy 4:57 AM
|
||||
I heard an anecdote that you could break in to the debugger (halting the CPU) with an engine running on the dyno, and it would continue running just fine
|
||||
4:58
|
||||
it wouldn't vary the ignition timing or fuel quantity, but it would continue running steady state
|
||||
|
||||
Rafael Matos 4:59 AM
|
||||
The thing is, i understand 8 bit is enough to run an engine, and it works fine, everweek there is at least 9/10 8 bit ecus passing through my hands, but i dont like the fact that people try to make it look that has a lot if headroom and there is no advantage on 32b
|
||||
4:59
|
||||
Like the iphone 1 also makes calls and sends texts...
|
||||
5:00
|
||||
:face_with_rolling_eyes:
|
||||
|
||||
Matthew Kennedy 5:00 AM
|
||||
But the iPhone 1 doesn't take photos like this
|
||||
Image from iOS
|
||||
Image from iOS
|
||||
|
||||
|
||||
|
||||
Rafael Matos 5:00 AM
|
||||
Yep
|
||||
|
||||
Matthew Kennedy 5:02 AM
|
||||
also geez I need to clean my keyboard
|
||||
5:06
|
||||
though to their point, even if an 8b ecu is fully packed with work to do, it can still work fine
|
||||
5:06
|
||||
there are many cases that it is 100% adequate, and you wouldn't get any gain from a faster cpu
|
||||
|
||||
Rafael Matos 5:06 AM
|
||||
Of course
|
||||
|
||||
Matthew Kennedy 5:07 AM
|
||||
my race car would make the exact same power with an ms2
|
||||
|
||||
Rafael Matos 5:07 AM
|
||||
The problem is everytime there is a new idea to add something the mcu is a limiting factor and there is a lot of work that has to be done in order to work around it
|
||||
|
||||
Matthew Kennedy 5:07 AM
|
||||
yep
|
||||
|
||||
Rafael Matos 5:08 AM
|
||||
I get that, there is not many people that have seen and assembled so many DIY engine management systems as i did, i know what works and what doesn't work, i just don't like that people always try to find a way to justify things
|
||||
|
||||
Gwendal Blot 5:19 AM
|
||||
Main advantage of a 32 bits ECU is you can brag about it at car meets when leaning on your engine
|
||||
|
||||
Simon - Orchardperformance 5:45 AM
|
||||
I like to use the simple analogy of the flathead V8, sure a flat head V8 will run and drive, sure you can tune it up to decent power, but no matter what it is always going to be a flathead V8 and your not going to get the same $/hp or peak power or light weight from it.
|
||||
Same deal for an 8 bit CPU
|
||||
|
||||
Dave B. 9:52 AM
|
||||
If you look at the really successful automotive MCU platforms circa 201x, you'll see a few things:
|
||||
9:52
|
||||
-32 bit (way of the world)
|
||||
9:53
|
||||
-Dedicated coprocessors / programmable timer modules / fancy timers for handling time sensitive events
|
||||
9:54
|
||||
-Often a solid FPU, "DSP" or other set of instructions for doing lots of math fast
|
||||
9:55
|
||||
PPC/MPC/Power architecture, Tricore, SuperH, ARM variants. They all have very similar playbooks.
|
||||
9:56
|
||||
Unfortunately, most of the chip manufacturers will make you sign a fairly strict NDA before releasing details of their "TPU" time processing unit programing, from what I understand.
|
||||
9:57
|
||||
Processors like the XGATE that have been used successfully despite relatively modest specs (16 bit, low clock speed) tend to have very well developed secondary timing processors.
|
||||
9:58
|
||||
I look at the Honda ECUs on my bench that came in 1992 model year vehicles and would at least run an engine at 12,000 RPM with nothing more than a chip change. They have a 10Mhz 16/8 bit MCU with no floating point and an ASIC for handling timing tasks.
|
||||
|
|
@ -58,3 +58,4 @@
|
|||
1. https://rusefi.com/forum/viewtopic.php?f=3&t=1673 Renault KM4 May 15, 2020
|
||||
1. https://rusefi.com/forum/viewtopic.php?f=2&t=1740 1980 kz750 motor (carbs, electronic ignition)
|
||||
1. https://rusefi.com/forum/viewtopic.php?f=3&t=1760 VW 1.8t Drive-by-wire May 31, 2020
|
||||
1. https://rusefi.com/forum/viewtopic.php?f=3&t=1734 Miata FE swap 2.0
|
||||
Loading…
Reference in New Issue