For your time critical paths you are almost certainly have to use PASM or non-interpreted code of some sort; Spin on it's own might be able to do 600 rpm max. To define and implement methodology you need to know what you need - an ECU program has a lot of small parts - see http://www.scribd.com/doc/94992958/Flowchart-Mega-Squirt#scribd for an overview of the Megasquirt ECU. Things that are ISR driven in the interrupt driven processors have to be placed into their own cog and signalled when to run in the Prop case, i.e., injection and spark events,wheel decoding and angle clock generation are the main gotta-be-fast routines. A lot of the other stuff, lookup tables, ADC data acquisition, serial interface, etc., is ably handled by Spin. Keeping things tight and efficient is mandatory as you don't have a lot of memory to operate in. PropBASIC is excellent for learning PASM when you need to see an example of how something is done in PASM. For example, write a couple lines of PB, compile it and then examine the PASM it generates, which has the corresponding source as comments.For example, here's PB generated PASM examples of a loop, a multiply and a copy of a cog var to a hub var array and a few other basic things like declaring variables all from less than a dozen lines of PB source:
'======================================================================
' ----------------------------------------------------------------------
' Device Settings
' ----------------------------------------------------------------------
DEVICE P8X32A, XTAL1, PLL16X
XIN 6250000
x var long (16)
y var long
x_hub hub long
Program Start
do
for x = 0 to 15
y = x * 16
wrlong x_hub(x), y
next'
generates:
'' *** COMPILED WITH PropBasic VERSION 00.01.42 Aug 25, 2013 ***
'' ----------------------------------------------------------------------
'' Device Settings
'' ----------------------------------------------------------------------
CON 'DEVICE P8X32A, XTAL1, PLL16X
_ClkMode = XTAL1 + PLL16X
_XInFreq = 6250000 'XIN 6250000
' x var long (16) 'x var long (16)
' y var long 'y var long
' HUB LONG x_hub 'x_hub hub long
PUB __Program | __VarsPtr 'Program Start
__VarsPtr := 0
CogInit(0, @__Init, __VarsPtr)
DAT
org 0
__Init
__RAM
mov dira,__InitDirA
mov outa,__InitOutA
jmp #Start
__DO_1 'do
mov x,#0 ' for x = 0 to 15
__FOR_x_1
mov y,x ' y = x * 16
shl y,#4
mov __temp1,x ' wrlong x_hub(x), y
shl __temp1,#2
add __temp1,__x_hub_adr
wrlong y,__temp1
adds x,#1 ' next
cmps x,#15 WZ, WC
IF_BE jmp #__FOR_x_1
__NEXT_x_1
jmp #__DO_1 'loop
__LOOP_1
'**********************************************************************
__InitDirA LONG %00000000_00000000_00000000_00000000
__InitOutA LONG %00000000_00000000_00000000_00000000
_FREQ LONG 100000000
____STRING_adr LONG 0
__clkfreq_adr LONG 0
__x_hub_adr LONG @@@x_hub
__remainder
__temp1 RES 1
__temp2 RES 1
__temp3 RES 1
__temp4 RES 1
__temp5 RES 1
__param1 RES 1
__param2 RES 1
__param3 RES 1
__param4 RES 1
__paramcnt RES 1
x RES 16
y RES 1
FIT 492
CON
LSBFIRST = 0
MSBFIRST = 1
MSBPRE = 0
LSBPRE = 1
MSBPOST = 2
LSBPOST = 3
DAT
__DATASTART
x_hub LONG 0
Is there a cool way to organize a lookup table in this way: If value is between A and B then use this lookup data, if value is between B and C then use this lookup data, etc.?
I know one could use a bunch of conditionals, if value is greater than A and less then B then use this data, but it didnt look time efficient.I saw your example above as using probasic to learn pasm, cool Idea. I found the download. Im going to try it out.
Is there a cool way to organize a lookup table in this way: If value is between A and B then use this lookup data, if value is between B and C then use this lookup data, etc.?
Seriously though this is a bit like how ISAM (Indexed Sequential Access Method) searched a database. See https://en.wikipedia.org/wiki/ISAM for an explanation. It may be overkill for what you need.
A time T is a measured camshaft period in clock ticks, and I need the associated TD to plug into a waitcnt. I don't know a cool way to categorize T and index it. A T will come, it will need to be compared to the list of recognized T values, so the associated TD can be found.
Is there a cool way to organize a lookup table in this way: If value is between A and B then use this lookup data, if value is between B and C then use this lookup data, etc.?
Bilinear interpolation works well for that purpose. You don't need a huge lookup table with that and it runs fairly fast - faster than your inputs can change! I'ts usually used in image processing but has many other applications. I have working code in C, PropBasic and somewhere, Spin. Interpolating both fuel and ign tables in a loop runs at >5 KHz and, both in PB and C, just barely fits solely into cog ram in both (C using fcache) ,accounting for the seriously nice speed.
Edit/Addendum: You only need very simple linear interpolation (https://en.wikipedia.org/wiki/Linear_interpolation) if you're only using RPM as an input variable. Load as another input is very nice though, that has just as big an impact on calculating proper advance as rpm does. Load can be quantified by measuring throttle plate angle, manifold pressure or mass air flow.
Comments
An easy to understand programming language that results in the least amount of clock cycles required (aka: power), to me is a good thing.
Say each element of the lookup is a byte. Weave the two together:
lookup: A1, B1, A2, B2, A3, B3....
Then you shift the index one bit, to multiply by 2, then add one conditionally to get at the right set of lookup values.
Or...
lookup: A1, A2, A3, A4...
lookiup: B1, B2, B3...
If they are a similar length, or the same length, then just add an offset conditionally to the array index.
How about a lookup table lookup table. AKA LUT^2
Edit/Addendum: You only need very simple linear interpolation (https://en.wikipedia.org/wiki/Linear_interpolation) if you're only using RPM as an input variable. Load as another input is very nice though, that has just as big an impact on calculating proper advance as rpm does. Load can be quantified by measuring throttle plate angle, manifold pressure or mass air flow.