105 Initialisation / Configuration block always 2009-10-15 21:58 2009-10-19 07:10 Fred Fred normal closed 0.0.20 pre-release none none fixed 0 Table data appears to be wrong! The main VE table whichc is being both read by the math code and sent to the tuner via serial appears to have random data in it instead of the correct flat 50% VE valules as per the compile time defaults. This is screwing up both Aaron and I as we try to make sense of it and use it for actual computations etc.
Fred 2009-10-15 22:38 Confirmed to be correct in the S19 file! The issue almost certainly lies with the init flash > ram code, I'll check it out tonight away from the box :-/
Fred 2009-10-19 07:09 Confirmed fixed!
Fred 2009-10-19 07:10 Found init code issue and fixed. Tested by Cam.
84 Firmware Protocol feature N/A 2008-12-03 00:15 2009-09-02 21:32 Fred BenFenner normal closed none none duplicate 0 Basic datalog request button payload id :

#define requestBasicDatalog 300

the payload can either be empty or 2 bytes made up of one unsigned short.

if empty, the configured length is used (currently max by default)
if populated, controls the length of the datalog to be sent. The maximum length is defined per release of the firmware, currently it is as per the datalog display mantis issue.

i'd like to be able to send both types, so a check box saying send length, and a field to enter the length in that is not used if the check box is not checked should suffice.
68 Features Requests feature N/A 2008-11-23 21:15 2009-02-15 08:32 BenFenner sry_not4sale normal closed none none fixed 0 Memory block request tab Create a new tab. Give it a drop down of the 29 blocks of memory with names and numbers. Give it a drop down of 2 types of payload id and a send button. Fred can use it to request all the blocks of memory back and test his serial code.
Fred 2008-11-23 21:37 Memory block IDs :

/* Fueling blocks */
#define VETableMainFlashLocationID 0
#define VETableMainFlash2LocationID 1
#define VETableSecondaryFlashLocationID 2
#define VETableSecondaryFlash2LocationID 3
#define VETableTertiaryFlashLocationID 4
#define VETableTertiaryFlash2LocationID 5
#define LambdaTableFlashLocationID 6
#define LambdaTableFlash2LocationID 7
/* Timing blocks */
#define IgnitionAdvanceTableMainFlashLocationID 8
#define IgnitionAdvanceTableMainFlash2LocationID 9
#define IgnitionAdvanceTableSecondaryFlashLocationID 10
#define IgnitionAdvanceTableSecondaryFlash2LocationID 11
#define InjectionAdvanceTableMainFlashLocationID 12
#define InjectionAdvanceTableMainFlash2LocationID 13
#define InjectionAdvanceTableSecondaryFlashLocationID 14
#define InjectionAdvanceTableSecondaryFlash2LocationID 15
/* Tuable blocks */
#define SmallTablesAFlashLocationID 16
#define SmallTablesAFlash2LocationID 17
#define SmallTablesBFlashLocationID 18
#define SmallTablesBFlash2LocationID 19
#define SmallTablesCFlashLocationID 20
#define SmallTablesCFlash2LocationID 21
#define SmallTablesDFlashLocationID 22
#define SmallTablesDFlash2LocationID 23
/* Flash ONLY blocks */
#define FixedConfigLocationID 24
#define FixedConfig2LocationID 25
#define IATTransferTableLocationID 26 /* 2k */
#define CHTTransferTableLocationID 27 /* 2k */
#define MAFTransferTableLocationID 28 /* 2k */
Fred 2008-11-23 21:39 Payload IDs :

/* Whole block manipulation */
#define replaceBlockInRAM 0
#define replaceBlockInFlash 2
#define retrieveBlockFromRAM 4
#define retrieveBlockFromFlash 6
#define burnBlockFromRamToFlash 8

you should implement the last 3 as they are all easy :-)

The other two require having the data (in human format of a table) and packaging it up to send... which probably requires parsing the data returned by the two retrieve types.
sry_not4sale 2008-11-28 08:01 Json list of memory locations please Fred :)
Fred 2008-11-28 14:14 Nahh, I just hacked the python again ;-)

Do you want to give a short eg file or trust me to write something reasonable?

I already did one, but it's in my EEE.

Will get it to you ASAP.
Fred 2008-12-03 00:06 I've been using it, works well :-)
77 Comm Interface feature N/A 2008-11-29 21:01 2009-02-15 08:25 Fred sry_not4sale normal closed none none fixed 0 Move serial comms low level stuff into SOA style thread setup I think this will enable you to debug it a little better and keep the gui responsive. Currently I click on the buttons repeatedly quickly and it can't keep up because it is working on the last click at a low level.

To do this effectively you'll need some sort of queueing system where by a packet to send gets placed in a queue FIFO style, and the same for returned packets from the device.

I haven't tried to look at what you are doing, but the following pseudo code should be more or less how the serial stuff works :


* look for start byte :
ignore all other bytes until a start is found. perhaps cache the other bytes so you can dump them as an array in the log after finding the start byte with a specific message such as "junk before start byte : <junk>"
* move all bytes into a raw buffer to examine for debugging.
* move non escape/stop bytes into buffer to be processed :
when an escape byte is found do not buffer it, rather set a flag to unescape the next byte before moving it to the buffer and drop this byte.
* when a stop byte is found check the last byte received against the checksum of all bytes before that as per the spec. move from the buffer to a raw object and add to queue
*repeat

no data should be lost, and it should all be processed sequentially.

if you can achieve the same logic with searches etc, by all means, but it might be better to KISS to start with?

Lastly, except moving it to a thread, feel free to ignore all this provided that it works :-)
sry_not4sale 2009-01-13 21:40 Send, receive and comms logic now moved to individual threads
75 User Interface minor always 2008-11-28 00:50 2009-02-15 08:24 Fred sry_not4sale normal closed none none fixed 0 Fails to display hex for large packet Traceback (most recent call last):
  File "/home/fred/tuner/gui/__init__.py", line 138, in OnIdle
    self.CommsReceive()
  File "/home/fred/tuner/gui/__init__.py", line 322, in CommsReceive
    comms.getConnection().recieve()
  File "/home/fred/tuner/comms/Serial.py", line 181, in recieve
    watcher(packet)
  File "/home/fred/tuner/gui/commsDiagnostics.py", line 86, in printRecievedPacket
    self.insertRow(response)
  File "/home/fred/tuner/gui/commsDiagnostics.py", line 104, in insertRow
    self.SetCellValue(self.row, 3, payload_hex_hum)
  File "/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/grid.py", line 1971, in SetCellValue
    return _grid.Grid_SetCellValue(*args, **kwargs)
  File "/usr/lib/python2.5/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 66: unexpected code byte
 Changes I made over what Aaron gave me to get this far :

fred@rwdlsd:~/tuner$ git diff
diff --git a/protocols/FreeEMS_Vanilla/0_1.py b/protocols/FreeEMS_Vanilla/0_1.py
index 2d8e758..9d36255 100644
--- a/protocols/FreeEMS_Vanilla/0_1.py
+++ b/protocols/FreeEMS_Vanilla/0_1.py
@@ -158,7 +158,7 @@ class protocol:
         'FixedConfig2LocationID 25',
         'IATTransferTableLocationID 26',
         'CHTTransferTableLocationID 27',
- 'MAFTransferTableLocationID 28',
+ 'MAFTransferTableLocationID 128',
         ]
 
     _memory_request_payload_ids = [
@@ -710,7 +710,7 @@ class protocol:
             self._validation_rules = {
                 'preset_payload_length': False,
                 'requires_length': False,
- 'firmware_type': False,
+ 'firmware_type': True,
             }
 
 
@@ -720,10 +720,10 @@ class protocol:
             rules = self._validation_rules
             pid = self.getPayloadIdInt()
 
- if rules['preset_payload_length']:
+ # if rules['preset_payload_length']:
                 # Check payload is the required length
- if rules['preset_payload_length'] != self.getPayloadLengthInt():
- raise Exception, 'Packet type %d preset length of %s does not match the actual payload length of %s' % (pid, rules['preset_payload_length'], self.getPayloadLengthIn
+ # if rules['preset_payload_length'] != self.getPayloadLengthInt():
+ # raise Exception, 'Packet type %d preset length of %s does not match the actual payload length of %s' % (pid, rules['preset_payload_length'], self.getPayloadLengthI
             
             if rules['requires_length']:
                 # Check a length was supplied and the payload matches
sry_not4sale 2009-01-13 21:55 Was escaping related, fixed
Fred 2009-01-14 05:42 Tested fixed.
10 Structure / Style minor N/A 2008-10-29 16:28 2009-01-02 14:57 Fred Fred low closed none none fixed 0 Document And Standardise Upon Coding Conventions Currently the coding style is only consistent within modules. Inter module it has some inconsistencies that aren't serious, but should be fixed.

We need to define formal coding conventions and then format all the code and adjust all the variables to be in line with that style.

Some examples of things that need to be defined are :

* Case, upper, lower, camel, leading upper on camel or not, etc. This needs to be done for each class of identifier. eg defined constants, const constants, local vars, global vars, function names, etc
* tabs/spaces/length of tabs, locations of braces, spaces between if( or if ( blank lines between block of code, etc
* file naming conventions similar to identifiers
* comments, size, type, location, chars to EOL etc
* GNU GPL header MUST be in place before release
* Some specific prefixes standardised upon for identifiers related to certain modules etc
* header structure standard - needs to be defined, see related task
* where multiple terms exist for a single thing, define which to use

Probably other things, suggestions on the above and additional things most welcome.
Fred 2009-01-02 14:57 This is now part of the source and a work in progress. It will be an on going thing to keep the guide reasonable and up to date and keep the source inline with that.
96 Documentation minor N/A 2008-12-25 22:42 2009-01-02 10:01 Fred Fred normal closed none none fixed 0 Add configuration and setup for index page to code base If you could at least give me a template config file and template index setup file I can improve them as required. You have two weeks :-) (if you want to... if not, assign to me and I'll do it)

I'll be working on making the comments compatible as per mantis 95.
Fred 2009-01-02 10:01 This is complete and available from the git repo right now.
94 General Features minor always 2008-12-22 22:01 2008-12-22 22:02 Fred Fred normal closed none none fixed 0 duplication in itoa functions itoa functions have duplicated code as do send unsigned functions
Fred 2008-12-22 22:02 Added for historical purposes.
93 Ignition / Injection Scheduler minor always 2008-12-22 22:00 2008-12-22 22:00 Fred Fred normal closed none none fixed 0 No test at run time for always on Forgot to add code run time to test for always on in new code layout.
Fred 2008-12-22 22:00 Added for historical purposes.
92 Injection / Ignition Calculations minor have not tried 2008-12-22 21:57 2008-12-22 21:58 Fred Fred normal closed none none fixed 0 Code attempting to predict future... The logic for injectors staying hard on relied on predicting the future, clearly that was no good :-)
Fred 2008-12-22 21:58 Added for historical purposes.
91 Ignition / Injection Scheduler minor always 2008-12-22 21:55 2008-12-22 21:55 Fred Fred normal closed none none fixed 0 Logic that causes the injectors to stay hard not taking advance into account. The logic that causes the injectors to stay hard on is not taking advance into account. This is causing the step from requested pulsewidth to be "advance" large, so if pulse width increases from 10ms to 20ms and advance is 10ms, and the period of the whole cycle is 25ms, you will get a step from 15ms to 25ms/100% duty when the end of the pulse hits the point where the thing is scheduled from.
Fred 2008-12-22 21:55 Added for historical purposes.
90 Injection / Ignition Calculations minor always 2008-12-22 21:52 2008-12-22 21:54 Fred Fred normal closed none none fixed 0 Engine cycle period used before valid Found and fixed bug present in 0.0.10 and probably earlier where engine cycle period was being used before it was valid.
Fred 2008-12-22 21:54 Added for historical purposes.
89 Ignition / Injection Scheduler minor always 2008-12-22 21:46 2008-12-22 21:47 Fred Fred normal closed none none fixed 0 PORTA and PORTB get written to randomly after the program runs for some time. PORTA and PORTB get written to randomly after the program runs for some time. This is likely to do with pointers and arrays and what have you, but I haven't had a chance to track it down yet.
Fred 2008-12-22 21:47 Added for historical purposes.
52 Analog Input Config & Processing major N/A 2008-11-15 13:49 2008-12-18 13:01 Fred Fred high closed none none 0.0.17-SpudEchoes fixed 0 Investigate Using Pointers For Variable Banking Currently I'm using a scheme with structs of 2 long arrays to have a banked variable system. This is working very well at the moment, however for getting the data out of the EMS it will be slow and overly complex (iterating through the array copying one byte/short at a time and incrementing by 2 instead of just taking the whole lot in one go. Additionally, I believe it is slower to look them up with the current syntax :

struct.array[bank]

Rather than the suggested :

struct.var

I'm not sure what issues there are with either approach into the future, but this is here to make sure I find out and change it all to the best type.
Fred 2008-12-18 13:01 I've performed this refactoring. About 150 lines were affected. From a total code size of 16k binary, it saved 500 bytes! The code looks a LOT cleaner! And the code should be faster, significantly!
73 Firmware Protocol minor always 2008-11-28 00:22 2008-12-03 00:04 Fred sry_not4sale normal closed none none fixed 0 received packets ignored due to not handling header bit firmware packets received are treated as bad protocol packets.
sry_not4sale 2008-11-28 07:56 Fixed in commit 6dc01ac90d7d38a1cb4ffa89aca6a74624cd4ca0
Fred 2008-11-29 19:49 Sorry, still broken :

2008-11-30 08:57:52,048 DEBUG comms.Serial - Packet sent over Serial connection: ['0xAA', '0x10', '0x00', '0x04', '0x00', '0x02', '0x00', '0x00', '0x16', '0xCC']
2008-11-30 08:57:54,286 ERROR comms.Serial - Packet type 5 requires the protocol flag is set
2008-11-30 08:57:54,289 ERROR comms.Serial - processRecieveBuffer failed to parse packet from buffer: [170, 0, 0, 5, 0, 0, 0, 27, 0, 21, 1, 206, 0, 24, 0, 19, 0, 0, 0, 200, 2, 188, 4, 26, 5, 120, 6, 214, 8, 52, 9, 146, 10, 240, 12, 78, 13, 172, 15, 10, 16, 104, 17, 198, 19, 36, 20, 130, 21, 224, 23, 62, 24, 156, 25, 250, 27, 88, 28, 182, 30, 20, 31, 114, 32, 208, 34, 46, 35, 140, 6, 64, 12, 128, 18, 192, 25, 0, 31, 64, 37, 128, 43, 192, 50, 0, 56, 64, 62, 128, 68, 192, 75, 0, 81, 64, 87, 128, 93, 192, 100, 0, 106, 64, 112, 128, 118, 192, 125, 0, 131, 64, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 255, 255, 103, 204]
Fred 2008-11-30 13:40 I had another thought about this :

"Packet type 5 requires the protocol flag is set"

This implies that you are checking things in the wrong order. It should read

"Packet type 5 not found in firmware packet list, logging unknown packet data."

or similar.

IE, you should first check that flag, then look through the particular list of IDs to see what to do with it. The other way can't work.

Perhaps the message is just a poor one for what the code is doing?
Fred 2008-11-30 21:51 2008-12-01 10:56:28,997 ERROR comms.Serial - Packet type 301 requires the protocol flag is set

LOL, strange indeed :-)
sry_not4sale 2008-12-01 01:17 Two more commits that should fix this:
315ab41edd344850d52297a298bbd1871c291a34
b885669ad9bfd7572e24d148d2bcd4036e5fcb1f
Fred 2008-12-03 00:04 really fixed this time :-)
74 Comm Interface minor always 2008-11-28 00:25 2008-12-03 00:03 Fred sry_not4sale normal closed none none fixed 0 Tuner reports that ALL bytes in a long packet are escaped wrongly This COULD be my code sending junk, or it could be yours with a bug. It's not possible to tell right now due to no logging of context around the offending byte.

If you had 2 in front of and one after that byte you could prove it wrong or right.

If you think it is in my code, reject this and open a new one against me.		 app.log.zip (16 KB) 2008-11-30 00:59
Fred 2008-11-28 01:44 2008-11-28 14:51:08,544 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: CC
2008-11-28 14:48:42,201 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: 38

Nearly 2.5 minutes at 100% CPU with the GUI frozen, just printing logs. Obviously this will be infrequent once the bugs are gone, so performance shouldn't be an issue.
Fred 2008-11-29 19:51 Received two packets tonight, should have been identical, probably were, one came through (not recognised, but came none the less) and the other did the massive error dump stalling the gui completely for 2.5 mins :-)

