VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
GenBoard/UnderDevelopment/FirmWare (2007-07-17 08:05:00)

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

'features could be mapped to product'' in ofbiz using product associations.

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.

Misc. smaller TODO items

Some User request for the GenBoard 2.2-3.0

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:

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).

Each sequential output (like inj and ign) should be driven this way:

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

ignconf.c and injconf.c should be dropped (even more complex :-) :

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.

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:

large 16x8 tables (16 in the RPM, 8 in the kPa direction):

small 1x16 tables:

small 1x8 tables:

check the following for menu conflicts:

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:

ADC related

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\n

// exponential decay:
uint16_t t = get_sensor(x) + new_reading) >> 1;
cli(); // needed on AVR because 16 bits
set_sensor_value(x, t);
sei();

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:

We should finally have:

can we kill the handler2k?

any low priority maintenance task

do the timing from last possible tooth - AdvancedIgnition

pri=2

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:

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

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