##    
   ##    
 ######  
   ##    
   ##    
   ##    
    ###  
         

         
         
 # ###   
 ##   #  
 ##   #  
 # ###   
 #       
 #       

 ###     
  ##     
  ##     
  #####  
  ##  ## 
  ##  ## 
 ###  ## 
         

  _      
 | |     
 | |     
 | |     
 | |____ 
 |______|
         
         

         
         
 ##  ##  
 ##  ##  
 ##  ##  
  #####  
    ##   
 ####    

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 lists for developers some items they can pick from''' ''When changing the semantics of a variable or table, please write a note to GenBoard/UnderDevelopment/FirmwareChanges'' ------ GenBoard/UnderDevelopment/FirmWare/NextRelease specifies what tasks has to be done before we can create a new stable release. ------ The syntax of the page is inefficient. '''There should be a ''features relation'' ''' with attributes:N * feature name * short description * long description * priority * state (wishlist, designed, implemented, tested, well-tested) * test documents * responsible person(s) * implementation file(s) * other data The TODO-list could be generated automatically, and the finalization of features should not require moving to another ''page'' (or table or whatever). ---- '''Priorities:''' 0: unknown (may be urgent too) 1. light-wish 2. wish 3. strong wish 4. planned far future 5. planned near future 6. planned very soon 7. urgent 8. urgent bugfix 9. critical bugfix ---- '''Strategical list''' List of tasks that you can choose from if you want to join: Feel free to add new items, add your name if you feel like doing it (that '''does not mean others cannot participate'''), or start a discussion about them. * pri=6 finalize WideBand lambdatarget feedback (MembersPage/MichaelKristensen, MembersPage/MarcellGal) look at firmware, keywords: update rate, confidence (Ri on target) * pri=7 ArmEfi (HW) To be able to strip this board to make Ufo. * pri=7 ArmUfo (HW) used as lambda meter * pri=7 Lambda vout on OC3C, 10:1AFR=0% 30:1=100% (For Autronic Autotune) * pri=7 Input from professional lambda meters (1v per lambda) or Autronic format (AFR10:1=0v AFR30:1=1v) (For verifying our WBo2 application.) * pri=5 StandaloneWBo SW * pri=5 DizzyBoard IonSense (MembersPage/KeithHargrove MembersPage/JörgenKarlsson) * pri=5 LoggerIntegration (MembersPage/RichardBarrington) * pri=6 overlapping dwell for direct ign (MembersPage/MarcellGal) * pri=4 play with IPAQ with GPS jacket (optionally palm)(MembersPage/RedMist) * pri=4 StreetDyno (using RPM, VSS, GPS), ChassisDyno (MembersPage/RedMist) * pri=5 MegaTunix handling the MSAVR variables (mcd) (MembersPage/RichardBarrington) * pri=6 OtherTuningsoftware (or compiling MegaTunix on win32) * pri=3 histogram of tooth-times to catch bad (inverted) install of VR sensor (33+1.5+1.5 instead of 34+2) and possibly other problems * pri=1 currently it's not supported to build a firmware with -D NOIGN. It doesn't make much sense, since ignition can be disabled in configuration. Only makes sense for special apps, that are short of flash. The pri=8 was a joke, I guess. * pri=2 WBO2 only builds with -D BENCHMARK set. This is known. * pri=6 Support for even tooth wheels (cam sync with multiple tooth wheels even) This will be needed for any Rotary with stock triggers and Hondas with stock triggers, probably more than that too. * pri=1 CEL Reserve and define an ouput for driving a check engine light. But what conditions should activate it (besides the 2 seconds or "until RPM found" powerup light-up)? ** Eg. if WBO2 Ri target cannot be reached (or Ri confidence low) for a significant time, we know that WBO2 is not functional. ** if WBO2 is working, and it shows lambda target cannot be reached. ** serious knock detected ** For dual-trigger applications the loss of one trigger can activate it ---- Misc. '''smaller TODO items''' * GenBoard/UnderDevelopment/FirmWare/Settings discussion on how settings are retrieved and stored. * generic logging functionality * cvs version of files stored in flash (maybe the CVS/Entries can be used?) The global.h is especially important: maybe we write a command like mcg.. to the start of config.mtt that when downloaded to a firmware that has different global.h than .. will emit a BIGWARNING.. (to RS232 and maybe LCD). People keep sending bad config.mtt to the AVR from time to time and they wonder why the result is stupid. Not only that, other tuning software could download the global.h, instead of having the (hopefully) latest version around. * a small branch in bin/make-...pl for canonizing config.txt and tables.txt: this will allow us diffing the result read back via ''mcd'' and whatever is in the config.txt and tables.txt files: see what changed, and catch config.mtt made with bad global.h revisions. * baro/dbaro should be done after table lookup * make the battery voltage measurement configurable (compensate for wrong voltage divider) * search_table(n) "on demand", no need to run it if say engine.coolant hasn't changed since last time. I say make it binary-search (log(n) steps) instead. (well, in case of coolant I guess a slow linterp without rx21 is still there...) * cranking pw decrease with time to avoid flooding * Injector flow bench: mxo (too fast?), mdp, duration * airden = airden_table[MATFACTOR] instead of seperate table? (We already have the MATFACTOR) * flash checksum * "lock" eeprom after flash update (don't do anything before special command is executed that unlocks the eeprom). Some suggest to park the eeprom pointer to a dummy unused location, so it's not pointed to the last used active data - an overcautios step to prevent corruption. I'm still uncertain about RC-type or the MCP809-type reset circuit options, either is possible. * 64 byte sendbuffer for RS232, with one what_to_send() call per mainloop: whenever the byte-buffer is not full, and the cmd-buffer is not empty, it can start consuming the cmd_buffer and filling the bytebuffer '''DONE''' * lightweight sheduler so RS232 what_to_send() and rpmcalc,fuelcalc get higher priority than LCD and other inferior tasks * runtime configurable iac (enabling of stepper / pwm) * comm.c: VE_TABLE_FIX doesn't work as expected (?) ----- Some User request for the GenBoard 2.2-3.0 * '''N2O activate output''' DONE * '''Shift Light''' - Indicates the engine runs over a configured RPM, and driver needs to shift (1 bit output channel). Look similar to N2O output (which also consider TPS, and is DONE). * '''Spray intercooler''' - Power on/off the WaterInjection pump or the InterCoolers cooling fan, controlled by MAT signal (1 or 2 bit output) Needs a configurable output pin, like the WOT. See GenBoard/UnderDevelopment/ConfigurableMiscOutputs. * '''Full Power Shift Cut''' - If the driver shifts, without using the clutch, at full throttle, the MS should cut the spark while the shifter is moving. Needs a gearshifter motion-sensor input. * '''Launch Control''' - Widely used feature to help the good start. On the startline, the driver needs to pull out the clutch, and press a button on the steering wheel. Then give a full throttle. The ECM must rev-limit (with ign+inj cutting) the engine on the configured limit, while the clutch is being pulled. Needs two input lines and 2 switches. (Note by hackish:) This can be accomplished without any extra hardware if you have VSS enabled. Check the vehicle speed sensor and if you're going less than X km/h enable the launch rev limit. * '''Launch Control Light''' - Almost the same as the standard launch control, but not as advanced. By adding a revlimit to the current ALS function, the user can choose between only a revlimiter (no/low boost off the line), or building up boost by changing ign.advance and adding more fuel. To enable, the clutchswitch has to be activated, and the launchcontrol is enabled with a second pushbutton, So that it doesn't activate the next time clutch-switch is activated. A separate boost-target could be set while this is activated as well. * '''EGT Based enrichment''' Powerful engines may need this, as they keep getting hotter with time. This would be a EGT vs enrichment % table, 3..8 cells, a unplugged/broken sensor should render full enrichment We should have a '''power-target sublayer''' that consolidates ** ALS ** launch-control and ** traction control ** idle-control all are some way of controlling power, with a combination of ** ignadv ** boost ** EGR ** fuelcut ** event-skipping, and ** direct idle-air-valve control. * '''ALS''' - AntiLagSystem. Needs an external switch (to control its on/off state), IAC control, EGT sensor, and a strong exhaust system. It's under development, using a simpler approach, without IAC and EGT. UNTESTED * '''High-resolution VE''' - Sometimes the 8x8 tables will be too rough to set the correct VE values (high-load charged engine under racing conditions) and should extended to 16x8 (8 kpa bin is '''always enough''', only incompetent tuners think otherwise (who do not understand the speed density approach or the linear interpolation). * '''Second serial connection''' - SV1: it would be nice to make AVR wake up so there is a menu listening on second UART. That will make 3 simultaneous accesses possible (currently 2 - without dispatching on the PC) and more importantly give people another chance to sort out comm problems (should the first channel have suspicion because of TX-TX abuse or whatever reason). '''We need to decide on default speed. I suggest 19200 or 38400'''. Should BootLoader also listen finally? (no free space in the upper 2kbyte at this moment). Find out how to notice a connected GPS module (so the GPS data can also be logged to MMC flash together with runtime data). GPS modules usually send out standard NMEA messages ($GPxxx) at least once/sec with 4800bps. * '''Connection authentication - security''' - A configurable password, to protect RS-232 communication interface against "unwanted" tuners. Before using megatunXX-like programs you must run a small password sender application. But a well-trained hacker can download the contents of the eeprom, so a realtime table encryptor/decryptor built-in into firmware would be nice. :) Randomization of table/config positions before compilation should be enough. ** changing the ''Man'' sequence (compile-time) seems very simple. ** that should be completely enough after we make the AVR not wake up in the MegaTune mode if password is configured. There is a fuse-flag in AVR that determines if EEPROM is erased at erase operation (or just the flash). IIRC value bit3=8 (0x81 .. 0x89) in ...fuse. With that fuse, and without menu, you only need to make the PS2 default to '''pre-password-entered-mode ''' to prevent access. You can waste any amount of time, but don't worry, they will just hook up a GenBoard (available in WebShop :-) to the outputs (of '''any ECM'''), log while the engine is running, and recover the tables. We do the same (see MembersPage/MichaelKristensen/MeasuringIgnitionAdvance) ** also want protection for BootLoader ? Shouldn't be needed, since BootLoader is not obligatory, and there is little room in the 2kbyte space anyway. * '''Two channels of working WBO2'''.We're building a race car, and it's needed to use 2 channels of WBO2. Could someone implement into the firmware that 2 WBO2 could be calibrated, used, and written the two lambda out to the LCD? *'''Programmable Injection timing'''. Like the motec does. We could give the injection timing angle (0-720 deg) from the TDC, at every RPM bins. When the injection firing ends. Is there a point to configure fixed beginning? From experts I hear that only the fixed ending makes sense (actually not much difference since the pulsewidth is also mainly determined by the loadsite).Fix beginning could be only an extra feature.But if we'll have only fix ending, that will be great too! ''fixed injection start angle is useless -Jörgen'' *'''More MAP bins'''. I'm working with a high boost race car nowadays, and I think more MAP bins are necessary for such high boost applications. Serious race cars works more then 2-2.5 bar boost, but that doesn't mean that more than 6..7 MAP bins are needed! candidates: * 12x12 (RPMxMAP) this is much '''worse than 16x8 we have now''', as strange intake (regardless of max boost) requires more RPM bins not MAP bins. Only a broken MAP sensor with highly nonlinear transfer-curve requires more MAP bins (but easier to use a working MAP sensor) * 16x12 (RPMxMAP) ... possible ... If the MAP bins are fixed you need (much) more bins, but with configurable MAP bins it is easy to start with 5..6 bins and add more if there is a serious break somewhere. VE or lambda tables should not have such breaks in the MAP direction in any case (max 1 break if injector opening is misconfigured). Only the ignadv has 2 breaks (for which 4 MAP bins are needed) the extra 4 bins can be used to smooth out all areas. To prevent stepup to 16 .. 32 .. 64 .. 99 million bins we should examine the exact table and find the problem and determine benefits numerically. ---- '''LCD Related''' Moved to GenBoard/UnderDevelopment/FirmWare/LcdRelated ---- '''INJECTOR_STAGING''' GenBoard/UnderDevelopment/StagedInjectors ---- '''Michael's browsing through the firmware''' '''TODO'S''' ---- How does bootloader handle inverted/noninverted igndriver? The trick is in ioinit.c: the initialization block is inside ''#if (defined __MEGASQUIRT_C__) || (! defined HARDWARE_PULLUP_OR_DOWN)'' So in the bootloader, the pins are left as input if HARDWARE_PULLUP_OR_DOWN is defined (so the PWM-ing SIL5 10k does it's pullup job). ---- refcard needs serious updating ---- '''outputs''' WOT_OUTPUT_TPS_THRESHOLD should be specified in config_t wot_output needs hysteresis miscX_activity needs hysteresis ---- '''menu.c:''' * 'mdh': m->tab is not used for a pointer (not dereferenced), but a simple 0..255 value (special purpose) in this case, see usage in menu_num_x. TODO: check if it is reset (eg. to j table) before any other menu (mtt !!) could act on it menu.c: * mcs: eeprom save variables runs asyncronously, thus lcd_init() will not show that the storing has completed. It can be just a visual feedback. ---- '''edis.c:''' for IGN_DUALOUT ch-1, ch==0 can cause problems, warn in the manual ---- '''fuelcalc.c:''' * primepulse: todo pwm-ing? config.warmup_rpm[] is a bit sick for 16x8 table. The idea was that at low RPM the config.warmup_clt[] '''multiplier''' could result in way too much fuel at high RPM. The RPM (r-array-table possibly 16 value!!!) selected config.warmup_rpm[] can downscale it (written <100 values). I propose a simple constant slope to downscale with increasing RPM. The other solution is to use '''additive quantity''', not multiplier, but that breaks megatune compatibility. I applied a small [http://www.vems.hu/files/Firmware/patches/corrwarmrail355.diff corrwarmrail355.diff patch] to make corr.warm (which is afterstart + warmup enrichment) rail at *3.55 instead of old *2.55. The [http://www.vems.hu/files/Firmware/prerelease/v3_firmware_2004-11-24_v6.zip has it applied]. Jorgen said his afterstart is higher than *2.55, Dave Brul's is railed at *2.55 and Marcell's engine seems to like more than *2.55 as well. It only matters for very small time as afterstart decays fast - but I think this railing at *2.55 prevented starting my engine in cold, when I refused to touch req_fuel or divider to hackstart it (after being confident in VE learned with warm engine earlier). storage.c: undovalue doesn't check if we are busy storing values to eeprom => can result in a long busy wait. Added return condition. See it again. '''BUG'S''' timing.c @ l526 secondary inj channels touches the last primary inj channel DONE fuelcalc.h @ l49 als reads port instead of pin ''This is important:'' Look in the mega128 datasheet page 63; Reading the PORT register...bad! Instead PINn register ''must'' be read: fixed now. ioinit.c @ l98 als should also init port value besides ddir DONE storage.c @ 78 m-tab in menu points to tables, not the structures, ex. m->tab = &ve.lambda not m->tab = &ve Modified, see it again. ---- even '''more sophisticated IdleControl including CruiseControl and ALS''' ---- '''atomic RS232 logging''' Done in wbo2.c (mates with wbo2log.pl) ---- '''verify calculated edgetime_corr coefficient''' The visual gnuplot-linreg is OK, you can log WideBandO2 data to RS232 and verify with ''linreg.pl'' ---- pri=6 MUST-do sg. like this for GenBoard v3.0: '''configurable with tables''' (vs. compiletime). * injector: DONE (see h-table: 8 bit mask limits to max 8 independent injector banks) * ignition: simple for direct ign for non overlapping dwell Each sequential output (like inj and ign) should be driven this way: * engine cycle (normally 720 crankdegree) is splitted to N (N=7..0) channels. It is possible that primary injection has 8 channels, while ign has some other number (eg. 4 with wasted spark) and secondary injection (eg. water) has 2 channels. * the channels (at least the 1st) are synchronized to InputTrigger * the channel number points to the h[2] table, so the firmware knows where to look up the channels * I checked the i259 initialization code when ign_out=71 (for the common ign_out=70 it's tested thoroughly). It looks good. It seems to me that the hardware RC reset on the i259 is applied for too long: the processor reset comes too early, so for inverted semantics the hardware reset takes precedence. ---- '''This stuff is DROPPED for now in favor of an even simpler, still powerful scheme''' old port_act stuff for the curious: that particular channel to * switchoff/gopwm/switchon (for inj) or * init/charge_coil/release_spark (for ign) * alltogether 8 port_acts in a table for every channel: 2/3/3 for the above portactsets (this makes it possible to use very primitive atomic portacts) * the looked-up 8-bit portacts can be executed simply. Eg. 00 and FF are nop. These should ideally be referred from configuration with symbolic names translated by perl - otherwise we'll run out of space in the future. ignconf.c and injconf.c should be dropped (even more complex :-) : * only port_act part remains (simple, as outlined above) * ''following-action'' functionality will go to the tables (next channel -> next line) * condition will go to the IC3 handler (simply step the channelnumber and reset after the number of configured channels is reached.) * dispatcher only gets a 1 byte val_t, in which the action is coded: bits 6:7 selects type of action: ign/injprimary/injsecondary/ ... /special, bits 4:5 the off/gopwm/on (inj) or init/on/off (for ign) bits 0:2 selects the channel 0..7 (bit 3 is future) We can first write a generic handler that will use the lower 3 bits to determine the channel (tableline), later it can be unrolled for faster execution. Packing the bits in a better way could help gcc optimize well after unrolling. In each dispatcher() call up to 3 port_acts can be executed depending on the relevant port_acts read out from the table (00 bails out earlier, FF not!) as the 3 consequtive values in the relevant port-act config table. ---- '''(EEPROM) Storage related''' As you know (storage.c) we have all tables and config (that live in EEPROM) mirrored in SRAM. Config and h-table must stay in sram (or flash), so it is always available, even during EEPROM writing! (since it is used all over the place, including interrupts). However, we'll have about 9 (!) 16*8 byte tables (it only took to change 2 constants - one VE_SIZE_RPM in firmware and $elements in make_tables.pl - to get 16 RPM bins, but it requires some more testing), which is not marginal. * it would be nice to read from EEPROM * only have dirty lines in SRAM * the fuelcalc can wait max a few msec if the EEPROM is being written (for some ECM saving configuration data requires engine off). EEPROM write should only be allowed to start (it takes 8.5 msec) if the fuelcalc is not needed within 9 msec. Doing it right after fuelcalc is perfect at high RPM; simplest algorithm is to do a storage, than a fuelcalc and so on (needlessly too many fuelcalc at low RPM). Later we will need sg. like a debug flag, that enables writing these tables. So in mtt mode they will not be accidentally overwritten (misconfiguration of ''h'' table would change the behaviour fundamentally, but why is that a problem? ). '''Suggested names tables:''' * h for hardware, currently 3*8 bytes GenBoard/Manual/Config/HwMap large 16x8 tables (16 in the RPM, 8 in the kPa direction): * l lambdacorr target (already there) for WideBandO2 closedloop and learning (8x8 should be enough) * j VE (reference) table (formerly dummy fake-VE of traditional megasquirt) * v VE (reference) table for secondary table * p precision learnt VE (should there be 2 tables, one for each banks?) this is currently 16 bit (but only 8*8) * n ignition max ignadv map * w ignition knock adjust window (8x8 should be enough) * i ignition knock learned adjust * g lo(g) of knock history (knockcounts per loadsite): 16 bits would be better small 1x16 tables: * r rpm bins * s staging transfer function (structure? maybe 1*8 enough ?) small 1x8 tables: * k kpa bins * q for j-channel inj req-fuel (1x8: separate for each channel as the injector-size varies...) * f for v-channel inj req-fuel similar as above check the following for menu conflicts: * v * s * g * i * w * p ---- A good collection of subroutines, eg. I2C: http://hubbard.engr.scu.edu/embedded/avr/avrlib/ We should contribute at least pid, softpwm and eventqueue. See also: LoggerIntegration ---- The 16x8 tables are a good idea. I've never run into a situation where I felt that I needed more than 8 KPA values. From a marketing standpoint however more is better. It is unfortunately a sorry state if marketing must dictate features. From a tuning standpoint it isn't all bad as sometimes more Kpa values would make for easier tuning rather than having to move existing points around whenever large changes in V/E are found. Case and point VE on variable valve timing motor depends on the switchover point. ---- TPSdot versus MAPdot. This is very setup dependant as the MAP will lag the TPS somewhat. I think both MAPdot and TPSdot should be implemented so the tuner can decide to use either or both. I have implemented it, now it has been in the firmware (MembersPage/Gabor) ---- A config parameter is needed for the max KPA given the installed MAP sensor. Since the signal input is generally 0-5v regardless of the range of the sensor the ECU only needs to know the real KPA value for display purposes. Since the injection is based as a ratio subject to the injector opening time and size it could care less if you're at 1 bar or 4 bar. But it would be nice for the LCD to show the right values. ---- I have more or less stolen a tps calibration setup: Pretty obvoious, allow engine.tps pull tps_low lower and tps_high higher. Let tps_low and tps_high=sensors[TPS] whenever commanded so via menu or for some special occasion (ignition on for 20 sec without starting?) The otherwise stupid (now it is legal!) tps_low >= tps_high could also trigger this. Or special values tps_low=FF and tps_high=00 ---- '''use the LSB bits of ADC''' For most ADC channels only the upper 8 bits are used. This is mostly OK, but why not use all 10, or 12 (MCP3208) or more (using filtering). Actually, for WBO2 Ri calculations we use 10 bits samples of the nernst input. For MAP we use 11 bits: in speed-density setup the VE value is multiplied with MAP. For a 2.5bar MAP sensor the readings (using only 8 bits) for 30 and 31 kpa would be appr. 30 and 31 (difference is 1 LSB) which is significant. With using 10 bits it becomes 120, 124 (4 LSBs), much nicer. I'm thinking of killing the ifndef WBO2 ADC setup, and tweaking the WBO2 ADC to work with non-WBO2. The sensor values must be accessed with getter functions get_sensor(x) (that can be inlined or macro-d), not like sensor[x]. (This will come very handy when the digital signal can come from other controllers later). Do we need the prev_sensor_reading[] array ? We can just do <code> // exponential decay: uint16_t t = get_sensor(x) + new_reading) >> 1; cli(); // needed on AVR because 16 bits set_sensor_value(x, t); sei(); </code> Note that the '''''getter'' should work the same way no matter the signal comes from a local internal ADC, MCP3208 or a combination of 2 signals (like cold-junction compensation signal of a K-Thermo comes from a different channel), or from network'''. We might want different getter-wrappers for different bitwidths (an 8 and a 16 bit getter, the 8 is needed so the upgrade is simpler, and 8 bit is actually enough at most places). ''should this be here?'' MCP3208 was not tested extensively before this. MCP3208 is the only useful chip from microchip (the CAN transceiver was dropped from the short list because it does not support talking to an uC 3.3V :-), we'll use MCP3208 a lot. The SPI software went smooth, it worked on first try. Small issue that I first read channel6 (to display output of ADC597AD on the top) because Microchip named stupidly 1..8 instead of 0..7, but it was trivial to fix (and read channel 5). Do we want to rename signals on schematic? Or just remember... '''Sampling freq''': We currently have 2 classes: * low priority (sampling every 8 .. 9 msec is perfect) * sampling a burst of one channel (for WBO2) once in a while (the other channels are not selected during this burst) We should finally have: * low priority (sampling every 10 .. 15 msec is perfect) * medium-priority (sampling every 5 .. 8 msec is perfect). This can be achieved with a sequence (maybe flash-defined) that has these medium-priority events multiple times. * sampling a burst of one (but it should be selectable!) channel (for WBO2) once in a while. Generic notify mechanism for observers (eg. the WBO2 calculations). Note that almost same would be used for uC-controlled hot-air-wire air-flow measurement. ---- '''can we kill the handler2k?''' * benefits: the number of read ADC samples (the main job of handler2k currently ifdef WBO2) cannot be decreased, but it can be done at a time when it is cheaper: when there is no conflict with scheduled events. * disadvantages * work amount any low priority maintenance task * that we can do from userspace, should go to userspace * that we cannot do from userspace (needs interrupt) should first check if there is an upcoming event scheduled. It would postpone its action for some time if there is, so not to delay the event execution at all. ---- '''do the timing from last possible tooth''' - AdvancedIgnition * trig2spark needs to be updated to give back the proposed engine.trigger_tooth and the (time or rpm_period) multiplier that need to be scheduled after it. * use engine.trigger_tooth that is coming from userspace instead of config.trigger_tooth * note: engine.trigger_tooth needs to be updated in a syncronized way (from dispatcher igndeact), such as the igncount that we got wrong last time :-) * possible to still schedule ignact (dwellstart) the very same way as now (from previous deact or some predetermined trigger). Optionally calculate another trigger tooth and delay from userspace (as trig2spark). ---- pri=2 * check if MegaTune can cause config corruption in the AVR * review comm.c compatibility layer I think megatunix is safe, anyone confirm this? yes. We couldn't reproduce the problem with the same genboard with another computer (and megatune). It seems the USB-RS232 converter caused the problem by making rare errors in the AVR => PC direction (bootloader was fine, although the bootloader moves very little info from AVR => PC : checksum only) ---- '''menu entries for testing Hardware''' - DONE * DONE: check the mdh.. command, it can set to hi or low anything that is possible via GenBoard/Manual/DigitalOut (look at digitalout.c for the codes to issue, 82 sets pin4 of i259 IIRC). * menu.c warning that "fire_dwell_2 broken!" is OK: since '''mxg menu entry''' not implemented for v3.x, but not needed, since: * DONE: scanning through outputs provides a nice testing method for an installer to check IGBTs, wiring, config: menu.c already has mdn, stepping to a specific item in h[2] table is possible this way: mdn03mdn02mdn01mdn00 will fire ''3, 2, 1, 0'' ignition outputs (actual outputs determined by the h[2] table), all ignchannels on a 4 cyl direct ignition or 8 cyl wasted spark. ** The igbt fires after the number is entered ** Note that the pulses are short, determined by engine.dwell * it might worth to consider making the ignition (selected by h[2] table-line) use GenBoard/Manual/DigitalOut facility, so that any signal (possibly low level signal) can be chosen for ignition. Care should be taken so the compiled asm is fast. Any advanced testing helper should go to the PC side (eg. one that steps through the outputs and activates one at a time). ---- '''Heap scaledown''' - DONE (TODO: merge this chapter to OnlineCourse/EventQueue) The dual-heap EventQueue supported scheduling to 262 msec far into the future. We decided to spare some SRAM, flash, complexity and processing time by killing the dual-heap implementation (for a simpler one). The dual heap implementation was used so '''comparison between 2 events is possible''', without the overflow screwing up result. Note that comparison with "etime.now" is not an issue: uint16_t diff = key - now; if(diff >>8) == 0xFF than the event must be executed ASAP. With a little trick (key is 1020 usec or 255 higher than real execution time) if(diff >>8) == 0 condition can be used (even faster). The problem with one heap is comparing 2 event-keys, the max difference between 2 event-keys must NOT be greater than 32767 (or 131 msec), otherwise the comparison would return bad result in some cases. 131 msec means that timing from an even-type trigger to 100 degrees (pretty extreme setup) would only work down to 127 RPM (not below). Fortunately this is fine (if not, it could be solved nicely of course). * kill heap_overflow heap (the heap_normal becomes direct dereference, faster) * kill heap_consume() * (maybe macro called "earlier") for comparing 2 event keys (times): (int16_t)(key1 - key2) < 0 * macro for comparing an event key with "etime.now" (see above) * change insert and other operations * ideally only eventqueue.c and heap.c is effected but timing.c must be examined, when it inserts the igndeact event (currently to max 262 msec). * dispatcher improvement: if 16 bit val_t <= 255 dispatcher uses a table of function pointers that live in flash. Take care: bits 4..7 hold the injector number for ifdef GENBOARDv3 * setalarm(): detect when event is close to handler2k and move away time handler2k a bit when needed. * tester: stim (msp.., mst..) improved so it has more precise (16 bit) period and keeps track when it should fire (DONE upto this point) * possibility to log detailed times (instead of the histogram) (NOT DONE) * userspace could take care of more distant events, entering them in the heap when necessary (NOT DONE). ---- '''Trigger scaledown''' trigger should consist of only the following actions: * capture time * store time in buffer for userspace (=> flag userspace) * update phase * check a simple condition if it needs to schedule an action * if needed, calculate when to schedule with a simple multiplication and addition * schedule the required action This depends on userspace preparing an execution plan, sg. like: ignition should be fired n degrees after p-th tooth: in interrupt this means very simple condition (maybe it could also check if trigger frequency did not change drastically, or something...) and very simple calculation. ---- '''Priority-based mainloop scheduler''' prio=4 I propose a simple userspace (mainloop) scheduler with 4 prio levels (queues): * all pending tasks from 1 * than first pending task from (2 or 3 or 4) Notes: * repeat this forever (of course) * the 2, 3 and 4 are round-robined inside (start to look from next one each time) but prioritized between queues: if the priority 2 queue has anything todo, anything in queue 3 or 4 will be neglected in that round. * all pending tasks are handled from 1 (so they are top priority) * tasks in 2 never starv * tasks in 3 or 4 can starve (theoretically - unlikely though if well written) * the N millisec handlers would be in queue 2, and they can have more than one subtasks (if the sum of execution times is low enough) * we could define that time is updated before each task is run, so the softelapsed() need not readTMR() for itself. It is also possible to have an eventqueue that is executed in userspace (instead of softelapsed), not interfering with interrupt execution (the heaproot would only be considered for execution when the mainloop thinks so). Caveats: * note that everything that uses the same eventqueue has essentially the same priority, while * LCD should live in a low(er than say comm) priority task anyway * many tasks simply cannot say in advance when they want to run next. (think: they don't know in advance when there will be bytes in the comm rcv buffer. Only when the bytes are there, will it know it got work). ---- '''Flexible analog output''' ( OC3C ) An analog output (maybe external GND referenced) should be easy to configure. Could be configured as MAP,'''WBO2''', NBO2, ignadv, injpw, RPM etc... This would allow * relatively fast, hackless diagnostics without LCD and notebook (only DVM and PS2 is needed). * more importantly it would allow proper logging with inferior (read: most) dyno-s. With many dyno-s the only way to identify log-sections is via logging external analog signal (besides hard paperwork of course). Eg. if one is tuning ignadv (setting fueling is fast with GenBoard/VerThree lambdatarget feature) he wants to know which power-log belongs to which ignadv setting. '''The WBO2 output is high priority at least''' Someone please make sure the most used curves are linked near from GenBoard/Manual/WBSensor''' ---- '''PRG_RDB and PRG_RDW fix''' If firmware does not compile with latest (past avr-libc-1.2.0) avr-libc, we must consider to change all PRG_RDW and PRG_RDB to pgm_read_word() and pgm_read_byte(). Probably somewhat better to make wrappers. We need wrapping eg. for PC anyway. Remember firmware is not avr-libc only. Going towards ARM and even running on OnlineCourse/PcEmulation. So wrapping is good. Eg. in global.h <code> // ---- change the related section to the section below this ---- #ifndef PRG_RDB #define PRG_RDB(x) pgm_read_byte(x) #endif #ifndef pgm_read_word #define pgm_read_word(a) ((PRG_RDB((unsigned char*)(a)) & 0x00FF) | ((PRG_RDB((unsigned char*)(a)+1))<<8)) #endif #ifndef pgm_read_word_near #define pgm_read_word_near(a) ((PRG_RDB((unsigned char*)(a)) & 0x00FF) | ((PRG_RDB((unsigned char*)(a)+1))<<8)) #endif #ifndef pgm_read_byte #define pgm_read_byte(a) (PRG_RDB((unsigned char*)(a))) #endif #ifndef PRG_RDW #define PRG_RDW(x) pgm_read_word(x) #endif // --- EOF latter libc macro fix ---- </code> The fix must be flexible and work for older avr-tools as well. (eg. many people use latest winavr). ---- '''Unified fuelcut''' * we have rev_limit fuelcut * overrun fuelcut and fuelresum overrun can be used to help race-start: Setting overrun fuelcut and fuelresume RPM to 3700 / 3400 RPM and applying a switchbutton that grounds the TPS signal. This way during race-start the rev is ideal for fast starting. (otherwise it is almost impossible to manually maintain the desired RPM with throttle and no load: the throttle is usually very touchy). The idle-air valve will close but who cares the throttle is opened anyway. Don't let the idle controller retard the ignition too much (a few degrees are OK). After starting, switchbutton released, TPS signal back to normal, so rev-limit is raised to redline. It would make sense to use a separate digital input channel (GenBoard/UnderDevelopment/DigitalInputs) instead of grounding the TPS signal: so 3 rev limits are possible. ||'''Condition'''||'''fuelcut RPM'''||'''fuelresume RPM'''|| ||if TPS < tps_thresh||overrun_fuelcut||overrun_fuelresume|| ||else if the racestart switch is ON||racestart_fuelcut||racestart_fuelcut - (overrun_fuelcut - overrun_fuelresume))|| ||in any case, if they are higher, they lowered to||rev_limit ||rev_limit - (overrun_fuelcut - overrun_fuelresume)|| * So if someone forgets to configure racestart_fuelcut the revline will save his engine. * Better name for racestart_fuelcut? * overrun_fuelcut - overrun_fuelresume should be 100..400 RPM (we can administratively maximize it to 800 RPM) and I see no reason to have different rangesize for the 3 cases
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.