Pretty sure it's not in my code, but could be wrong.
Fred 2008-11-29 20:48 Bingo, this is definitely related, the 1k packets are visually longer on periods for the LED on the serial adapter. Thus you can tell roughly how many bytes you are getting. There are definitely way way way more bytes than shown here being delivered to the tuner. This shows one good packet, and the same packet being shown as 3 bad bytes repeatedly. This is not the truth. I hope it helps. If I had a clue about python I'd have a look at it, but I don't.

2008-11-30 09:36:59,334 DEBUG comms.Serial - Packet sent over Serial connection: ['0xAA', '0x10', '0x00', '0x06', '0x00', '0x02', '0x00', '0x02', '0x1A', '0xCC']
2008-11-30 09:36:59,707 ERROR comms.Serial - Packet type 7 requires the protocol flag is set
2008-11-30 09:36:59,718 ERROR comms.Serial - processRecieveBuffer failed to parse packet from buffer: [170, 0, 0, 7, 0, 2, 0, 27, 0, 21, 1, 206, 0, 24, 0, 19, 0, 0, 0, 200, 2, 188, 4, 26, 5, 120, 6, 214, 8, 52, 9, 146, 10, 240, 12, 78, 13, 172, 15, 10, 16, 104, 17, 198, 19, 36, 20, 130, 21, 224, 23, 62, 24, 156, 25, 250, 27, 88, 28, 182, 30, 20, 31, 114, 32, 208, 34, 46, 35, 140, 6, 64, 12, 128, 18, 192, 25, 0, 31, 64, 37, 128, 43, 192, 50, 0, 56, 64, 62, 128, 68, 192, 75, 0, 81, 64, 87, 128, 93, 192, 100, 0, 106, 64, 112, 128, 118, 192, 125, 0, 131, 64, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 192, 0, 238, 238, 73, 204]
2008-11-30 09:37:02,669 DEBUG comms.Serial - Packet sent over Serial connection: ['0xAA', '0x10', '0x00', '0x06', '0x00', '0x02', '0x00', '0x01', '0x19', '0xCC']
2008-11-30 09:37:03,087 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: BB
2008-11-30 09:37:03,099 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: 4
2008-11-30 09:37:03,114 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: CC
2008-11-30 09:37:03,885 DEBUG comms.Serial - Packet sent over Serial connection: ['0xAA', '0x10', '0x00', '0x06', '0x00', '0x02', '0x00', '0x01', '0x19', '0xCC']
2008-11-30 09:37:04,298 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: BB
2008-11-30 09:37:04,309 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: 4
2008-11-30 09:37:04,325 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: CC
2008-11-30 09:37:04,739 DEBUG comms.Serial - Packet sent over Serial connection: ['0xAA', '0x10', '0x00', '0x06', '0x00', '0x02', '0x00', '0x01', '0x19', '0xCC']
2008-11-30 09:37:05,157 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: BB
2008-11-30 09:37:05,172 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: 4
2008-11-30 09:37:05,216 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: CC
2008-11-30 09:37:05,589 DEBUG comms.Serial - Packet sent over Serial connection: ['0xAA', '0x10', '0x00', '0x06', '0x00', '0x02', '0x00', '0x01', '0x19', '0xCC']
2008-11-30 09:37:05,786 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: BB
2008-11-30 09:37:05,791 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: 4
2008-11-30 09:37:05,797 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: CC
2008-11-30 09:37:06,516 DEBUG comms.Serial - Packet sent over Serial connection: ['0xAA', '0x10', '0x00', '0x06', '0x00', '0x02', '0x00', '0x01', '0x19', '0xCC']
2008-11-30 09:37:06,713 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: BB
2008-11-30 09:37:06,718 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: 4
2008-11-30 09:37:06,726 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in buffer: CC
Fred 2008-11-30 00:55 About to attach a specially generated log file showing exactly what the problem is :-)

The messages start flooding immediately after finding a start byte. Additionally, the escaped bytes arent displayed, instead the escape byte is displayed in their place.

Your special byte handling needs work, maybe other things too, but that is certain now :-)

I setup code with 8 sets of 0 - 0xff in a row in a big array. you can clearly see the pattern starts immediately after the 0xaa and then when aa bb or cc should be present, the bb is displayed instead.

should be easy to find now.

Fred.
Fred 2008-11-30 01:01 seems like you are unescaping before looking for a start byte? also seems like the escaping is backwards, ie, the escape byte ends up in data, and the escaped byte is lost. havent looked at the code yet though. probably won't be. i'll be documenting the firmware for the release instead.
Fred 2008-11-30 14:00 This may help too :

I know python is interpreted, but I refuse to believe that it is so slow as to take 2.5 minutes to dump out 2048 bytes to a log file. I think what it must be doing is iterating through the whole array at least once each byte looking for something (christ knows what lol). I think a byte by byte approach as on the 40mhz core could work efficiently enough, esp considering most machines are about 20 times faster than that ;-)
sry_not4sale 2008-12-01 02:56 Fixed
Fred 2008-12-03 00:03 this is no longer an issue.
5 Flash Burning minor always 2008-10-29 11:19 2008-11-26 22:48 Fred sean94z high closed none none 0.0.16-FlashGordon fixed 0 Function writeAlignedBlock does not write the data I just attempted to burn a block of code to another block of flash using the new two way serial comms and found it did not work.

The dumps from before and after show that the first page of visible flash at 0x4000 is erased (rather than the page at 0x8000 as instructed).

I had a quick look at the source and the first thing that stands out is that the pointer is an unsigned short* type and you are incrementing it by 2 each time. I believe that when you increment a pointer it increments in chunks of the size it is, so ++ or += 1 mean 2 in the case of a short. I could be wrong though, but it would pay to check that.		 0x4000.erased.not.written.not.0x8000.as.instructed.png (63 KB) 2008-10-29 11:27
flashWrite.c (7 KB) 2008-11-19 18:06
working.jpg (339 KB) 2008-11-11 19:01
Fred 2008-10-29 11:20 Date: 2008-10-27 15:29
Sender: sean94z

"I'll put some code together today and test it on the hardware when I get home and post my findings/patch."

Fred 2008-10-29 11:21 Date: 2008-10-27 19:21
Sender: fredcooke

"Awesome, note that this is the highest priority bug logged yet (yeah right) ;-)"

Fred 2008-10-29 11:21 Date: 2008-10-29 03:34
Sender: sean94z

"Good eye mate.

send( "Echo Pointer Test ");
pointer = 0x4000; //16384
sendUS(pointer);
send(" ");
pointer++;
sendUS(pointer);
send( " ");
telnet -----> Echo Pointer Test 16384 16385

send( "Echo Pointer Test ");
*pointer = 0x4000; //16384
sendUS(*pointer);
send(" ");
pointer++;
sendUS(*pointer);
send( " ");

telnet ------ Echo Pointer Test 16384 65535

Now to patch the code."
Fred 2008-10-29 11:22 Date: 2008-10-29 05:52
Sender: fredcooke

"One of those blocks you are setting and getting the address of the pointer, the other the value AT the address, but I'm sure you know that now :-)"

Fred 2008-10-30 00:46 I just ran it again with the new C file and there is absolutely no change in behaviour. I did notice something new though which you can see in the attachment pic that I posted earlier. The first word of the erased byte IS written. However the erased block is still the wrong one, and the data is still not written. The first word that IS written 0xCF3F is NOT the first word of the source block. I don't know where it came from, but this is worth investigating too.

Fred.
Fred 2008-10-30 06:16 I just had a look and the issue is within the assembly as called by line 79 :

StackBurner(flash_address);
sean94z 2008-10-30 15:37 I'll take a look at the flashBurn.s file and see what I find. Thanks!
Fred 2008-11-01 15:33 OK, missed these comments till now. The last comment post dates the attachments though, so I assume they aren't up to date. I'll wait till you give me the go ahead and post new files before I merge them in.

Fred.
sean94z 2008-11-03 17:44 I didn't get much down over the weekend but I thought I would post this.


if (Counters.logsSentCounter == 3)
    {
        send("-----------------Printing Flash Gordon Test------------------------ ");
        writeAlignedBlock((unsigned short*)0x8000, (unsigned short*)0x4000);
    }

Results in 0x8000 being erased, still need to verify that it is writing data.
sean94z 2008-11-03 21:20 I have been playing with the eraseSector function and discovered that it only will erase starting at $8000 no matter what address I pass into it.
sean94z 2008-11-04 18:16 Strange observation

eraseSector((unsigned short*) 0x8c00);
    }
will erase 4c00 when I look at freeems.full.dump.48k.s19

eraseSector((unsigned short*) 0x8000);

will erase 0x4000 and so on............................
Fred 2008-11-04 20:05 Getting closer :-)
sean94z 2008-11-06 16:20 Offset implemented in eraseFunction, it now behaves as ordered. Should have write block ready to go very soon.
sean94z 2008-11-06 17:16 Offset implement in writeWord, it now behaves as ordered. Now on to testing/fixing writeAlignedBlock.
sean94z 2008-11-06 19:52 Almost working, writeAligned seems to only write the first word it reads, possible syntax error. But at least its wrights an entire 1k block. Maybe I cant go flash to flash........

