### ## ### ## # ##### ## ## ## ## #### ###
##### ## ## ## ## ## ## ## ##
_______ ( ____ \ | ( \/ | (__ | __) | ( | ) |/
_____ | _ | | | | | | | | | \ \/' / \_/\_\
#### ## ## ## ## ## ####
IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now. Visit Preferences to set your user name Summary of change: '''ARM based EFI:''' - developer info! To avoid confusion, I propose that in the future * armefi codename is reserved for the high-end board, likely SAAB70 connector * VemsFrontier/ArmUfo will be used for EC36 based controller, still awesome featureset Significant part of the development effort is shared. This is the primary fuel injection system. Smaller than v3.x and able to communicate with the other VEMSFrontier boards * CAN on at least 2 CAN controllers (CAN transceiver must be close to EC36, not * CAN transceiver on one of the UARTs (CAN transceiver must be close to EC36, not uC) to comm with low-end boards. * CAN makes timing easier: 2..5usec timesync is possible with 115200 baud UART comm (also CAN transceiver) but requires a bit averaging; with CAN it's simpler uC) to comm with big ARM based boards, like ** another armefi ** '''external ignition module''': basically similar to armefi, with some input and output changes *** case and clamping compatible with armefi *** preferrably same (atmel arm or LPC2292) uc *** CAN similar to armefi *** trigger inputs similar to armefi *** the DPAK clamping IGBTs (with input pads so the board can be used as dummy ignition amplifier if all else fails) *** we need a DCDC for CDI anyway. ** IonSense might be included in above ** or TractionControlArm The easiest way to map pins is print page 23 .. 24 of the A3 manual and take pencil-notes (I know it has been partially done, but others must verify too: this way it only takes 1..2 hours). It seems that there are not much compromises needed * since we won't need SPI (TPIC8101 and MCP3208 not used), MMC/SD is simple. However it would be good to know if traditional SPI is possible with MMC/SD that doesn't speak traditional SPI (or we can hunt heavily for MMC/SD that speaks traditional SPI: needed for v3.x anyway) * maybe 1..2 ADC channels sacrificed '''DROP: VemsFrontier/ArmUfo'''. ArmEfi will be nice and manufacturable in every aspect, we don't need a downscaled board. * EC36 main connector 114x109mm board size * 2 CAN busses (LPC2292) * 1 x RS485 * 1 x RS232 (or FBUS uart) * CRANK and CAM trigger inputs utilizing 1 '''LM 1815 VR interface'''. * Internal MAP sensor (type ?). * CLT; IAT and TPS sensors. * proposed 2 (max 4) Ignition power stages for inductive ignition (with simple SMB flyback for when used for anything else than ign: unpopulated in PNP). ISL9V2040D3S (900 pieces in stock) * 2 high current and high voltage open collector outputs. (can be used to drive ignition coils) is this just duplication of line above? * 8 !LowZ injector outputs. (Can be used for other applications too.) Controlled flyback, still nice footprint (nice routing, Jorgen!). HUF76423D3S (900 pieces in stock). * 1 Bosch LSU Wbo2 sensor controller * 1 SN754410 stepper (powerdip). L293D '''SMD stepper driver is hard to get''' * 1..2 Knock sensor input. Maybe without TPIC8101, using the extra ADC channels * extra pins on headers (at least on developer series) * MMC flash socket or connection ---- '''Strategy ''' TPIC8101 or amplified acoustic signal into ARM TPIC8101 was the perfect choice in the past. However, with the significant processing power available, I doubt it's usefulness. We can easily filter in the ARM (with slightly more lines of code than it takes to just communicate with TPIC8101), with a few percent of processing power. Note that TPIC8101 also sets gain in the digital domain, after it's internal ADC. ---- '''Power related''' * the drivers (IGBT-s, injdrivers, etc..) must be on same side if possible (common clamping), but both on bottom PNP dissipation: assume 1A current and 50% duty: * T1 PNP: 0.5 * 1A * 1.2V = 0.6W (will it fry at 85C ? 90K/W*0.6W=54C, so junction prolly kept below 150C) * FET dissipation: 15625 Hz * (200 + 100)ns * 1A * 14V/2 + (1A * 1A * 0.037mOhm) = 0.032W + 0.037W = 0.069W The 200 and 100ns are estimated switchoff and switchon times for Ugs=5V (the datasheet says 240 and 120 for Ugs=4.5V). Will be cool with the slamping. The number of switches for inj/ign (within some limits) can be decided at assembly time (minor firmware issue). Every output must have at least an SMB for flyback protection. * Min 2, max 4 DPAK outputs have good clearance (ign-capable) * 8 PWM capabilityhave (pad for) simple SMB flyback, 6..8 has and max 4 has controlled flyback (PNP on bottom for cooling, FET on top).''' No reason for using the PowerDip version of L293D and not the SOIC L293D. In fact we need SMD. [http://www.st.com/stonline/books/pdf/docs/1330.pdf link to ST electronics pdf file] On v3.2 we use the [http://focus.ti.com/docs/prod/folders/print/sn754410.html SN754410] which has nice current range but thrughole sux ---- ''' LPC2294 (144pin, 4 CAN) or LPC2129 (64pin, 2 CAN)''' Quick info: http://www.semiconductors.philips.com/acrobat/literature/9397/75013968.pdf User manual May 3rd 2004: http://www.semiconductors.philips.com/acrobat/usermanuals/UM_LPC21XX_LPC22XX_2.pdf Errata: April 1st 2005: http://www.semiconductors.philips.com/acrobat/erratasheets/2292_2.pdf http://www.semiconductors.philips.com/acrobat/erratasheets/2294_2.pdf The 2294 is more expensive, but you can only buy 1 hamburger for the difference. Footprint is also a few mm bigger. But: * more AD * more CAN - we won't take advantage now. Is the LPC2292 otherwise fully pin compatible with LPC2294 ? * more IO * easier mapping, Mapping isn't much easier, big LPCs have the same collisions as the 64 pin chip, all the extras is only generic IO. But generic IO also helps, so featured IO need not be sacrificed. '''2292 and 2294 would be identical in our application, it seems like the two addtional CAN busses collides with more useful special functions.''' The atmel arm seems to win anyway. ---- '''2 CAN or more''' I have a feeling that we will like 4 CANs in the '''future'''. With the new modular approach, it's good to have a board that is extendable to be the central brain. No need to stuff all 4 CAN transceivers onboard during the manufacturing, and no space on EC36 for all. ---- '''when to use MCP3208 channel and when to use internal AD''' Even though MCP3208 is relatively cheap, we like the internal ADC more: because reading data from MCP3208 still requires 3 (!!!) interrupts for a sample since the SPI ain't have a queue. So MCP3208 is ideal for temperature and alike, while knock should go into CPU (after AMPlified). This also suggests LPC2294 that has more nice ADC channels. Reading through LPC user manual again, I was horrified to find that '''there is an interrupt for each internal ADC sample''' (or every received SPI byte). Still better than 3 interrupts for an MCP3208 sample, but sucks a bit. * the CAN, UART (16 byte FIFO) and timers are properly designed in the LPC.. * the SPI and especially the internal ADC lack a few bytes buffer to be even more useful Can someone confirm this? Maybe I'm wrong, search for FIFO from page 239 (definitely after UART). * ''I have checked the documentation and the ADC lack a FIFO'' * looks like the ADC can accumulate up to 256 readings which is useful for lowpass filtering, but not for knock * The SPI has the absolute minimum 1 byte receive buffer (same as the AVR) so it does not immediately overwrite previous byte with new value (and no write buffer)'' '''TODO: check the time of a minimalistic interrupt handler''', that just passes up received data to userspace'''. I'm sure it is below 2 usec (maybe 1), we'll need it to sample 30ksps of sound (and the max interrupt processing should be lower than 33 usec, including a dispatcher action and an event insert). ---- '''Trigger''' ( with minimal interrupt overhead ) First, '''trigger is clamped in HW'''. Than * Trigger is '''shaped with LM1815 and connected to an input capture'''. This allows trigging on falling edge, at negative crossingh of 0V * Trigger is '''sent to another input capture without shaping with LM1815 first''' so both edges can be trigged on. * Trigger is also directly connected to an '''ADC channel'''. This allows analyze the signal with a simple algorithm (similar to what LM1815 does in analog, but more flexible this way) and perhaps send to log (to PC or MMC) when necessary An ADC (of 2) is appr. 364ksps but sweeping over 8 channels means only 45 ksps per channel. Perfect for knock and IonSense but trigger needs double samplerate. IIRC it is not possible to automatically (using PDC for transferring samples to memory and minimizing interrupt overhead) sample in arbitrary order (eg, 0,1,2,3,4,0,1,5,6,7 ), because the "conversion sequencer" can only go in sequence of the ADC_CHSR enabled channels (someone please confirm): * that means '''same primary_trigger signal could be connected to 2 channels''' (eg ch0 and ch4 of the same ADC block) but we have to check again. I don't think we need both channels. You're right about the ordering, but it seems to me that the "conversion sequencer" is only used when using the ADC while the processor is asleep. We can still use the PDC and change the sampled channels when we get the transfer complete interrupt (e.g. 0, 1, 2, 3 4, interrupt, 0, 1, 5, 6, 7 , interrupt ). '''This means 75k interrupt / sec that was ruled out earlier. However, it might work (with a fast, highly optimized assembly handler)'''. Also, the trigger and knock/IonSense can be sampled with high freq, and the other channels just enabled for a run once in a while when necessary. The added code complexity due to non-even sampling should not be prohibitive. The interrupt processing time is exactly what we are trying to minimize. 10..20k interrupt/sec is perfect, but 100k is rather tough (even if we write in assembly). I picked this up from the datasheet: --- Only one start command is necessary to initiate a conversion sequence on all the channels. The '''ADC hardware logic automatically performs the conversions on the ''active'' channels''', then waits for a new request. The Channel Enable (ADC_CHER) and Channel Disable (ADC_CHDR) Registers enable the analog channels to be enabled or disabled independently. If the ADC is used with a PDC, only the transfers of converted data from enabled channels are performed and the resulting data buffers should be interpreted accordingly. Warning: Enabling hardware triggers does not disable the software trigger functionality. Thus, if a hardware trigger is selected, the start of a conversion can be initiated either by the hardware or the software trigger. --- '''Software configurable VR/HALL''' (to let the end-user choose between VR and HALL without changing anything on the board). VR CRANK go through the main connector too, it share pin with the HALL CRANK sensor but they use different internal signal conditioning and is connected to different CAP pins on the MCU to allow the choice to be made in software. It's a waste of pins to have separate VR and HALL-level inputs. (although it is possible to use HALL-input as a general digital input pin). * '''1 VR + 5 HALL level captured inputs possible?''' Do we have enough CAP channels available on processor? (this would allow a simple board with 4 LM1815 chips to shape VR inputs to HALL for traction control). No need for too much protection on the inputs. For example '''CAP 0.0 is available on several pins!''' We can probably find a CAP channel where we can connect HALL and VR CRANK to different pins but same channel. About trigger pullup options: * '''direct pull-control from 0/5V''' remove the transistors and control the pull (up/down) resistor from a 0/5V output pin (there are free pins because of HALL shaping NANDso) We apply a '''BAV99 to protect the 5V logic output in a special way''': anode to GND, cathode to pullup resistor, midpoint to NAND output. This '''protects the NAND output and also eliminates the pullup resistor completely when NAND output is 0V. This looks like the best solution we can find''' Thanx for applying it, looks great. Btw., the whole thing, so far. ---- '''Amplifiers''' * we'll use quad OPA-s with low temperature-offset dependence.See VemsFrontier/OpaSelection * measure board temperature * have 1 highZ instrumentational amplifiers (3 OPA each ouch) * have 2..3 simple differential amplifiers (1 OPA, input is lowZ, but perfect for EGT, knock or even MPX700A) * measuring GND current would be interesting. total-sum, or several individual channels. Only if space is left... * 1 external GNDx referenced PWM output (just 1 OPA) would be desirable, I think (driving gauge, or Autronic wbo2 input). ---- '''Powerful logic chips driving the gates''' see VemsFrontier/ArmEfi/FetDrive ---- Locking: UnLocked: armefi_r043_jk.zip '''TODO:''' * Fit MAX232 * Make board wider to make room for connectors and fitting on front panel. * Consider header for 'advanced communications board' CAN would move here and stuff like bluetooth, USB and Ethernet could also be implemented on this board in the future. * Add NPN output for fuel pump relay * Add NPN output for activating relay with the board in powersave mode. (to bring it to full power mode) * Split powersupplies to support several weeks in powersave mode. ''I have local sketches for this that I haven't had the time to transfer to sch -Jörgen'' * Fit a heartbeat LED. VERY IMPORTANT!!! * Wire up the stepper drivers. CHANGE TO DIP VERSION * Make powersupplies. Using MC33269DT-5.0 for 5 and 6v(diode) and MC33269DT (MC33269DT or MC33269DT-adj)adjustable regulator for 1.8 and 3.3v (even if we plan to use the fixed versions.) * U14 supply from GND referenced 5V (either separate 78L05 or shared). The GND5 referenced 5..6V supply will fry it. -As planned. !!!!!!! * R64 boardtemp NTC available in 0603 ? -Yes, Elfa has them stocked. * CH7 (MAT) to ARM or mcp3208 * Assign subcircuits to powersupplies based on sensitivity and power demand. * Set ground strategy. It seems that FETs, IGBTs and stepper drivers are on GND5 while everything else on GND. anything special ? Yes, we share one GND wire between sensors, logic, trigger and so on. That force us to set tighter routing rules for GND. But I'm on top of it, noone else seem interested in good GND. * MAP the MAT0.* pins to the ignition IGBT's and the MAT1.* pins to one of the stepper drivers. It can be the other way around too, let routing decide. *Map drivers and sensors to connector. *add headers for unused pins * Add 1 external GND referenced PWM out (high frequency). * Have at least 1 (2 if possible) diff-input channel. Low-impedance is OK (=>no need for the 3 OPA instrumentational circuit, just the 1 OPA circuit as on v3.x (small footprint). This is very important for injector-diagnostics and we cannot implement auto-dwell without it. Unfortunately packing on EC36 is impossible, so this will be available on the "diag connector" - only on extra version (higher priced) units. '''Done:''' * Add scope input * Fix that LM1815 clamps the hall to 3v (move LM1815 feed to before the first protection resistor and make the LM1815 protection resistor larger). * Check SMD stepper driver for problems and if it passes make footprint and replace powerdip version. - Done, SMD version will be very nice. * Fit gate resistors to IGBT's. * Design safety feature that shuts off all outputs if PowerGND is more then 0.7 volt higher then GND. ''Done, I only have to move from paper to sch. -Jörgen'' Are you planning on some peak-rectifier ? I hope this is not an OPA circuit, but a simple DR or just a 2-resistor voltage divider towards 5V should be perfect (best on an interrupt-capable input). '''I can't come up with a good way to do it without an OPA, with hysterisis and treshold resistors we are at 4 resistors and one OPA.''' We don't need anything special, the noninverting output stage will automagically switch off the FET (without oscillation!) when PGND rises. -wrong, it may turn on again when the PGND get closer to GND as current decrease. *Add 603 or 805 NTC as board temp sensor. * Improve Hall input by using 74HCT132 chip in series. Let VR and Hall share input pin but use different signal conditioning and CAP pins. (Software configurabel VR to HALL at almost no cost.) ''90%'' * Fit gate resistors to FET's. * Add 74HCT132 driver chip for the IGBT's. *Add voltage sense. *Add LM1815 VR interface: The v3 design is perfect. *Fit new surface mount crystals for knock and MCU (available in latest revision of jurg.lbr). *Try to route and map the injector and flyback wires. They can swap places. '''mapped, routed, but needs cleaning''' * Really consider removing the IGBT's and building an external IGN module instead, this will let us use a MUCH smaller connector. Most people already have coil drivers or smart coils. -Done, we keep the ignition drivers. * Change 74HCT08 AND chips on ijectors to 74HCT132 Schmitt NAND chips. * dip switches (various HW configurations, for example Hall pullups) dropped, they would ruin our robust design. * '''Decide what do remove from connector, we need 39 pins and only have 36. See below. -Done''' '''Layout Notes''' * Set Grid to 5 MIL * MIN: 10mil width, 12 drill via with 24mil diameter * Middle 4 pins on the DIP packages are for heat sink, strong ground plane * pin 3,6,11,14 of the DIP's go to the connector. *the logic-stepper connections. 1A, 2A,3A, 4A, 1-2EN and 3-4EN on both stepper chips can be connected to any of the remaining outputs of IC3 and IC4. Pin mapped to optimize routing. * Stepper Driver connector wires ~ 24mil ---- '''ECIII 36 pin mapping:''' - for armufo <code> '''Main connector:''' Trigger: 3 Hall 5V supply (also used for TPS and MAP) CAM Crank Sensors: 10 CLT, IAT, TPS, MAP, Spare 5 WBo2 5 (4 would be enough) Nope, this board use the Rcal and need 5 wires minimum for WBo2. Outputs: 20 INJ (HW-PWM capability) 8 stepper pushpull #4 Ign/Misc (high voltage and current) 4 Idle/misc 1 DPAK Fuel pump 1 DPAK. Variable intake 1 DPAK Boost solenoid 1 DPAK All outputs feature flyback, including ign (SMB diode population optional at assembly) Power:4 Power_gnd 1 GND 1: also ground for sensors and triggers Switched_Power 1 TODO: elaborate Vbatt 1 Solves a lot. TODO: elaborate Flyback Internal? ----- 37pins!!! '''Not on EC36!''' Network:0 RS232:0 (2) CAN: 0 (2) VR inputs: 1 X BNC for CRANK CAN: Standard DB-9 CAN connector (two of these) Probably only headers on the board RS232: Autronic compatible plug Knock sensor: BNC </code> Optional: Add document to category: Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.