#    
         
   ##    
    #    
    #    
    #    
   ###   
         

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

         
|\     /|
( \   / )
 \ (_) / 
  \   /  
   ) (   
   | |   
   \_/   
         

 ______  
(  ___ \ 
| (   ) )
| (__/ / 
|  __ (  
| (  \ \ 
| )___) )
|/ \___/ 
         

 _____ 
|  __ \
| |  \/
| | __ 
| |_\ \
 \____/
       
       

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 in a new release, please write a note to GenBoard/UnderDevelopment/FirmwareChanges where the release happens'' Maybe we can separate tasks into the pick list and things people are working on? I've commented 2 tasks I'm working on so nobody else duplicates work. -Michael ------ '''Links - subpages''' * GenBoard/UnderDevelopment/FirmwareChanges/TestingAndReleases ** In the future we want first 2 number (of the revision: 1.1 1.2 .. 1.9 1.10 1.11 ... ) to be the "config" revision. The 3d number is for intermediate changes (MegaTune or firmware) that don't effect config. So anyone can easily know that 1.1.8 MegaTune should be compatible with 1.1.3 firmware. * GenBoard/UnderDevelopment/FirmWare/NextRelease specifies what tasks has to be done before we can create a new stable release * GenBoard/UnderDevelopment/FirmWare/LcdRelated '''LCD Related''' * GenBoard/UnderDevelopment/FirmWare/PowerRelated '''idle, ALS, launch and friends''' * GenBoard/UnderDevelopment/StagedInjectors '''INJECTOR_STAGING''' * GenBoard/UnderDevelopment/FirmWare/MiscOutputs * GenBoard/UnderDevelopment/DigitalInputs * GenBoard/UnderDevelopment/FirmWare/MenuRelated * GenBoard/UnderDevelopment/FirmWare/SyntaxRelated * GenBoard/UnderDevelopment/FirmWare/ConfigRelated ** GenBoard/UnderDevelopment/FirmWare/DynamicConfigRelated * GenBoard/UnderDevelopment/FirmWare/AirConditioner * GenBoard/UnderDevelopment/FirmWare/CoolantTemperatureRange * GenBoard/UnderDevelopment/FirmWare/GPSrelated * GenBoard/UnderDevelopment/FirmWare/TriggerRelated * OnlineCourse/Modeling/Scheduler * GenBoard/LoggerIntegration * GenBoard/UnderDevelopment/FirmWare/Settings discussion on how settings are retrieved and stored ---- ''' 'features'' could be mapped to ''product'' in ofbiz ''' using product associations. * feature name * short description * long description * priority * state (wishlist, designed, implemented, tested, well-tested) * test documents * responsible person(s) * implementation file(s) * other data ---- '''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. * IssueReports * pri=5 independent tach output is done, but the divider will be changed to allow precise tuning and tricks like 6cyl tacho gauge on 4..5 cyl engines * any mcp3208 input configurable for ALS / Launch input * 2nd WBO2 channel * for idle solenoid, if PWM period=0 configured, than we should revert to original extremely-fast softpwm behavior (instead of the nicely controlled period as now) * camsync and missing tooth-style multitooth (like 60-2) crankwheel for 4 cyl (working on 5 cyl, but not on 4 ;-) * pri=5 LoggerIntegration (MembersPage/RichardBarrington) * pri=6 overlapping dwell for direct ign (MembersPage/MarcellGal). * pri=7 ArmEfi (HW) * DROPPED: 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.) LSM11 curve is needed in table format (not unprecise drawing) * pri=5 DizzyBoard IonSense (MembersPage/KeithHargrove MembersPage/JörgenKarlsson) * 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 * pri=0 If using WBO2, NB02 output to fool vehicles own ecu. Maybe useful if original ecu still controls engine check lights, fuel consumption meter and so on? ---- Misc. '''smaller TODO items''' * generic logging functionality * svn revision stored in flash. We update firmware_revision.h like "1.0.18" (without reusing numbers for release candidates) so this should not be badly needed. SVN revision is simpler (like 1543) than CVS. Because SVN revision is ment for the tree, while CVS revision is ment for the files. * 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. * 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. * '''Two channels of working WBO2'''. For logging and LCD. ** it's not hard, just make sure the nernst samples are not repeated in SRAM. Now every WBO2_SAMPLING 's handler2k run, a nernst sampling is started. Every 10th msec. We want one every 5th msec, for the A and than for the B channel. The output variables need new SRAM space, but that's not much space. wbo2_sampling.nernst_sample_cnt MSB can show the actually used WBO2 channel. Basically jump from sampling one channel to the other very rapidly - from a resource standpoint of view * '''Use of both knock channels simultaneously''' * '''Use of BMW-type IAC valve''' as it's experimental at MembersPage/GergelyLezsak/IdleControl/Firmware ---- '''Michael's browsing through the firmware''' '''TODO'S''' ---- '''Ignition channel configuration''' 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). This has somewhat changed, since we always use the FETDRIVER_INVERTING. BootLoader pulls outputs high so real outputs are inactivated. For the ignition, we leave as the hardware reset leaves the ignition (off). Inverted ignition configured in software (ign_out=0x71) is not supported. Inverted ignition must be configured in HW. The '''h[2] configuration could be made more general''', there are 2 options: * like the h[0], allow more than one ignition channel to be fired simultaneously (without IGN_DUALOUT) * configure like other output channels in GenBoard/Manual/DigitalOut/Table (02 instead of 00, 32 instead of 03, 72 instead of 07, etc...) Both has some overhead, the second has marginal. As an extreme case, it could be configurable, which approach is used :-) ---- '''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 ---- '''TPS auto-calibration''' Allow engine.tps pull the (tps_low, tps_high) lower/higher. Trigger condition for reset (reset means let (tps_low, tps_high)=sensors[TPS],sensors[TPS]+1) could be: * dedicated menucomman * or special occasion (ignition on for 20 sec without starting?) * special values: tps_low=FF and tps_high=00 or tps_low=00 and tps_high=FF * '''my favorite:''' abs(tps_high-tps_low)==1 * Remember during implementation that tps_low >= tps_high is legal now, so direction must be preserved ---- '''ADC related''' * we have 10, or 12 (MCP3208) or more (using filtering) bits available * for most ADC channels the upper 8 bits are enough * WBO2 Ri calculations use 10 bits samples of the nernst input. * MAP calc uses 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). '''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) ---- '''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. ---- '''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''' ---- '''See also''' * A good collection of subroutines, eg. I2C: http://hubbard.engr.scu.edu/embedded/avr/avrlib/ We should probably contribute at least pid, softpwm and eventqueue.
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.