writeAlignedBlock((unsigned short*)0x7c00, (unsigned short*)0x2000);
sean94z 2008-11-06 20:43 I have refactored the code and moved the offSet addition to the writeAligned function. This should lower CPU overhead, however eraseSector and writeWord will write to the wrong address if called outside of writeAligned, unless the offSet is added before passing the parameters.
sean94z 2008-11-07 19:26 Added extra delay in StackBurner.s. No matter what I do I cannot write to 0x8000. I passed 0x7c00 and 0x1024 and the results look promising.
sean94z 2008-11-07 21:26 RAMAddr offset is NOT needed, I was mistaken.
sean94z 2008-11-07 21:31 7c00/c000 WORKS!!!!!!!!!!!! But here is the kicker if I comment out line
sendUS((unsigned short)RAMAddr. The cpu will hang and I never get my DONE message.



send("-----------------Printing Flash Gordon Test------------------------ ");
        writeAlignedBlock((unsigned short*)0x7c00, (unsigned short*)0xc000);
        send(" DONE ");






    while (wordCount > 0)
    {
        unsigned short sourceData = *RAMAddr; /*Convert the RAMAddr to data(dereference) */
    // sourceData += sourceData;
        writeWord(flashAddr, sourceData);
        RAMAddr = RAMAddr + 1; /* increment RAM source up by one word */
        flashAddr = flashAddr + 1; /* increment flash destination up by one word */
        sendUS((unsigned short)RAMAddr);
        wordCount--; /* Decrement our word counter */
    }
Fred 2008-11-07 21:45 This isn't the best style IMO :

RAMAddr = RAMAddr + 1; /* increment RAM source up by one word */
flashAddr = flashAddr + 1; /* increment flash destination up by one word */

I would like to see this instead :

RAMAddr++; /* increment RAM source up by one word */
flashAddr++; /* increment flash destination up by one word */

They should behave identically. You can check the generated ASM between compiles to confirm that it is OK :-)
sean94z 2008-11-07 21:55 Changed! Tests fine, as long as I don't comment out the sendUS((unsigned short)RAMAddr);
Fred 2008-11-08 11:26 Try putting in a call to adjust ADCs instead and see if its the function call making it OK. If it's in ASM, perhaps you aren't handling the stack pointer or return of data to regs on and off the stack effectively?
sean94z 2008-11-10 20:17 replacing sendUS with send(" FUQ "); causes it to write a block of CF3Fs

Tried replacing the While with a For loop, had no effect.

sean94z 2008-11-10 22:34 Now works without making any external calls. There is a 'junk' function in flashWrite.c to get it working for the time being.
Fred 2008-11-10 23:13 Works perfectly (congratulations) :

writeAlignedBlock((unsigned short*)0x7c00, (unsigned short*)0xc000);

Erases 0xC000 and writes nothing :

writeAlignedBlock((unsigned short*)&VETableMainFlash, (unsigned short*)0xC000);

Thanks for that, it's an improvement over the last release which is good :-)

Wrapping it in ppage swapping did not help :

unsigned char old = PPAGE;
PPAGE = BIGTABLES_PPAGE;
writeAlignedBlock((unsigned short*)&VETableMainFlash, (unsigned short*)0xC000);
PPAGE = old;

same exact result as without.
sean94z 2008-11-11 20:57 I'm now working with .17 code, let me see if I can find the WTF.
sean94z 2008-11-12 22:52 eraseSector( (unsigned short*)&VETableMainFlash );
writeWord((unsigned short*)&VETableMainFlash, (unsigned short)0x0000);


will erase and write 0000 to the first word in block 0x4000

The problem is in the loop unless 0x4000 is the wrong address

Also calling
eraseSector( (unsigned short*)&VETableMainFlash );
with eraseSector commented out of writeAlignedBlock.
writeAlignedBlock((unsigned short*)&VETableMainFlash, (unsigned short*)0xC000);

Will Erase 0x4000 and write nothing to it.

sean94z 2008-11-19 18:08 Seems to work now, I should be able to add ppage to the header.

 StackBurner(0x3E); //PPAGE loaded into Register B, PPAGE is set with Reg B in StackBurn asm file 0x3E is a test value
Fred 2008-11-26 22:48 Tested successfully this evening, closing.
41 Flash Burning minor N/A 2008-11-08 17:46 2008-11-26 22:46 Fred sean94z normal closed none none fixed 0 Add PPAGE setting to the function and function header. As soon as you have bug 5 licked, I need you to add burning to an explicit page to the function. IE :

[code]writeAlignedBlock(destAddr, sourceAddr, whichPPAGE){}[/code]

Or similar.

I can handle the paging external to the app function if required? that is very easy, just set it and enter function :-)

Get it working 100% first and I can try that, it's probably just a wrapper thing anyway...

When I say wrapper, I mean just add in a call to write it to the register before continuing. I think it should be compulsory to specify the page when using it as most stuff will be paged in future...		 flashBurn.h (1 KB) 2008-11-26 20:38
flashWrite.h (2 KB) 2008-11-26 20:58
flashWrite.c (7 KB) 2008-11-26 20:59
flashBurn.s (12 KB) 2008-11-26 20:39
sean94z 2008-11-19 22:16 unsigned char oldFlashPage = PPAGE;
            // perform function TODO
            PPAGE = 0xFF;
            writeSector((unsigned char)0xE0, (unsigned short*)0x0000, (unsigned short*)0xc000);
            PPAGE = oldFlashPage;

see ppage.jpg for results
sean94z 2008-11-25 22:35 Found error in ASM code that incorrectly handles PPAGE, will post fix SOON.
sean94z 2008-11-26 20:40 Give those files a go and let me know!
Fred 2008-11-26 22:46 Tested successfully this evening, closing.
54 User Interface minor always 2008-11-15 20:02 2008-11-16 21:15 Fred BenFenner normal closed none none fixed 0 Red button text skewed See screen shot :

http://i260.photobucket.com/albums/ii15/diyefi/FreeEMS-Tuner/stillBadOnEEE.png [^]
sry_not4sale 2008-11-16 20:57 Fixed in HEAD.

I am unaware of the correct wx code to center multiple line automatically.
Fred 2008-11-16 21:15 Confirmed fixed.
40 General Features minor always 2008-11-05 13:43 2008-11-16 13:06 Fred Fred high closed none none fixed 0 Hard Reset No Longer Works Since Change To Paging After changing the flash system to the paged scheme from linear the hard reset vector call no longer resets. Instead it corrupts some registers etc and stops the application running normally. I've spent some time trying to diagnose it, but no luck yet.

Soft application level reset is being used instead in the interim.
Fred 2008-11-16 13:06 Decided to give up with my dodgy vector method and use the COP method that the SM uses. This works well.
17 Documentation block N/A 2008-10-31 09:33 2008-11-11 10:55 Fred Fred high closed minor fix < 1 month fixed 0 Update Comms Documents To Reflect Current Reality The comms docs require some work to accurately reflect the current state of the standards. This is blocking Aaron and others work on GUI front ends to the firmware.
Fred 2008-10-31 09:34 The following docs all need to be updated :

Comms core spec
Comms vanilla spec
Comms implementation

These will allow other developers to build apps to tune the device.
Fred 2008-11-11 10:55 This was completed (except implementation doc) and released on 0.0.17
16 Serial Communications block N/A 2008-10-31 09:29 2008-11-11 10:52 Fred Fred high closed major rework 2-3 days fixed 0 Refactor The Serial Comms Code The freshly written serial comms code requires some rework as it is not currently correct. I've noted a number of issues with it and am working to resolve them as soon as possible.
Fred 2008-11-02 08:24 1/4 done as of last night, working on it again today.
Fred 2008-11-02 18:23 I've made a lot more changes today.

Completely redid the serial headers with all new fields and flag names etc
Mapped out the flow of control via flags and interrupt enable disable etc
I've moved various things around and made some subtle changes here and there

Much more to do, but feeling a bit more positive about it now.
Fred 2008-11-03 00:55 I'm about 50% of the way through making the rest of the changes to the actual code to fall inline with the headers and design.
Fred 2008-11-04 22:05 The interrupt aspect and the headers for that function correctly. Further work is still required before full functionality is available.
Fred 2008-11-10 10:57 Table fetching works

I need to do more work around table manipulation and also add debug and error handling properly too.

This should be completed this evening with a little luck.

Then just the docs need bringing up to date as in the other issue.
Fred 2008-11-11 10:52 This work was completed and released in 0.0.17
39 Comm Interface major N/A 2008-11-04 22:19 2008-11-05 23:09 sry_not4sale sry_not4sale high closed none none won't fix 0 Dump raw bytes to file Dump all sent packets to file
sry_not4sale 2008-11-05 23:09 Don't think this is really necessary with the raw output in the commsDiagnostics ui element
38 User Interface minor always 2008-11-04 22:09 2008-11-05 23:08 Fred sry_not4sale low closed none none fixed 0 Zero Padding Of Hex Bytes In Packet Data It would be nice if the data displayed was in the form 0x08 instead of 0x8. Again, ultra low priority.
sry_not4sale 2008-11-05 00:29 Fixed, and also now upper case the HEX
36 User Interface feature N/A 2008-11-04 00:33 2008-11-05 23:07 sry_not4sale sry_not4sale high closed none none fixed 0 Big red hardware reset button Just for fred ;)
Fred 2008-11-04 01:34 http://www.newlaunches.com/entry_images/0607/01/ultimate_reset_button1.jpg [^]

I'd prefer a more Ferrari like red, scarlet is the name I believe.
sry_not4sale 2008-11-04 20:06 Created!
Fred 2008-11-04 21:34 The big red button is present and looks fantastic, however it does not reset the controller at this time :-) Reopened! ;-)
sry_not4sale 2008-11-05 23:07 This time!
23 Build Process tweak N/A 2008-11-01 23:38 2008-11-04 22:04 Fred Fred normal closed none none 0.0.16-FlashGordon fixed 0 Investigate Paged Function Memory Addressing I'm not 100% certain that the linear addresses reported by hcs12mem when doing a dump are accurate in terms of what GCC does with them. I need to compile a program with some functions in paged space and see how the assembly generated looks with respect what it puts in PPAGE to switch pages for a given linear address. After that I can finalise the Makefile and memory.x and linker script to work correctly for all pages. Once this work is completed and the loader utility written we can start writing serious quantities of code for all sorts of nifty features :-)
Fred 2008-11-04 20:08 I did some solid work on this today and will try it out shortly.
Fred 2008-11-04 22:04 Paging is now implemented in FreeEMS 0.0.17 pre release and works nicely.

It throws a lot of warnings, but I think they don't matter.

We now have 128k of flash to play with instead of the 48k we had before.

The addresses I had before were wrong afterall. I solved it by using those same warnings.

Additionally, hcs12mem and the serial monitor function fine out to that 128k limit.
1 Comm Interface feature N/A 2008-10-28 21:16 2008-11-03 23:49 sry_not4sale sry_not4sale high closed none none fixed 0 Set up comms over serial This is basic functionality and is required before going much further!
sry_not4sale 2008-10-29 20:11 Now sends packets over serial!! Still need to tidy it up tho
sry_not4sale 2008-11-01 22:28 Code complete, including error handling.

Tested with a virtual serial port!
sry_not4sale 2008-11-03 23:49 Tested by Fred, worked!!!
32 Ignition / Injection Scheduler minor always 2008-11-03 10:22 2008-11-03 10:23 Fred Fred normal closed none none 0.0.11-Cookin' fixed 0 Forgot to add code run time to test for always on in new code layout. Forgot to add code run time to test for always on in new code layout. Fixed some time ago, just creating permanent record of old bugs.
31 Ignition / Injection Scheduler minor always 2008-11-03 10:22 2008-11-03 10:23 Fred Fred normal closed none none 0.0.10-Squashed fixed 0 The logic for injectors staying hard on relies on predicting the future, clearly this is no good :-) The logic for injectors staying hard on relies on predicting the future, clearly this is no good :-) Fixed some time ago, just creating permanent record of old bugs.
30 Ignition / Injection Scheduler minor always 2008-11-03 10:21 2008-11-03 10:22 Fred Fred normal closed none none 0.0.10-Squashed fixed 0 Bad PW Due To Advance The logic that causes the injectors to stay hard on is not taking advance into account. This is causing the step from requested pulsewidth to be "advance" large, so if pulse width increases from 10ms to 20ms and advance is 10ms, and the period of the whole cycle is 25ms, you will get a step from 15ms to 25ms/100% duty when the end of the pulse hits the point where the thing is scheduled from. Fixed some time ago, just creating permanent record of old bugs.
29 Ignition / Injection Scheduler minor always 2008-11-03 10:16 2008-11-03 10:17 Fred Fred normal closed none none 0.0.10-Squashed fixed 0 Engine Cycle Period Used Before Valid As per title. Fixed some time ago, just creating permanent record of old bugs.
28 Ignition / Injection Scheduler major random 2008-11-03 10:13 2008-11-03 10:14 Fred Fred high closed none none 0.0.1-To-0.0.9 fixed 0 PORTA and PORTB get written to randomly after program runs for some time This is likely to do with pointers and arrays and what have you, but I haven't had a chance to track it down yet.
Fred 2008-11-03 10:14 Fixed some time ago, just creating permanent record of old bugs.
4 Build Process block always 2008-10-29 10:42 2008-10-31 09:08 Fred Fred high closed none none fixed 0 .vector and .bss overlap during the link This occurs with nearly 2 kilobytes of flash space unused in the s19 image. Either bss data should be present in the s19, or should be removed from the link somehow to free the 2k space for further code to reside in.

