History of VemsFrontier/ArmEfi
Older Newer
2005-06-15 09:51:23 . . . . MembersPage/MarcellGal [nomenclature]
2005-06-12 06:40:14 . . . . MembersPage/MarcellGal [minor cleanup]
2005-06-12 06:23:28 . . . . MembersPage/AlexanderGuy [Reasoning behind interrupts.]
2005-06-12 06:13:47 . . . . MembersPage/MarcellGal [is 0,1,5,6,7 really possible ?]
2005-06-10 03:46:46 . . . . MembersPage/AlexanderGuy [Add my two cents on the trigger.]
2005-06-09 22:00:37 . . . . MembersPage/MarcellGal ["conversion sequencer" cannot do arbitrary order]
2005-06-09 20:13:27 . . . . MembersPage/MarcellGal [note about trigger to ADC]
2005-05-22 09:21:31 . . . . MembersPage/MarcellGal [SPI and MMC/SD. the way to pinmap]
2005-05-22 03:34:29 . . . . MembersPage/JörgenKarlsson [Unlocked r043_jk]
2005-05-22 02:09:45 . . . . MembersPage/JörgenKarlsson [Locked r043_jk]
2005-05-21 17:38:24 . . . . MembersPage/JörgenKarlsson [Locked r042_bm for brian]
2005-05-10 21:19:08 . . . . MembersPage/JörgenKarlsson [Counting pins, too many. Unlocked 040_kh]
2005-05-10 14:29:48 . . . . MembersPage/MarcellGal [updates]
2005-05-10 13:57:27 . . . . MembersPage/JörgenKarlsson [Updated pinout]
2005-05-09 14:32:17 . . . . MembersPage/MarcellGal [note about CAN transceiver location]
2005-05-06 16:49:19 . . . . KeithHagrrove
2005-05-06 00:11:24 . . . . KeithHagrrove [unlocking]
2005-05-02 21:12:09 . . . . MembersPage/JörgenKarlsson
2005-05-02 08:55:28 . . . . MembersPage/MarcellGal [ignition module very similar to armefi in many aspects]
2005-05-01 09:43:28 . . . . MembersPage/MarcellGal [important changes to ArmEfi. RS485 and DIP stepper drivers]
2005-04-14 22:42:41 . . . . MembersPage/JörgenKarlsson [Unlocked r036]
2005-04-01 00:00:49 . . . . MembersPage/JörgenKarlsson [Unlocked r035_jk]
2005-03-06 07:24:27 . . . . MembersPage/JorgenKarlsson [Unlocked r034_jk and added todo's]


Changes by last author:

Changed:
This is the primary fuel injection system, not as fully featured as the V3 but smaller and able to communicate with the other VEMSFrontier boards
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

Changed:
Trigger is also directly connected to an ADC channel. 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) 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 will be connected to 2 channels (eg ch0 and ch4 of the same ADC block) but we have to check again.

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.

Changed:
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 ). What suggests that 0, 1, 5, 6, 7 is possible? if so, why is 0,1,2,3,4,0,1,5,6,7 not possible?
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.
Changed:
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.
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.
Changed:
ECIII 36 pin mapping:
ECIII 36 pin mapping: - for armufo