docs/serial.imp.issues.txt

   1 Serial TODO
   2
   3 split location variable declarations out into own file.
   4 split some headers into more than one for different  inclusion purposes
   5 make file dependencies - chainable ? use same thing for message as action (only possible for single targets)
   6 main loop, disable timer isrs leaving only comms and enter loop with delay sending out errors - this gives possibility to use comms to load better data and reset without engine running at all
   7 ping packet?
   8 globals comments?
   9 address request packet?
  10 lower 256 codes are proto - maskable by checking upper byte is 0x00 - update comms spec and code to match
  11 8 GP buttons for testing purposes - mantis 87
  12 split files down to smaller chunks
  13 write functions for wrapping
  14 caveats document - easy to screw up by x, y, z, etc
  15 assumptions document - no small table access in isrs
  16 location id list - fill out with fixed conf stuff and copy to tuner json
  17 think about header types and return semantics and buffer location independence etc
  18 Look at IO control payload type
  19 Look at pointers for memory rearrangement
  20 Ditto, pointers for paged ram tables etc to make code more readable - not so sure now
  21 Check ALL isr code for refs to TableA - TableD : separate headers out to avoid this problem
  22 Work on hardware docs
  23 Further work on serial errors and debug packets etc
  24 Look at placement of vars in the structs and try to aim for 16 or 8 long structs. (for filtering)
  25 see if we can make the flash block location pointers constants in flash  const volatile
  26 see if const array of injector register locations will work now - may not have had rodata or similar back then...
  27 finish memory management doc
  28 data map docs
  29 update comms docs to match code and vice versa
  30 group functions that call each other a lot by page
  31 put things called from everywhere in text/text1 - break text into two chunks, one for stuff that must go there, and one for stuff that is faster if it goes there.
  32 minh special stack pointer return function so we can know if there is room for a flash burn buffer
  33 docs = error code as neg ack or independent error packet - best way??
  34 async errors mask for which to send and which to not send - based on counts or what?
  35 datalog mask(s?!) for which to send and which to not.
  36 debugs not sent counter and method send if the tx buffer is empty only logic
  37 always respond to packets - last line call to send routine, check inside for flag or something and if not set then send generic response packet back
  38
  39
  40 possibly switch to pointers for all small tables etc to enhance readability :
  41
  42 currently :
  43
  44 (twoDTableUS*)&TablesA.SmallTablesA.injectorDeadTimeTable
  45
  46 Could be
  47
  48 (twoDTableUS*)&(TablesA->injectorDeadTimeTable)
  49
  50 is the above redundant, ie, is the last part already a twodtableus pointer?
  51
  52 or even just
  53
  54 injectorDeadTimeTable
  55
  56 if it was just a pointer...
  57
  58
  59 not serial :
  60 5)  Look at configuration errors and see if they can be done a better way, ie without possibility for an error
  61 3)  Async errors and debugs should be done by saving the count each send period <user defined> and send a
  62     packet for each count with the appropriate code in it and perhaps a count difference or count total
  63     too. this could be masked in a similar way to that intended for logging packets.
  64 4)  Standardise the naming of error values, match their ordering to aid in 3)
  65 18) change calls to senderror to increments of counters to be sent via the central error sending function
  66
  67
  68
  69 trivial/unimportant :
  70 12) rawByte or rawValue not consistent
  71 13) packet/payload not consistent
  72 14) type/id not consistent
  73 17) later, refactor to use UART prefix such that flags for CAN can start with CAN and be obviously unambiguous
  74 xx) size/length
  75
  76
  77
  78
  79 Tuner thoughts :
  80
  81 aaron to make serial testing framework request/response config based so i can add them as i go and you can base your work on that.
  82 aarons test framework capable of behaving correctly for sm and ms too?
  83
  84
  85
  86 Hardware thoughts :
  87
  88 Bootloader PIN as fuel pump and protection activation source
  89
  90 during bootload the bootload pin is X during normal running without intervention it is Y
  91 X = fuel pump off via inversion pre driver if required
  92 X = ignition output disable via extra pin on ICs
  93 Y = fuel pump on and all other pins under control
  94 This is  no good as it is reversed for a brief period in between just when the ign pins are trying to spike on...
  95
  96 Can't drive A from a B pin as the state will be random when working.
  97
  98 Need independent pin for pump and disable use as discussed in thread.
  99
 100 investigate registers with non zero contents
 101 investigate the unknown pins and enter into pin out doc
 102 investigate the known high pins and find out why
 103 investigate the known high pins and see if we can tame them with resistors during reset/load.
 104 investigate loading effects on high pins.
 105 find free pin for fuel pump use
 106 choose chip(s) to isolate AND select ign outputs
 107 choose chip(s) to select inputs
 108
 109 select = XOR
 110 isolate = ???
 111 inputs : signal > filter/process > invert/noninvert > cpu
 112 ignition : cpu > isolation layer > invert/noninvert > drivers
 113 isolate/invert unit could be same part in -ve/+ve versions?
 114
 115 4077             = XNOR
 116 74hc86 / 74act86 = XOR
 117 75hc08/74hc01    = AND/NAND for isolation as it forces the output to a particular state when the other gate is powered/not powered
 118 74hc367          = tri state
 119 74hc125          = bus buffer
 120
 121 lm1815 goes ?? for tooth and ?? for gap?
 122
 123 to220 part for fuel pump relay drive = many relays controlled by this