Blocking because code size is currently right on the 48k limit and we can't exceed that due to hcs12mem issues and lack of custom loader.
Fred 2008-10-29 22:55 I've been looking into this today and have found a few things to try out. I found that I wasn't including the .data section in the S19. This is bad as it probably means that some variables weren't being initialised properly... I have noted a few things to test with regards this so will be looking into it more tomorrow evening.

I had a quick look at the ms2e s19 and memory map and found that they also have an unused hole between the code and vectors. I'm currently wondering if the compiler is trying to be smart by assuming that unwritten flash is zero or is one after an erase and just not loading the data and reading from the bare flash to init.
Fred 2008-10-31 09:08 This morning I continued yesterdays investigation and eventually found a missing AT() clause in the linker script. I can now add more functions as there is a chunk more free space available. Most happy about this :-)
82 Comm Interface minor always 2008-12-03 00:09 2009-02-15 10:44 Fred Fred normal resolved none none fixed 0 escaped bytes handled incorrectly causing checksum to be wrong. I setup a test packet with 0 - 255 in it 8 times, when received, this is printed out :

2008-12-03 12:52:47,244 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,245 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,246 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,247 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,248 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,249 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,251 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,252 ERROR serial.FreeEMS_Vanilla - Wrongly escaped byte found in packet: 43
2008-12-03 12:52:47,254 ERROR comms.Serial - Checksum is incorrect! Provided: 55, generated: 151
Traceback (most recent call last):
  File "/home/fred/tuner/gui/__init__.py", line 130, in OnIdle
    self.CommsReceive()
  File "/home/fred/tuner/gui/__init__.py", line 312, in CommsReceive
    comms.getConnection().recieve()
  File "/home/fred/tuner/comms/Serial.py", line 171, in recieve
    logger.error('processRecieveBuffer failed to parse packet from buffer: %s' % join(protocols.toHex(cache)))
NameError: global name 'join' is not defined
 This indicates to me that only one type of escaped byte is handled wrongly as there are 24 escaped bytes per test packet, 8 of each type.
sry_not4sale 2009-01-13 21:37 Packets were being escaped twice
Fred 2009-01-14 05:43 Tested fixed.
66 Comm Interface minor N/A 2008-11-18 21:39 2009-02-15 08:34 sry_not4sale sry_not4sale high resolved none none fixed 0 Fix spelling of receive throughout the code Common Aaron... lol
Fred 2008-11-18 23:50 Perhaps I should grep for this too :-)

Perhaps you should grep for to and too and check on those as well ;-)
70 Comm Interface minor always 2008-11-28 00:12 2009-02-15 08:33 Fred sry_not4sale normal resolved none none fixed 0 Packet parser breaks valid packets up and then complains they aren't valid this is seen with large packets, the code appears to split them into smaller chunks for some reason and then decide they aren't valid as smaller chunks.

Seen using bens code to pull the IAT table.

Logs emailed.
83 Comm Interface minor have not tried 2008-12-03 00:10 2009-02-15 08:32 Fred sry_not4sale normal resolved none none fixed 0 Performance unacceptablely bad and data lost due to this When streaming constant 115200 bit per second data the software can not keep up, chews 100% cpu and fails to buffer and receive all messages. Obviously all of these things are bad :-)
72 User Interface minor always 2008-11-28 00:20 2009-02-15 08:32 Fred sry_not4sale normal resolved none none fixed 0 all logged data should be displayed as hex ERROR comms.Serial - processRecieveBuffer failed to parse packet from buffer: [

dumps decimal. This is bad for three reasons :

1) you can't compare it readily with the other messages
2) you can't easily join two 8 bits into a 16 bit number
3) because they aren't fixed width you can't tell how long the packet chunk was
86 Configuration / Settings minor always 2008-12-18 20:06 2009-02-15 08:28 sean94z sry_not4sale low resolved none none unable to reproduce 0 my_config.ini not parsed with default.config.ini When I downloaded FreeEMS-Tuner I put my port settings in my_config.ini. Because the example my_config.ini only had a couple lines, I made the assumption that it is parsed with default.config.ini. This was not the case as I had to specify all settings in my_config.ini before it would connect to FreeEMS.
sry_not4sale 2009-01-13 21:36 Can you confirm this with a fresh install of the tuner?

Thanks
71 Firmware Protocol tweak always 2008-11-28 00:16 2009-02-15 08:27 Fred sry_not4sale low resolved none none fixed 0 firmware interface unique id is wrong and interface version is wrong Currently :

protocols/FreeEMS_Vanilla/0_1.py

Should be :

protocols/IFreeEMS\ Vanilla/0.0.1.py

I think exact names are important as I could potentially use an underscore and mean for it to be different than a space. 0.0.1.py doesn't matter though, provided it has 3 digits. 0_0_1.py is fine too.
sry_not4sale 2008-11-28 07:58 Using spaces or dots or dashes in file names would break pythons import mechanism, so have renamed file to 0_0_1.py from 0_1.py
sry_not4sale 2008-11-28 08:00 Fixed in commit 425b85e2264be44e02019394a361d1da18d6bdeb
Fred 2008-11-28 13:49 Got the version change, but you missed the I on the front of IFreeEMS_Vanilla ;-)
Fred 2008-11-30 12:16 Thinking about this some more...

I think what you need to do is either through config or in the master comms file have a mapping of exact string key identifier to file path and name. That way you can call them what you like and the id process will always work correctly. I think this is important and I hate spaced file names too :-)
sry_not4sale 2009-01-13 21:43 Now moved to

/comms/protocols/IFreeEMS_Vanilla/0_0_1/*
65 Firmware Protocol block have not tried 2008-11-18 21:38 2008-11-19 20:54 sry_not4sale sry_not4sale normal resolved none none fixed 0 Code could cause first part of a packet to disappear protocol.processRecieveBuffer() will process the buffer if it finds a start and end byte in it.

Once it finds a start byte it started popping bytes of the buffer until it finds the end byte. If it doesn't find the end byte, these bytes will be lost!
Fred 2008-11-18 21:40 Save your chat log, it tells you exactly how to fix that and other subtle issues ;-)
63 Main Site block random 2008-11-16 20:59 2009-10-13 16:25 sry_not4sale Fred high assigned none none open 0 People still using MegaSquirt Please fix ASAP
Fred 2008-11-16 21:42 eye eye sir!!
Fred 2009-10-13 16:25 An engine has now run on FreeEMS. That is the first step, more to come soon.
104 User Interface minor have not tried 2009-09-08 09:36 2009-09-08 09:37 sry_not4sale sry_not4sale normal assigned none none open 0 Add datalog sample rate display datalog packets/second
76 User Interface feature N/A 2008-11-28 23:33 2009-09-04 10:39 Fred sry_not4sale normal assigned none none open 0 Add ability to cell by cell tune tables to memory dump tab This one should be pretty easy too :-)

You'll need to source the location id from the same drop down.

Then you need three numeric text entry fields :

RPM index
Load index
Value

The three new packet types are :

/* Main table manipulation */
#define adjustMainTableCell 100
#define adjustMainTableRPMAxis 102
#define adjustMainTableLoadAxis 104

The first one has 8 bytes of payload in the form of 4 unsigned shorts.

<start><header> location id, rpm index, load index, cell value <checksum><stop>

The second is :

<start><header> location id, rpm index, rpm value <checksum><stop>

And the third :

<start><header> location id, load index, load value <checksum><stop>

This will form the foundation of tuning into the future :-)

Should be easy as pie to do as well :-) Mean while Aaron can fix those bugs ;-)
Fred 2008-11-28 23:33 All yours Ben! :-)
BenFenner 2008-12-02 23:39 Here's some notes:

BenFenner: You want to be able to specify a load and rpm and give it a value, right?
Fred: ahh
Fred: no
Fred: the index of load and rpm
BenFenner: The cell-by-cell thing.
Fred: so not 5000rpm
Fred: but 15th rpm row
Fred: you see?
BenFenner: Sure.
BenFenner: So it should take in two axis coordinates.
Fred: yes
Fred: and a value
BenFenner: And a new value.
Fred: yep
BenFenner: k
BenFenner: And the packet it needs to send out looks like?
Fred: 8 bytes long
Fred: 4 unsigned shorts
Fred: first is location id
Fred: you already have a drop down for that
Fred: second is rpm index
Fred: third load index
Fred: fourth value
Fred: easy :-)
BenFenner: any special header flags, etc?
Fred: no, just standard
Fred: firmware type and no length or anything

sry_not4sale 2009-09-04 10:39 New firmware ID's

/* Main table manipulation */
#define adjustMainTableCell 300
#define adjustMainTableRPMAxis 302
#define adjustMainTableLoadAxis 304
79 User Interface feature N/A 2008-11-30 19:55 2009-09-04 09:42 Fred sry_not4sale normal assigned none none 0.1 open 0 Real time vars display for basic datalog packet create a tab with name and value pairs of fields in fixed locations. The values can be updated by a back ground process that reads fresh data, and the names will be static from code or config at start up.

Something like the temp and resistance fields here :

http://i260.photobucket.com/albums/ii15/diyefi/FreeTherm/RealScreenShot.png [^]

Only name on left and value on right might be better?		 The format of the packet will be as follows :

unsigned short IAT[IN_OUT_BANKS]; /* Inlet Air Temperature */
unsigned short CHT[IN_OUT_BANKS]; /* Coolant / Head Temperature */
unsigned short TPS[IN_OUT_BANKS]; /* Throttle Position Sensor */
unsigned short EGO[IN_OUT_BANKS]; /* Exhaust Gas Oxygen */
unsigned short MAP[IN_OUT_BANKS]; /* Manifold Absolute Pressure */
unsigned short AAP[IN_OUT_BANKS]; /* Atmospheric Absolute Pressure */
unsigned short BRV[IN_OUT_BANKS]; /* Battery Reference Voltage */
unsigned short MAT[IN_OUT_BANKS]; /* Manifold Air Temperature */
unsigned short EGO2[IN_OUT_BANKS]; /* Exhaust Gas Oxygen */
unsigned short IAP[IN_OUT_BANKS]; /* Intercooler Absolute Pressure */
unsigned short MAF[IN_OUT_BANKS]; /* Mass Air Flow */
unsigned short DMAP[IN_OUT_BANKS]; /* Delta MAP */
unsigned short DTPS[IN_OUT_BANKS]; /* Delta TPS */
unsigned short RPM[IN_OUT_BANKS]; /* Revolutions Per Minute */
unsigned short DRPM[IN_OUT_BANKS]; /* Delta RPM */
unsigned short DDRPM[IN_OUT_BANKS]; /* Delta Delta RPM */
unsigned short LoadMain[IN_OUT_BANKS]; /* Configurable unit of load */
unsigned short VEMain[IN_OUT_BANKS]; /* Divide by 512 to get % */
unsigned short Lambda[IN_OUT_BANKS]; /* Divide by 32768 to get Lamda */
unsigned short AirFlow[IN_OUT_BANKS]; /* top half */
unsigned short densityAndFuel[IN_OUT_BANKS]; /* bottom half */
unsigned short BasePW[IN_OUT_BANKS]; /* In timer ticks of 0.8us */
unsigned short IDT[IN_OUT_BANKS]; /* 0.8us ticks */
unsigned short ETE[IN_OUT_BANKS]; /* 0.8us ticks */
signed short TFCTotal[IN_OUT_BANKS]; /* Transient fuel correction */
unsigned short FinalPW[IN_OUT_BANKS]; /* In timer ticks of 0.8us */
unsigned short RefPW[IN_OUT_BANKS]; /* In timer ticks of 0.8us */

note TFC is signed and the rest are unsigned, no scaling factors are given yet, I just need to see the raw numbers for now, the rest will come in the JSONs later.

Also note, each one of these is two vars (new and old or old and new) taking up 4 bytes. later the format will change to one of each (and be the latest) but for now, either :

