_ _ | | | | | | | | | |/\| | \ /\ / \/ \/
_____ |_ _| | | | | |_|
##### ## ## ## ## ##### ## ##
______ ( __ \ | ( \ ) | | ) | | | | | | | ) | | (__/ ) (______/
_ _ ( ) ( ) `\`\/'/' > < /'/\`\ (_) (_)
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: This page specifies what needs to be done for the next firmware release. Next release is named: '''STABLE_1_1''' Tasks left before release: * New Timing Scheme (Dave & Marcell) ** complete the JAVA prototype ** implement the OnlineCourse/Modeling/Scheduler . This makes it possible to guarantee worstcase 300..400 usec turnaround for the highest priority trigger-process code ** Port model to firmware ** the interrupt becomes rediculously simple. This helps porting to ARM ** the clever stuff moves to userspace. If the next output event is due in less than 400usec (or there is no trigger expected before the output event), we schedule the eventqueue event right away (not wait for next trigger) ** Make it work * Scheduler (Fredrik) ** Framework needs review ** Port tasks to use it * Move towards 16x16 maps with configurable bins per table ** Implement in firmware ** Adapt megatune / mtx profiles to suit firmware changes * Remove config.warmup_rpm[] and add back a single rpm multiplier for decreasing warmup enrichment at increasing rpms * Make it bootable again ** '''The Problem''' ** Halfway through main_loop usercode stops running ** OCR16 (event2core) and ADC keeps on triggering ** So does PS2 whenever a key is pressed down ** It broke between 20041124 and 20041127. [http://www.vems.hu/files/FredrikJagenheim/crash-diff.txt Here] is the trimmed diff. ** ''any ideas?'' My major suspicion is in calc_trigger(uint8_t adv, uint8_t igncount) ... maybe it's just misconfiguration (that causes lockup). This function will likely be dropped altogether, so the trigger-tooth is not calculated beforehand (rather just in time, decide at every tooth if it's to trig sg. or not). Tasks suggested: * Make seperate v2 release and only support it for bugfixes * Sensor inputs ** '''Displaying and logging all inputs''' *** EGT x 2 *** Exhaust backpressure *** Fuel Pressure *** Second WBO2 Channel *** User configurable inputs for the free ADC Channels ** EGT based fuel enrichment (High power engines need a enrichment for cooling when the engine has been under load for a while ** Launch Control (Add a configurable revlimit to ALS code, fuelcut or configurable fuelcut/ignition cut) ** Make the temp sensors configurable, instead of compile time generated and converted tables (calibrate through ADC counts, 3 constants, eg. at 25 and 100 Celsius and 0° (melting ice) ** Alarms when lost or broken sensor signals detected ** Alarm when TPS is outside the configured range (with some mariginal), maybe add a 47k or so pullup so a lost signal can be identified (Currently floating) ** if possible, detect a broken MAP signal: the same method that we use for WBO2 nernst would work everywhere. It involves pulsing the signal through a big (10..100k) resistor from a 5V square pulsing and measuring the divided AC component. At high impedance (no signal connected) the AC component will be high. * If new scheduler and timing from last tooth takes a lot of time to finish, i think it would be wise to postpone them to a later release and try to support simple trigger + cam sync on the most common engines, 4,5,6 and 8 cyl even fire. (This is just a thought, we really need to get this working soon.) Tasks that have to wait until another release (Only put suggested tasks here): * Emulator support ** Isn't worth the investment to make a 'perfect' emulator. * MAT based ignition retard, 10 temp bins (the same bins we use for CLT) so ignition retard can be specified,that will offset the whole ignition-advance n[] map. The CLT bins temperature values can move from config (EEPROM) to flash, since they are never changed anyway. The MAT-retard can go to the same config positions. - I write here, how professional systems does it. They uses INJ and IGN correction(both advance and retard available!!) tables too. There are tables according to CLT, and MAT. Booth CLT and MAT bins shold be wider ranged, because theese functions often used to protect the engine. For example retard the advance 2 deg and add 10 percent more fuel at 110 celcius CLT(or at 70 celsius MAT). Serious engines could work up to 115 celsius or more CLT(coolant system under hevy pressure there). So we should increase the highest CLT temp that the genboard can realize at least about 125celsius, i think. And at the cooler CLT and MAT bins we could make to work the engine more good(for example -10 celsius CLT, it could have more advance, and more fuel too).I know this could be a very serious software project for us, but it could be great if the genboard could handle theese functions.- by FERO * a VERY simple deceleration fuel cutoff, a single MAP value.below that, no fuel is injected. Actually, the injpw calculation should be changed the j[]==0 means no fuel injected (currently the injopen is still applied in this case !!!). With this change there is no need for a MAP threshold in config to implement this cutoff. 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.