* just take the first one of each
* average the two
* display both
* make me send a byte to tell you which one is which		 many.many.many.datalogs.zip (18 KB) 2008-11-30 21:54
Fred 2008-11-30 21:57 Attached is a large amount of raw data dumped by the tuner while running at 100% cpu on my turion 64 1800. This is attached for both serial handling testing and example packets :-) Not sure if they are good packets at this stage, but they should be I think.
BenFenner 2008-12-02 03:41 It's all you Aaron unless you want to toss it back to me.
Right now it's pretty self explanatory once you see the code.
Purely visual right now with no logic behind it. Just a pretty face.
Fred 2008-12-03 00:19 Aaron, when parsing this, you should parse what you can before the end in the length specced. This is a packet that always has length. The length is variable but the field order is consistent. if there were 16 fields, and the length was half that, then you'd just parse 8 and zero/null/ignore the other 8 in the tuner display or indicate that they are not being populated.
sry_not4sale 2009-09-04 09:42 Contains the code to decode and display datalog packets in realtime interface:
721dc65ef0cb41c4b38a4b4e6e9e34b65e783409


All data is assumed to be an unsigned int, is displayed raw and unprocessed (except for averaging the two values received).
80 Firmware Protocol feature have not tried 2008-12-02 23:48 2009-09-02 21:31 Fred sry_not4sale normal assigned none none 0.1 open 0 Ability to turn async datalog on and off one button and one drop down

firmware type (0x00 for flags)

payload id is :

#define setAsyncDatalogType 304

one byte in payload :

0x00 for off
0x01 for basic/on
0x02 and 0x03 should do nothing, other values will throw an error.

easy :-)
BenFenner 2008-12-02 23:59 Fred: packet to turn the bastards off
BenFenner: Yah, you're gunn ahave to explain that one too. =]
BenFenner: What's happening now, why is it happening, and what needs to be done to fix it.
Fred: i just realised i told you the payload id is 304 for both, but its only 304 for the datalog control packet
Fred: ok
Fred: whats happening is that the tuner has poor performance
Fred: and
Fred: some how the data requests are ignored when the datalogs are flooding
Fred: there is a command to turn them off
Fred: there is also one to ask for them one at a time
BenFenner: Data requests from the tuner of the firmware?
Fred: yeah
BenFenner: So the tuner asks for data while the EMS is flodding the tuner with data and the request is ignored?
Fred: yes
Fred: not sure why
Fred: but cant test it while its flooding
Fred: so need to disable and reenable
BenFenner: You have a command in your firmware I can use to stop the data logging (isn't that a request in a flood?) and/or tell it to send one at a time?
Fred: yes, to the command
Fred: yes its a request
Fred: but no, they arent totally ignored
BenFenner: k
Fred: they just dont seem to return data
Fred: but can reset and control stuff
Fred: etc
sry_not4sale 2009-02-15 19:41 Tuner SO does not have "poor" performance :P

geez... ungrateful %%(*&$R% :P



I was thinking on and an off buttons on the data log display page

Fred: Sure, just source the byte for the ON from a field and default it to 0x01 so that I can turn on other types when I get them going :-)
102 Serial Communications minor have not tried 2009-09-02 09:58 2009-09-02 09:58 sry_not4sale Fred normal assigned none none open 0 Need method for discovering status of datalogging The tuner needs a way of discovering the current status of datalogging. e.g whether it is turned on or off.

Current related packets are:
#define requestBasicDatalog 400
#define responseBasicDatalog 401
101 Comm Interface major have not tried 2009-09-02 09:12 2009-09-02 09:12 sry_not4sale sry_not4sale normal assigned none none open 0 Pressing cancel at the Choose comms log file dialog doesn't cancel It acts as if you pressed OK
42 User Interface tweak N/A 2008-11-09 05:43 2009-09-02 08:32 sry_not4sale sry_not4sale normal assigned none none open 0 Tuner title text - version, etc As talked about here:
http://www.diyefi.org/forum/viewtopic.php?f=43&t=475&start=60 [^]
and:
http://www.diyefi.org/forum/viewtopic.php?f=43&t=475&start=60 [^]


My take on title/status bar text...

Title:
"FreeEMS-Tuner 0.0.1 - build 2008110901"

Status bar:
"Comms: Serial /dev/tty01 | Protocol: FreeEMS Vanilla 0.0.17 pre-alpha"


Ideas, votes... add your comments here!
Fred 2008-11-09 20:44 Looking above this box I see that firefox has the page title to the left and it's own name to the right. In release version the build won't be present so I'd be looking for that to be integrated with the name and version at the moment. If that's the case then it makes sense to me to display the firmware version in the title bar next to the tuner version.

As mentioned in the forum, the configuration and code should be labeled around the interface stuff. IE, if you follow your name/version structure for the next release it will be :

basedir/IFreeEMS\ Vanilla/0.0.1.py or whatever

The version of the firmware should be for display purposes and linking bugs only. The interface should define the interaction between the tuner and firmware.

So in the info box from the menu, put interface and build and so forth and on public display put tuner name/version - firmware name/version

If you think the build is more than just a build tag for dev use then I'm concerned because it implies that you may have more than one 0.0.1 available at any given time which would seriously confuse users IMO. builds for dev, releases for release?

These are my thoughts.
Fred 2008-11-16 14:18 New thoughts : Whatever is displayed should probably indicate what type of device it is talking to at the time.

MegaSquirt2 SerialMonitor FreeEMS VEMS etc :-)

Fred.
sry_not4sale 2008-11-28 08:05 Build for commits, versions for packaged/tagged releases.

Can you confirm a title scheme and status bar scheme that you would like?
Fred 2008-11-28 14:25 Well, I think these should be obvious at all times while running :

* Tuner exact name and version (regardless of release status, always want to know that even if it's ugly)
* Firmware Name and Version (display, not interface)
* The type of firmware connected (covered by the last one probably)

I'd probably go with just the title bar (use other space for actual tuning) :

<tuner name/version> - <firmware name/version>

Which for your first release will probably be something like :

FreeEMS-Tuner (0.0.1) - "FreeEMS Vanilla v0.0.18 pre-alpha"

Or something. I don't want to be too fussy about this but I do want those two name/versions to be displayed obviously such that no one can be confused about what they are using.
sry_not4sale 2009-02-20 20:44 Had issues with importing modules starting with a integer, so renamed 0_0_1 folder to v0_0_1

e.g

comms/protocols/IFreeEMS_Vanilla/v0_0_1/*
sry_not4sale 2009-03-31 20:56 Is this ok for an interface version?:

IFreeEMS.Vanilla (v0.0.1)
sry_not4sale 2009-08-31 21:32 Example..:


Titlebar: FreeEMS-Tuner (version) - FreeEMS Vanialla v0.0.18 pre-alpha

Statusbar: Protocol: IFreeEMS.Vanilla (v0.0.1) | Comms: Serial (/dev/tty1)
sry_not4sale 2009-09-02 08:32 All done bar interrogation to get firmware version
81 Serial Communications minor always 2008-12-02 23:52 2009-02-22 20:03 Fred Fred normal assigned none none open 0 Find a way to remove extra start byte hack. Without the hack, when sending a lot of data, there is no start byte sent. With the hack, when sending no data, there are 2 sent.

I suspect perhaps its still sending the last byte and thus doesn't get the first one and ignores it. Perhaps poll flags before writing out?
Fred 2009-02-22 18:41 This seems to be an issue for the start byte too. It's like we are losing the ends of various things at random. I'll be performing some more testing now to eliminate issues (even if I have to put hacks in) and posting here again soon.
Fred 2009-02-22 20:03 Second hack works just like the first and just as well too. Now all packets have two start and two stop bytes. Some percentage of the time they get lost though...

We need to suss out why and remove these hacks by putting a proper fix in whatever it is.
99 Serial Communications block always 2009-02-22 16:34 2009-02-22 18:24 Fred Fred urgent assigned none none open 0 Corrupt packets are sent when RPM interrupts are active Bad checksums are received by PC side software when the RPM on the device is non-zero.

There are a few reasons that I can think of that this is happening.

1) Delay in serial interrupt handling is causing bytes to be corrupted or lost due to timing.
2) Buffer data is being corrupted by the RPM interrupts
3) A concurrency issue is causing corruption of the checksumming routine when it runs

I can't think of any others right now, but there may be some.		 Receive data stream from device
Apply RPM signal with JimStim to device
 Many of the received checksums are zero or all ones. This is suspicious IMO.

Packet number 11236 ending of length 102 at char number 1117861 failed checksum! Received 0 Calculated 246
Packet number 11237 ending of length 102 at char number 1117965 failed checksum! Received 255 Calculated 134
Packet number 11239 ending of length 102 at char number 1118077 failed checksum! Received 0 Calculated 228
Packet number 11240 ending of length 6 at char number 1118085 failed checksum! Received 0 Calculated 82
Packet number 11242 ending of length 102 at char number 1118197 failed checksum! Received 255 Calculated 152
Packet number 11244 ending of length 102 at char number 1118309 failed checksum! Received 0 Calculated 64
Packet number 11245 ending of length 102 at char number 1118413 failed checksum! Received 0 Calculated 219
Packet number 11246 ending of length 102 at char number 1118517 failed checksum! Received 0 Calculated 200
Packet number 11248 ending of length 102 at char number 1118629 failed checksum! Received 0 Calculated 219
Packet number 11249 ending of length 6 at char number 1118637 failed checksum! Received 0 Calculated 82
Packet number 11250 ending of length 102 at char number 1118741 failed checksum! Received 255 Calculated 4
Packet number 11252 ending of length 102 at char number 1118853 failed checksum! Received 255 Calculated 156
Packet number 11253 ending of length 102 at char number 1118957 failed checksum! Received 0 Calculated 249
Packet number 11254 ending of length 102 at char number 1119061 failed checksum! Received 190 Calculated 54
Packet number 11256 ending of length 102 at char number 1119173 failed checksum! Received 0 Calculated 60
Packet number 11257 ending of length 102 at char number 1119277 failed checksum! Received 0 Calculated 192
Packet number 11258 ending of length 6 at char number 1119285 failed checksum! Received 0 Calculated 1
Packet number 11259 ending of length 102 at char number 1119389 failed checksum! Received 0 Calculated 31
Packet number 11261 ending of length 102 at char number 1119501 failed checksum! Received 0 Calculated 1
Packet number 11263 ending of length 102 at char number 1119613 failed checksum! Received 0 Calculated 145
Packet number 11264 ending of length 102 at char number 1119717 failed checksum! Received 0 Calculated 86
Packet number 11266 ending of length 102 at char number 1119829 failed checksum! Received 0 Calculated 251
Packet number 11267 ending of length 102 at char number 1119933 failed checksum! Received 255 Calculated 1
Packet number 11268 ending of length 102 at char number 1120037 failed checksum! Received 0 Calculated 247
Packet number 11270 ending of length 102 at char number 1120253 failed checksum! Received 0 Calculated 33
Fred 2009-02-22 16:41 The issue is with either my Nippon Denso code, OR the ignition or fuel code. I tried to reproduce the issue with Phil's 36-1 decoder and could not. Most likely the ignition PIT code is broken and corrupting memory. I will try to disable this next.
Fred 2009-02-22 16:52 Removing the ignition code did not help, I'll have to try removing the fuel code and putting ignition back. Then I'll remove both. If it still occurs then I'll look for the reason why it is happening in the remaining code. If that stops it I'll put a sleep function in to see if it is a sheer run time thing.
Fred 2009-02-22 17:26 Removal of fuel code didn't help either. ADC sampling is next to go.
Fred 2009-02-22 17:48 ADC sampling based on memcpy() is the cause!! I'll replace it with an old one that uses a loop or direct value by value copy and see where it gets me. I'll compare size for each too. I meant to bench mark those ages ago but never got around to it.
Fred 2009-02-22 18:24 This is solved and pushed up, I'll close it once I figure out exactly why memcpy was screwing things up and post here about that.
97 Structure / Style minor always 2009-02-05 00:34 2009-02-05 00:34 Fred Fred normal assigned none none open 0 Find areas where static variables should be used For some reason I didn't realise that static meant much the same thing as in Java...

Search out and replace all variables that are declared wrongly with static modifier where appropriate.
48 Serial Communications feature N/A 2008-11-11 16:15 2009-01-14 14:31 Fred Fred high assigned none none 0.0.17-SpudEchoes open 0 Complete Basic Firmware Functionality The addition of small tables and writing functions etc would complete the required work on serial stuff from the firmware side for the next forseeable future.
Fred 2009-01-02 14:16 Still need to test and/or implement the small table single cell adjust routine(s).
21 General feature N/A 2008-11-01 22:02 2009-01-08 21:18 Fred sean94z low assigned none > 1 month open 0 Create This Application We need an application to load the S19 files to the device, preferably using a GUI and preferably standalone. Currently we are using hcs12mem (which is GPL licensed) however it has a bug in erase and possibly burn also. See AN2548 for details on the serial monitor.

The issue with hcs12mem seems to be that it uses the erase all command 0xB6. This command DOES NOT WORK for our serial monitor. The flash must be erased one page at a time using the erase page command.

The basics are as follows :

To initiate comms you need to send it an 0x0D byte
It will respond with the following sequence 0xE0 0x00 0x3E
To blow away all the pages you perform a short sequence repeatedly :

write byte :

0xA2 0x00 0x30 0xPP

Where PP = PPAGE value required to be blown away.

erase page :

0xB8

pause and repeat.

Once it's blown away it can be programmed.

For this you will need to know the format of the S19 files.

each line starts with S and then has lots of HEX digits.

S1 is 2 byte address
S2 is 3 byte address

The next two chars are the length of the remainder in bytes in hex.

For small apps it is :

S113AAAADD~~~~~~~DDCC

Where
AAAA is the linear address in hex
DD~~~DD is 0x10 DD byte hex pairs
CC is the checksum byte

0x13 consists of 1 checksum, 2 address, and 16 data

The other format that we need is paged data.

For large apps it is :

S214PPAAAADD~~~~~~~DDCC

OR

S214LLAAAADD~~~~~~~DDCC

Where
LL is the linear address prefix
PP is the ppage register prefix
AAAA is the linear address in hex
DD~~~DD is 0x10/16 DD byte hex pairs
CC is the checksum byte

0x14 consists of 1 checksum, 3 address, and 16 data

I'm unsure how to write the data and verify, but it should be fairly straight forward.

Initial functionality to *just* blow away all pages would be very useful in combination with loading via hcs12mem.
Fred 2008-11-01 22:06 Typical linear short address line :

S11382407DD37DC57DB67DA87D9A7D8B7D7D7D6F3B

Typical linear long address line :

S2143801808463844D84388422840D83F883E383CE55

Typical ppage long address line :

S214E08170851484FE84E784D184BB84A5848F8479C7
Fred 2008-11-01 22:10 The way to do the erase is to start erasing at 0xFF and build down to the max extent of the flash.

For 512k it would be 32 erases.

0xFF
0xFE
0xFD
...
...
0xE2
0xE1
0xE0

then write the file in :-)

then verify.
Fred 2008-11-01 22:22 S records :

http://www.amelek.gda.pl/avr/uisp/srecord.htm [^]

App note :

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2548.pdf [^]

There are plenty of FreeEMS s record files available to download from sourceforge here :

http://sourceforge.net/project/showfiles.php?group_id=214452&package_id=258422 [^]

I can generate paged S19 files to test with fairly easily, just ask.

Fred 2008-11-01 23:10 OK, further info on this.

The pause between page erases should be at the very least :

320ms

It would probably be best to give the app a base time that and a configurable margin OR wait for the response from each erase command if there is one.

I'd be going for 500ms wait time between erases.

The 320 figure is based on the 20ms per sector mentioned in the AN2720 app note and 16 sectors per page.

This means the shortest erase will be 32 x 320 ~= 10 seconds. About 15 is you pause plenty to be safe :-)
Fred 2008-11-04 23:01 Further information about this :

erase all *does* work, but only erases the 128k block its on.

hcs12mem does work when treated right.

the priority of this just fell due to not needing it for some time. It would still be nice to make it easy for people to load the firmware as a user only and not a developer though.

hcs12mem doesn't do a verify either.

It may be possible to use erase all to erase the other 3 blocks, but I haven't looked into it.
Fred 2008-11-08 14:51 It's worth noting that we definitely do want this at some stage before the project gets popular. Loading with hcs12mem is a bit clumsy anyway and the serial monitor offers no data protection.

Data protection in terms of using parity and buffering the data for in order to confirm it is ok with a checksum is not possible with the serial monitor.

The app could use a boot strapping strategy where it loads its built in (or config style) firmware using the serial monitor and then resets the chip after asking the user to move the SM switch. It could then communicate with it's own custom firmware using a more cut down/restricted and robust protocol. Checksummed and verified loading combined with the robust firmware communications would provide absolutely NO chance for serial caused flash data errros that plague other simpler engine management systems.

I recommend a linear 12k RAM memory model. The design should use two buffers just as in the firmware. Unlike the firmware it should be compiled to run from ram in its entirety such that flash writing operations do not affect it at all. To keep complexity down I would suggest not using interrupts for communications and instead doing a busy wait style of operation as there is nothing else to do anyway.

It would be preferable for the same style of packets as in the main firmware to be supported, specifically :

/* Firmware Independent functions */
#define requestInterfaceVersion 0
#define requestFirmwareVersion 2
#define requestMaxPacketSize 4
#define requestEchoPacketReturn 6
#define requestSoftSystemReset 8
#define requestHardSystemReset 10
#define asyncErrorCodePacket 65533
#define asyncDebugInfoPacket 65535

I'd suggest a simple payload design with fixed packets consisting of :

action PPAGE address <optional 1024 bytes of data for writes>

and the same style for replies echoing the action and addresses back too :

action PPAGE address <optional 1024 bytes of data for reads>

with the same packet header and escape sequence as the main serial comms protocol.

actions could/should include :
read block
write block (with verify)
verify block (without write, against sent data)
others?

Alternatively you could use an incompatible cut down protocol (even if only for initial versions/testing) with start, <body> checksum stop and the same escape scheme as the main protocol.

/thoughts.
Fred 2009-01-08 21:18 I had an idea this evening :

When loading firmware we should be able to specify which parts we want to load.

IE, it should be possible to right down new code without touching a tune. It should also be possible to write down a tune without touching code without using the tuner.

Think of it as a kind of restore of settings. Obviously this probably won't work for the settings tables on most upgrades, but the main tables and lookup tables should be easy to achieve.

It would just be done via ranges or groups of pages to not touch or to touch. Bye exclusion or inclusion.
61 Initialisation / Configuration minor N/A 2008-11-16 15:03 2009-01-02 15:00 Fred Fred high assigned none none 0.0.17-SpudEchoes open 0 Go Through ALL ISR Code And Check For References To TablesA-D RAM Locations I've realised the potential for issues reading from that global ram space from an ISR while the math routine has the RPAGE value swapped out. I need to go through all ISR code and ensure there are no references to that present there and keep it that way into the future.
Fred 2008-11-25 13:38 This has been done, however the next step is to remove the references to these items from headers above the ISRs such that it can't happen in future. This task can stay open until that is done.
11 Structure / Style minor N/A 2008-10-29 16:48 2009-01-02 14:18 Fred Fred low assigned none none open 0 Define And Reorganise Header Structure Currently the header structure could be improved somewhat. I would like to see it more granular such that only files that *need* to see certain identifiers can see them. That should be the case with a single exception, main.c which should see everything.
Fred 2008-10-29 16:50 If possible I'd like to do some tricks to expose various vars for
reading in all files but only allow them to be writable in a few key
places. C lends itself to promiscuity and I'd like to avoid that if
possible.
Fred 2009-01-02 14:18 Some of this has been done, but much more is required. This is related to mantis 61
53 Analog Input Config & Processing tweak N/A 2008-11-15 16:34 2009-01-02 14:15 Fred Fred normal assigned none none 0.0.17-SpudEchoes open 0 Add Important Variables Into Structs And Refactor Placement Of Existing Ones Some variables are in places that they do not belong.
Many variables don't exist yet.

I should go through them in conjunction with the datalog thread and tidy them up a bunch.

If the other issue turns out to be a goer and the format changes, it would be a good opportunity to place them in order into separate memory regions such that a direct copy from RAM Is possible with minimal CPU overhead.
Fred 2009-01-02 14:15 To clarify what I meant by separate RAM region :

Set aside a piece of global RAM and pre init it with header data. After the header data block would be the various structs placed sequentially such that when a datalog needs to be sent it is a single memcpy() call of maximal efficiency only.

| header | struct 1 | struct 2 | struct n -1 | struct n | normal RAM ....

then the memcpy call can just take the configured length and it is single stage with no excessive ifs etc. Once it is in the serial buffer a normal checksum and send call can be made.
20 Initialisation / Configuration minor N/A 2008-11-01 12:17 2009-01-02 13:58 Fred Fred low assigned none none open 0 Move Static Initialisation To Single C File From init.c This will have a number of advantages :

* keeps the dynamic init code cleaner and more simple
* separates static init data out from code for visibility of resource consumption
* makes proper use of the compilers built in init code and uses less space overall

and probably other things.
Fred 2008-11-26 22:49 This is half done, needs further investigation.
Fred 2009-01-02 13:58 To be more precise, the array types may be able to be inited staticly as well. I may have tried to do that at a time when I wasn't linking the rodata in... which would explain why it didn't work then if so.
88 Serial Communications minor N/A 2008-12-22 20:18 2008-12-22 20:18 Fred Fred normal assigned none none open 0 Refactor serial code into functions to reduce large scale duplication. As part of this exercise the functions should be split off into different files as it makes sense. The first step of that was completed today with the removal of the address book lookup function to it's own file.
85 Main Site feature N/A 2008-12-16 22:11 2008-12-16 22:11 Fred Fred normal assigned none none open 0 Move content to Joomla or similar CMS I would be much more inclined to update the website if it was easier to do and the maintenance factor was less.

Migrating to Joomla wouldn't be a huge task, but must come after making an engine run.
69 General Features feature N/A 2008-11-25 11:47 2008-11-25 11:47 Fred Fred low assigned none none open 0 Add Useful COP Monitor Function Add a COP ISR handler that packages up the registers states, sends them out using the serial code and when done resets the device.

This shouldn't take a significant amount of time at all, but is low priority.

An addition to this at a later date could be to fill the free code space with jump instructions to run this code, however the chance of hitting such space is currently around 50% and dropping daily. It will approach zero in the medium term, so I deem that change ineffectual and a waste of time. (nice idea for a lightweight unreliable app though).
49 Firmware Protocol feature N/A 2008-11-12 09:16 2008-11-12 09:16 Fred sry_not4sale normal assigned none none open 0 Generate Messages To Send Data I have reception of packets for sending data to ram and flash (pending seans code) in source control. When I release this code (directly or publicly) you will have all you need to bring the app to life with settings and dialogs and tabs etc.
8 Ignition / Injection Scheduler major always 2008-10-29 12:35 2008-11-03 10:08 Fred Fred low assigned major rework > 1 month 0.0.16-FlashGordon open 0 PIT Based Ignition Control Broken The current experimental PIT based ignition code is not usable at all. It has shown some promise, but requires a significant investment of time to make reliable.
Fred 2008-11-03 10:08 Details of what is currently known to be wrong with it :

* Gathers a cumulative error in queued mode
* Sticks at high dwells
* Gets out of sequence when a spark event is missed
* Can't dwell long enough at various speeds and advances

Possibly other things too.
27 Flash Burning feature N/A 2008-11-02 18:53 2008-11-02 18:53 Fred sean94z low assigned none none open 0 Create EEPROM Write Functions It would be nice if we had access to the EEPROM for recording stuff while running, a sort of rolling datalog even.

These should be written in C with the usual GPL header file format etc.

I would imagine this would be a lot easier than the flash stuff due to being pure C and not having to sod around with memory management etc.

The following should be available :

* write word (this is the raw unit of eeprom)
* write byte (wrapper for write word that reads one byte out first and puts it and the new one back)
* write block (takes care of the misalignment without complaining and can write any size of block inside the EEPROM area)

We need to take care of the EPAGE register, perhaps internally or perhaps externally, I'm not sure which makes sense as I haven't read the docs thoroughly.
24 Schematics minor have not tried 2008-11-02 12:33 2008-11-02 17:16 davebmw davebmw low assigned none none open 0 Produce a working design for Knock detection for implementation on first spin of FreeEMS type B.
To be trialled and researched on my BMW M50 using both bosch oem knock sensors, the design should contain the following features:
1, Ignition timing derived knock sense window and sensor selection.
2, Op Amp based bandpass filter 4KHz to 7KHz.
3, Automatic Gain control based on RPM.
4, Single digital "Knock Detected" output (for immediate MS2 trials)
5, Dual Analog output pre-comparator for later implementation through ADC Channel.
 Variables for user tuning to suit application:
1, AGC gain and range.
2, Bandpass filter roll off points.
3, Knock detect threshold point.
Tuning apperatus required:
Tuning forks?
MS2 with a dodgy map.
Stethoscope.
Laptop based sound card scope with logging facility.
Fred 2008-11-02 17:16 Discussion at :

http://www.diyefi.org/forum/viewtopic.php?f=9&t=480 [^]
26 Other major N/A 2008-11-02 17:16 2008-11-02 17:16 AbeFM AbeFM normal assigned prototype none none open 0 Complete testing of Low-Z Injector Driver Having built provided circuit and found currents incorrect and FET's overheatings, the circuit needs rebuilding with a higher ohmage sense resistor.

The FET is my problem for not sinking it, the off currents need to be addressed.
Link to original thread:
http://www.diyefi.org/forum/viewtopic.php?f=9&t=378&st=0&sk=t&sd=a [^]

With schematic as tested here:
http://www.diyefi.org/forum/viewtopic.php?f=9&t=378&st=0&sk=t&sd=a&start=11 [^]

And parts list:
http://www.diyefi.org/forum/viewtopic.php?f=9&t=378&st=0&sk=t&sd=a&start=69 [^]
25 General Features feature have not tried 2008-11-02 14:58 2008-11-02 15:08 Fred AbeFM low assigned none none open 0 Write General Purpose PID Function A good PID controller algorithm is required for various tasks including but not limited to :

Idle speed control
Oxygen feedback
Boost control

I feel that this should be generic with a predefined struct holding state for each purpose and a pointer to a struct passed in to be acted upon based on other global variables.

The first stage is requirement gathering, once it is clear what is required a design should be drawn up and only after that should any code be written to perform this task.

Having only one copy of this logic will ensure that we have better reliability consistency and testing.
Fred 2008-11-02 15:08 The existing PID discussion thread :

http://www.diyefi.org/forum/viewtopic.php?f=8&t=186 [^]

A new thread for discussing requirements :

http://www.diyefi.org/forum/viewtopic.php?f=8&t=486 [^]
9 SourceForge Web Space minor N/A 2008-10-29 14:30 2008-11-01 12:10 Fred jharvey low assigned none none open 0 Create Initial SourceForge Web Space Page Once this is ready the redirect should be removed and this page should be displayed.

As I see it the first version of the FreeEMS website should have the following aspects :

* Summary of the project
* The diyefi.org main page
* Doxygen linked from somewhere
* The wiki on this server linked from somewhere
* This tracker linked from somewhere obvious
* The downloads section of sourceforge linked somewhere obvious
* The meta FreeEMS forum section on diyefi linked from somewhere obvious :

http://www.diyefi.org/forum/viewforum.php?f=19 [^]

It isn't too high a priority right now, but as time moves on the priority will grow. Many thanks to Jared for the work done in this regard so far!
Fred 2008-10-29 14:32 Sub task for me to do once this is complete :

* Move the redirect from freeems.org to point at sourceforge instead.
* Link to the new page from diyefi.org

Fred.
19 Schematics minor N/A 2008-10-31 09:38 2008-11-01 12:10 Fred jharvey normal assigned none none open 0 Update Schematics To Be Inline With Hardware Spec Once the pin out and hardware interface docs are released in their updated form, bring the schematics (and therefore pcb) into line with them.
6 Other major always 2008-10-29 11:31 2008-10-31 11:41 Fred sry_not4sale high assigned none none open 0 Create normal severity so that this request and others can be assigned to it. As per summary, also, make it default if possible.

Cheers :-)		 (I believe this needs you to edit files? could be wrong...)
Fred 2008-10-31 09:41 What do you think about adding "In Progress" and "Deferred" or "On Hold" to the status list? I'd like to see them there, how about you?
Fred 2008-10-31 11:41 For in progress etc, perhaps a new custom field would be better?

then it can be assigned and in progress or assigned and on hold/deferred.

Thoughts?
14 SourceForge Web Space minor N/A 2008-10-29 19:58 2008-10-29 20:02 Fred FE3tMX5 none assigned none > 1 month open 0 Come Up With An Awesome Logo For FreeEMS.org As the title says :-) No rush on that, it won't be important for at least a few months, probably more.

As discussed, something carry, something GNUy, something CPUy, pretty much anything, all of those three are optional and just random thoughts really :-)
Fred 2008-10-29 20:00 Welcome to the official FreeEMS contribution tracking task sharing all knowing fun having collaborative tool :-)
7 Ignition / Injection Scheduler major N/A 2008-10-29 11:48 2008-10-29 17:03 Fred Fred low assigned redesign > 1 month open 0 Replace Scheduling Code The current "scheduling code" is very basic and not overly useful in a generic way. I need to split the boot configuration, dynamic scheduling and schedule actioning out into appropriately generic modules of code. This will facilitate multiple decoders on top of a single scheduling interface and enable easy swapping between them. I have a design for this in my head and will put it into a formal spec as I create the interface and code.
12 Structure / Style minor N/A 2008-10-29 17:01 2008-10-29 17:01 Fred Fred low assigned none none open 0 Remove Most/All Literals From The Code There are currently quite a few literals in the code base. They were only put there as quick tests and trials during development and should not be present now. Most all all literals should be present only as #defines or const variables. All flags should be created ONLY using the pre defined bit fields such as BIT3 and NBIT7 (for the switching off).
2 Permissions feature N/A 2008-10-28 22:09 2008-10-29 12:02 sry_not4sale sry_not4sale low assigned none none open 0 Set up single-sign-on, or at least shared logins FreeEMS has a number of admin web tools, and it would be nice to have one login across them all...

- Forum
- Wiki
- Bug Tracker
sry_not4sale 2008-10-28 22:13 Mantis Bug Tracker and docuwiki SSO:

http://www.mantisbt.org/wiki/doku.php/mantisbt:issue:7075:integration_with_dokuwiki [^]
98 Firmware Protocol major N/A 2009-02-16 20:07 2009-09-02 21:41 sry_not4sale sry_not4sale high confirmed none none 0.1 fixed 0 Protocol Unit Test Framework Old bugs are coming back, and it's getting hard to test specific packets/combinations.

We need some sort of test framework where binary strings can be supplied and the apps output can be compared to what is expected.

Also the possibility of speed testing.
47 Features Requests minor N/A 2008-11-11 11:24 2009-09-02 21:36 Fred sry_not4sale normal confirmed none none open 0 Error Code To Description Config/Mapping And Display When an error code is received the number should be used to look up a description string to display in a dialog or console of some sort. Internal counters that display how many of each type are recorded would be good too.
35 Documentation minor N/A 2008-11-04 00:06 2009-09-02 21:35 sry_not4sale sry_not4sale low confirmed none none open 0 Document protocol plugin interface Please please.

Part of this will also be GUI element dependencies
34 Documentation minor N/A 2008-11-04 00:05 2009-09-02 21:34 sry_not4sale sry_not4sale normal confirmed none none open 0 Document comms plugin interface Please please :)
33 Documentation major N/A 2008-11-04 00:04 2009-09-02 21:34 sry_not4sale sry_not4sale high confirmed none none open 0 Document coding conventions Document please, probably base it on the python coding standards
43 Configuration / Settings feature N/A 2008-11-09 21:20 2009-09-02 21:31 sry_not4sale sry_not4sale low confirmed none none 0.2 open 0 Config GUI Mainly for comms at this stage, but this seems to be a common request
58 Features Requests minor N/A 2008-11-16 13:39 2009-09-02 21:40 Fred sry_not4sale normal acknowledged none none open 0 Yellow Reset Button I would like to be able to reset the device into the firmware out of the serial monitor.

Discussion on the forum required. Will update with more info when that occurs.
Fred 2008-11-16 14:13 http://www.diyefi.org/forum/viewtopic.php?f=43&t=500 [^]

Interrogation discussion (closely linked to this)
BenFenner 2008-11-23 21:06 Instructions from Fred:

When the serial monitor code is running on the hardware and my code is not, the serial communication protocol is totally different.

The idea is to not have to turn the key off to reset the device between states. And to not have to use a physical reset switch. Just to move the monitor switch and hit a button on the software.

I think I detailed the required commands in the interrogation thread and the mantis issue?

You need to start comms by sending a CR char and then turn on the COP monitor which will reset the device. Turning on the COP monitor is just a matter of writing a value to a register. The SM can write to any memory location so you can just do that and it will reset.

Fred.
Fred 2008-11-23 21:31 Aaron, if you do this as part of the interrogation thread it should probably only be a button for testing in the short term with the software knowing what state the device is in at any given time and when found in SM state offering to reset out of it (or load new firmware one day) with a dialog box or something. It would still be nice to have, but certainly is low priority.
67 User Interface minor always 2008-11-19 21:23 2009-09-02 21:40 Fred sry_not4sale normal acknowledged none none open 0 Scroll Events Ignored In Main Tab As the title says :-) I scroll, it doesn't move.
sry_not4sale 2008-11-19 21:25 Are you referring to the serial grid?

Using a mouse scoll wheel or dragging scroll bars?

Do both methods not work?

Vertically or horizontally?

Thanks :)
Fred 2008-11-19 21:36 :-p

main tab, mouse wheel no worky, scroll bar works fine.

update : debug log tab both work fine

Welcome ;-)
46 Features Requests minor N/A 2008-11-11 11:22 2009-09-02 21:39 Fred sry_not4sale normal acknowledged none none open 0 Debug Message Console Parse debug packets and create something to display them sequentially perhaps with a time stamp, one per line. Dumping to the console the app is running from is acceptable too. Or both configurable.
sry_not4sale 2008-11-16 20:58 Whats a debug packet?
Fred 2008-11-16 21:18 RTFM ;-) Literally. It's a variable length packet that always has a length header field and has a body that is all string with a null termination char. It's like system.out.println for freeems. I'd say just add them to that new debug log tab as EMS-DEBUG or something similar with a pair or quotes or [] around them to make it obvious what part of the line the message is.
62 Features Requests minor N/A 2008-11-16 20:41 2009-09-02 21:38 Fred sry_not4sale normal acknowledged none none open 0 Port Control Screen And Packets Obviously I need to write the firmware side for this too, but it would be immensely useful to be able to configure the IO from a dedicated tab in the GUI.

I think the format should be:

send (full state for all pins)
receive (full state for all pins)

At start up the GUI should query the device to find out the current state. Or perhaps it could be on a user config basis?

The tab in question will need a sub section for each port and a set of columns or rows or check boxs for the bits in each control register. There should be some sort of LED indicator for each pin to show the actual state received after the update is made. I guess it should be sent on a per click/adjustment basis in real time. There could/should be another LED saying that the state of the pin and the settings don't match.

This will be enormously useful in understanding the hardware better as it will enable me to test various theories without soldering new stuff up.

You won't be able to do much with it until I provide the details or what you should be able to control and how the packets should look, but have a think about it. it might be a case of just writing large blocks of registers with memcpy on my end, or maybe i will need to be more explicit.

This is a good task for me on the train so look for some results later this week. This of course relies on the comms reception working properly, so that takes priority for sure.

I've been working on the pin out stuff tonight, but it is tough going. it would be nice if I could configure things on the fly to test out some theories.

This type of packet could be used to implement various control strategies on the PC side where it is easier to write complex code and then migrate them to the firmware when well tested and debuged. Stuff like PID idle and what have you could all start life on the PC side using this interface.

In the long term it could be a very valuable debug tool when there are hardware and wiring issues etc. Well worth doing in my opinion. Quite easy too bar laying out the gui.
59 Comm Interface feature have not tried 2008-11-16 14:16 2009-09-02 21:38 Fred sry_not4sale normal acknowledged none none open 0 Create Interrogation Routine http://www.diyefi.org/forum/viewtopic.php?f=43&t=500 [^]

The program needs to be able to determine what it is connecting to and not corrupt the SM or a MS if they are present. It also needs to be able to determine which versions of each are present on the far end of the cable and load the appropriate code for them at that time.
57 User Interface feature N/A 2008-11-15 20:36 2009-09-02 21:37 Fred sry_not4sale low acknowledged none none open 0 Full Screen Mode For Use On Small Screens It would be nice if it could do a true full screen mode and claim every pixel for itself. This would be most useful on a little screen like the EEE which a lot of people may use to tune with.

Just a thought :-) You did say to put it all in here.
56 User Interface minor always 2008-11-15 20:13 2009-09-02 21:37 Fred sry_not4sale low acknowledged none none open 0 Give It the DIYEFI Logo :-) Here is the .ico file for the website, gimp can turn it into a png or whatever you want.

http://www.diyefi.org/favicon.ico [^]

I just realised that it has no display icon and in the EEE it comes up with the ugly red X logo as default.

No big deal, perhaps you want your own logo there, or the FreeEMS one when Rob designs it :-)



http://i260.photobucket.com/albums/ii15/diyefi/FreeEMS-Tuner/stillBadOnEEE.png [^]
55 User Interface minor always 2008-11-15 20:10 2009-09-02 21:37 Fred sry_not4sale normal acknowledged none none open 0 Good Default Min Sizes For Components And Windows Certain things like columns and what have you should have appropriate default and min sizes to display cleanly. You shouldn't be able to make the window size smaller than those figures, at least not without a scroll bar.

I think it should default to cleanly displaying all the components visibly.

Feel free to reject if you disagree :-)

I'm just trying to get to a place where I just git pull and make no adjustments each time I run it... could save me a few seconds here and there :-)

Screeny : http://i260.photobucket.com/albums/ii15/diyefi/FreeEMS-Tuner/stillBadOnEEE.png [^]
51 User Interface feature N/A 2008-11-12 09:26 2009-09-02 21:37 Fred sry_not4sale normal acknowledged none none open 0 Investigate And Maybe Create A Parser For MTX Gauge Definitions Open source means leveraging other peoples work :-)

It would be really cool/nice if we could use the same gauge definitions as MTX uses and therefore the designer that comes with it too. It may be that this is not practical at all, however it is a very nice feature and compatibility with them would be good to have :-)

See the latest MTX for examples and code on how they are used internal to that app.
50 Firmware Protocol feature N/A 2008-11-12 09:24 2009-09-02 21:36 Fred sry_not4sale normal acknowledged none none open 0 Datalog Parsing Based On Config Soon datalog packets will be available for parsing and displaying. This is core functionality to the tuning app. The data sent in the complex log will be configurable on the EMS side. The basic structure will be something like :

* A meta mask - where each bit indicates that a block of data is sent or not sent
* Sub masks - where each bit indicates that a particular field is sent or not

Which byte/short/long gets parsed into which internal value for display and logging is dependent on these masks.

Additionally, the user may want the ability to further filter these into a subset log for easier viewing and lower storage space while retaining a full log elsewhere, this is just a wild idea though :-)

I think the datalog files should be MS/MLV compatible for easy up front tooling. Later we can create an app to parse our logs (and ms ones) ourselves at which point the format *could* be changed.

Reliant on this parsing is general display of these values in bar graphs and on gauges.
44 Comm Interface minor N/A 2008-11-10 23:40 2009-09-02 21:35 Fred sry_not4sale normal acknowledged none none open 0 Make It Version Aware Make it query the interface version to choose which config to use/code to run etc and query the firmware version to be able to display it for the user. These are key to multi version support and a good user experience.
37 Features Requests minor N/A 2008-11-04 22:07 2009-09-02 21:35 Fred sry_not4sale normal acknowledged none none open 0 Ability To Select From Multiple Serial Devices A menu selection for the serial device to use would be a nice low priority feature to have.
sry_not4sale 2008-11-04 22:21 Pull from list in config file
22 Features Requests feature N/A 2008-11-01 23:15 2009-09-02 21:34 Fred sry_not4sale low acknowledged none none open 0 The Ability To Load New Firmware It might be nice in the future for the same gui to support upgrades as well.

See http://freeems.aaronb.info/tracker/view.php?id=21 [^] for more info.

Additional nice things an integrated version *could* do are move settings between releases in an automated or semi automated way.

Things that could move quite safely between releases (probably) include :

Main tuning tables
Thermistor tables

Definitely low priority on this, but something to think about :-)
64 Features Requests minor N/A 2008-11-16 22:41 2009-09-02 21:33 Fred sry_not4sale high acknowledged none none open 0 Allow Option To Not Blow Away Log On Restart It would be nice if the history was a bit longer than the 15 seconds since the last launch ;-)

Either rotating logs or just append and append with maybe a shutdown line to break it up or something?

Your call :-)
Fred 2008-11-28 01:49 This just got more important. It just blew away 5 mins of getting packet data...

configurable to append or rotating on startup.

Pretty please? :-)
78 User Interface feature N/A 2008-11-30 19:39 2009-09-02 21:33 Fred sry_not4sale low acknowledged none none open 0 Ability to lock the table switching tables together What I mean by this is that you probably want your two tunes to match. A check box on a per table/field/chunk basis that says sync or different might be nice.

Another way to do it, or as well as this would be to have a sync dialog where you select the fields you want to sync up and then hit burn.

Of course, this comes after the the basics are in place such as reliable comms and decoding of packets and interrogation and display of things in a basic way with editing and sending back.
87 Features Requests feature N/A 2008-12-22 20:14 2009-02-15 08:28 Fred sry_not4sale normal acknowledged none none 0.1 open 0 Tab with 8 generic packet types Please create a tab with 8 buttons and 8 text entry fields.

The packets sent should always use a length header component as you won't know what is going to be sent.

The payload of the packets will be parsed from a comma separated list of integers in either hex or decimal. The user will type that in manually such that they can enter a single byte, a single word (as two bytes) or a longer data block. If the parse errors, perhaps pop up a dialog or make the field go red or something?

The payload IDs for these "test packets" are as follows :

/* 8 payload IDs for testing purposes */
#define testPayloadIDPacketType0 65520
#define testPayloadIDPacketType1 65522
#define testPayloadIDPacketType2 65524
#define testPayloadIDPacketType3 65526
#define testPayloadIDPacketType4 65528
#define testPayloadIDPacketType5 65530
#define testPayloadIDPacketType6 65532
#define testPayloadIDPacketType7 65534

As usual, returned packets will be the next highest odd integer, though you won't have to deal with this as they can just be treated as unknown packets like any other unknown.

Good luck, may the GIT be with you :-)
95 Documentation minor N/A 2008-12-25 22:39 2009-01-02 14:59 Fred Fred normal acknowledged none none open 0 Update existing docs to work better with Doxygen The existing documentation can be easily updated to work better with Doxygen. I should get onto doing that over the next 2 weeks or so. All or at least most functions should have a Doxygen compatible comment in front of them.
Fred 2009-01-02 14:59 This has been started and is currently underway.
45 User Interface feature N/A 2008-11-11 02:07 2008-11-28 08:06 Fred sry_not4sale normal acknowledged none none open 0 Table and 3d Views for Main Tables The ability to view and edit main tables based on the table structure received and sent. The packets need parsing first to do this, so consider that part of this task/issue/request.
15 Firmware - Hardware Interface block N/A 2008-10-31 09:23 2008-11-16 23:01 Fred Fred high acknowledged none < 1 month 0.0.16-FlashGordon open 0 Update The Pin Out Document As I see it this task is to :

* Research and check the pin states during run, reset and bootload
* Update the master ODS pinout spread sheet document with this information
* Re-read the pin polarity thread and determine the best approach to ensuring safe pin states under all conditions
* Create a document detailing the specifications that a schem/pcb design must adhere to in order to be deemed FreeEMS compatible (IE, safe for general use by noobs and 100% compliant with the firmware behaviour) - Dave and Jared and others should collaborate on this.
* Publish all of this information to aid Jared and Dave in making progress on their hardware designs in a future proof way

Once I have this completed Dave will probably need to generate a PDF version of the ODS document for Jared. Alternatively Jared could just install OpenOffice.org on his machine :-p ;-)

Note, it is acceptable for private/specific purpose board designs to deviate from the standard, but main stream designs should adhere to it as a good example for others to follow.
Fred 2008-10-31 09:26 Dave and Jared are waiting on this and require it to make further progress in a meaningful and useful way. I should complete this at the earliest opportunity.
Fred 2008-10-31 09:40 Also to be updated is the hardware firmware interface document. This is part of the same task in effect so it can just be part of this one.
Fred 2008-11-16 23:01 Worked on this tonight, and will work on it again tomorrow and so on until it is done :-)
18 Schematics minor N/A 2008-10-31 09:37 2008-11-01 03:21 Fred davebmw normal acknowledged none none open 0 Update Schematics To Be Inline With Hardware Spec Once the pin out and hardware interface docs are released in their updated form, bring the schematics (and therefore pcb) into line with them.
103 User Interface minor N/A 2009-09-02 11:09 2009-09-16 15:53 sry_not4sale sry_not4sale normal feedback none none open 0 Improve UI for realtime data Currently it is hard to scan across a row and see the relevant value for a variable...

Also the white column is a bit hideous
BenFenner 2009-09-16 15:53 When you mentioned this I immediately realized what I'd done wrong in designing this (if it was in fact me).

Having bar gauges fill from right to left is just natural for me (US resident). But then again, having the labels on the left is also natural.
Here is my proposal. Either A or B would be fine I think and I can't see a real difference in readability between them from.

Proposal A.


......................MAP..[-----..............]
.......................IAT..[-----------.....]
..............Ign Timing..[------------....]
.................Idle Pos..[----------.......]
......................TPS..[--..................]
.....................EGT1..[------------....]

Proposal B.


......................[.............-----]..MAP
......................[.....-----------]..IAT
......................[....------------]..Ign Timing
......................[.......----------]..Idle Pos
......................[..................--]..TPS
......................[....------------]..EGT1


Get it? (I had to use dots instead of spaces so the formatting would not get messed up by the filter.) The display should be centered, and the labels and graphs should be butted up against each other in the exact center of the display. Actual values can either be displayed inside the bar graphs, or after the bar graphs, or in between the label and the bar graph in the exact center. I haven't looked at the way it's done right now in a long time, so I'm not being as specific as I might normally be.

60 Comm Interface crash have not tried 2008-11-16 14:42 2009-09-02 21:39 Fred sry_not4sale normal feedback none none open 0 Serial Comms Funnies Cause Hard Freeze A while ago I noticed that I could connect both cute comm and this to the serial port at the same time. This is unusual in itself and probably related as most apps lock the device for exclusive use by default. Today I had cutecom listening and tuner talking which was fine. Then I disconnected cutecom and sent another packet and it locked up solid using lots of cpu. open connection with cutecom
open connection with freeems tuner
send data with tuner
disconnect cutecom
send data with tuner		 It was dumping a lot of these out before dying (while both connected) :

<LogRecord: serial.FreeEMS_Vanilla, 40, /home/fred/ben/protocols/FreeEMS_Vanilla/0_0_17.py, 163, "Bad/incomplete data found in buffer before start byte: E0">
<LogRecord: serial.FreeEMS_Vanilla, 40, /home/fred/ben/protocols/FreeEMS_Vanilla/0_0_17.py, 163, "Bad/incomplete data found in buffer before start byte: E0">
<LogRecord: serial.FreeEMS_Vanilla, 40, /home/fred/ben/protocols/FreeEMS_Vanilla/0_0_17.py, 163, "Bad/incomplete data found in buffer before start byte: E0">
<LogRecord: serial.FreeEMS_Vanilla, 40, /home/fred/ben/protocols/FreeEMS_Vanilla/0_0_17.py, 163, "Bad/incomplete data found in buffer before start byte: E0">
Fred 2008-11-16 14:45 Related to this is the thing where the gui is locked while receiving data. I'd like to understand that a bit better as it seems like the gui should be a thread (or more) and the reception and sending should be a thread each. Serial transmission is slow and binding up during that seems like a bad idea. Perhaps I have a poor understanding of it at the moment?
BenFenner 2008-11-16 15:06 Stop trying to break shit on purpose. ;)
sry_not4sale 2008-11-16 20:33 The incomplete data in the buffer message is because there is a constant stream of 0xE0 bytes coming through.

Sounds like a cutecom issue (of course... its never my code... :P).

Although its definitely worth either moving the receive code into a thread or at least limiting the amount of bad bytes it will loop through at a time.
Fred 2008-11-16 20:53 Well, you may say this, but cute com and minicom don't allow hcs12mem to talk and your com library does :

FLASH erase: wait ...
FLASH erase: memory erased
Erasing flash was successful!
Load the firmware to your FreeEMS? [ yes | abort ]
abort
Thank you for choosing the FreeEMS to run your engine, goodbye.
fred@rwdlsd:~/workspaces/home/freeems/src$ ../bin/freeEMSloader.bash /dev/ttyUSB0 zoutput/freeems-v0.0.18.s19
Welcome to the FreeEMS firmware loader

This program is released under the GPL V3
Please see http://www.gnu.org/licenses/ [^] for details

This version is for mc9s12xdp512 based FreeEMS's

Do you have a mc9s12xdp512 based FreeEMS? [ yes | quit ]
yes
Checking configuration and arguments...
Everything looks good!
Erase the flash on your FreeEMS? (This is necessary to load new firmware) [ yes | abort ]
yes
Erasing the FreeEMS flash without verification...
hcs12mem: Freescale S12 MCU memory loader V1.4.1 (C) 2005-2007 Michal Konieczny <mk@cml.mfk.net.pl>

target info <single chip MC9S12XDP512 MCU>
target mcu <MC9S12XDP512> family <S12X>
SM serial port </dev/ttyUSB0> baud rate <115200 bps>

error: timeout - no connection with target
Erasing flash failed! exiting...

I don't necessarily think this issue is your code, but quite possibly the library.

As for the threading discussion, consider the situation where their is a constant stream of data coming in from the port. Will it lock up solid for that? Or will it continue to smoothly display graphs and user actions etc?

Thoughts?
100 Controller / Threading major have not tried 2009-09-02 09:00 2009-09-02 09:00 sry_not4sale normal new none none open 0 Random exceptions on shut down I think caused by the threads not being closed properly? Always occur in the controller it seems - hard to reproduce as the exceptions are different each time.
13 Auxiliary Task Scheduler minor N/A 2008-10-29 17:18 2008-10-29 17:18 Fred normal new none none open 0 Non Time Critical Non Preemptive Task Scheduler A task scheduler needs to be written for things like idle pwm updates etc.

It would be nice if it had some intelligence to it. Features like priority, period, runtime, and a pointer to a function to handle it would all be nice to have.

Note, this will not be a pre-emptive scheduler as there are no interrupts to trigger such behaviour and no time for context switching. The master plan is that the fuel calculation code runs first always and the scheduler runs some jobs after that and if that doesn't run it runs even more jobs instead of it.

Some discussion has occurred on the forum here :

http://www.diyefi.org/forum/viewtopic.php?f=8&t=77 [^]

And the wikipedia page on RTOS scheduling is worth a read too :

http://en.wikipedia.org/wiki/Real-time_operating_system#Scheduling [^]

This task is free for any developer to pick up and run with. We don't need this particularly soon, but it will definitely be a requirement to keep fuel latency low once we pick up more than just a basic feature set.