Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
105	[Firmware] Initialisation / Configuration	block	always	2009-10-15 21:58	2009-10-19 07:10
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:	0.0.20 pre-release	Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Table data appears to be wrong!
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000169) 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 :-/
(0000170) Fred    2009-10-19 07:09	Confirmed fixed!
(0000171) Fred    2009-10-19 07:10	Found init code issue and fixed. Tested by Cam.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
63	[DIYEFI.org website] Main Site	block	random	2008-11-16 20:59	2009-10-13 16:25
Reporter:	sry_not4sale	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	People still using MegaSquirt
Description:	Please fix ASAP
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000083) Fred    2008-11-16 21:42	eye eye sir!!
(0000168) Fred    2009-10-13 16:25	An engine has now run on FreeEMS. That is the first step, more to come soon.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
99	[Firmware] Serial Communications	block	always	2009-02-22 16:34	2009-02-22 18:24
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	urgent	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Corrupt packets are sent when RPM interrupts are active
Description:	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.
Steps To Reproduce:	Receive data stream from device Apply RPM signal with JimStim to device
Additional Information:	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
Attached Files:

Notes
(0000155) 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.
(0000156) 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.
(0000157) Fred    2009-02-22 17:26	Removal of fuel code didn't help either. ADC sampling is next to go.
(0000158) 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.
(0000159) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
65	[FreeEMS-Tuner] Firmware Protocol	block	have not tried	2008-11-18 21:38	2008-11-19 20:54
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Code could cause first part of a packet to disappear
Description:	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!
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000085) Fred    2008-11-18 21:40	Save your chat log, it tells you exactly how to fix that and other subtle issues ;-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
15	[Firmware] Firmware - Hardware Interface	block	N/A	2008-10-31 09:23	2008-11-16 23:01
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	acknowledged	Product Version:	0.0.16-FlashGordon
Product Build:		Resolution:	open
Projection:	none
ETA:	< 1 month
Issue Type:	Task
Summary:	Update The Pin Out Document
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000016) 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.
(0000018) 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.
(0000084) Fred    2008-11-16 23:01	Worked on this tonight, and will work on it again tomorrow and so on until it is done :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
17	[Firmware] Documentation	block	N/A	2008-10-31 09:33	2008-11-11 10:55
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	minor fix
ETA:	< 1 month
Issue Type:	Task
Summary:	Update Comms Documents To Reflect Current Reality
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000017) 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.
(0000069) Fred    2008-11-11 10:55	This was completed (except implementation doc) and released on 0.0.17

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
16	[Firmware] Serial Communications	block	N/A	2008-10-31 09:29	2008-11-11 10:52
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	major rework
ETA:	2-3 days
Issue Type:	Task
Summary:	Refactor The Serial Comms Code
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000029) Fred    2008-11-02 08:24	1/4 done as of last night, working on it again today.
(0000032) 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.
(0000033) 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.
(0000046) 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.
(0000064) 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.
(0000068) Fred    2008-11-11 10:52	This work was completed and released in 0.0.17

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4	[Firmware] Build Process	block	always	2008-10-29 10:42	2008-10-31 09:08
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	.vector and .bss overlap during the link
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000010) 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.
(0000015) 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 :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
60	[FreeEMS-Tuner] Comm Interface	crash	have not tried	2008-11-16 14:42	2009-09-02 21:39
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Serial Comms Funnies Cause Hard Freeze
Description:	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.
Steps To Reproduce:	open connection with cutecom open connection with freeems tuner send data with tuner disconnect cutecom send data with tuner
Additional Information:	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">
Attached Files:

Notes
(0000075) 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?
(0000076) BenFenner    2008-11-16 15:06	Stop trying to break shit on purpose. ;)
(0000077) 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.
(0000078) 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?

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
98	[FreeEMS-Tuner] Firmware Protocol	major	N/A	2009-02-16 20:07	2009-09-02 21:41
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	confirmed	Product Version:	0.1
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Protocol Unit Test Framework
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
33	[FreeEMS-Tuner] Documentation	major	N/A	2008-11-04 00:04	2009-09-02 21:34
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Administration
Summary:	Document coding conventions
Description:	Document please, probably base it on the python coding standards
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
101	[FreeEMS-Tuner] Comm Interface	major	have not tried	2009-09-02 09:12	2009-09-02 09:12
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Pressing cancel at the Choose comms log file dialog doesn't cancel
Description:	It acts as if you pressed OK
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
100	[FreeEMS-Tuner] Controller / Threading	major	have not tried	2009-09-02 09:00	2009-09-02 09:00
Reporter:	sry_not4sale	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Random exceptions on shut down
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
52	[Firmware] Analog Input Config & Processing	major	N/A	2008-11-15 13:49	2008-12-18 13:01
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:	0.0.17-SpudEchoes
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Investigate Using Pointers For Variable Banking
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000131) 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!

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
39	[FreeEMS-Tuner] Comm Interface	major	N/A	2008-11-04 22:19	2008-11-05 23:09
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	won't fix
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Dump raw bytes to file
Description:	Dump all sent packets to file
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000051) sry_not4sale    2008-11-05 23:09	Don't think this is really necessary with the raw output in the commsDiagnostics ui element

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
28	[Firmware] Ignition / Injection Scheduler	major	random	2008-11-03 10:13	2008-11-03 10:14
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:	0.0.1-To-0.0.9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	PORTA and PORTB get written to randomly after program runs for some time
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000035) Fred    2008-11-03 10:14	Fixed some time ago, just creating permanent record of old bugs.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
8	[Firmware] Ignition / Injection Scheduler	major	always	2008-10-29 12:35	2008-11-03 10:08
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:	0.0.16-FlashGordon
Product Build:		Resolution:	open
Projection:	major rework
ETA:	> 1 month
Issue Type:	Bug
Summary:	PIT Based Ignition Control Broken
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000034) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
26	[Hardware-Jared] Other	major	N/A	2008-11-02 17:16	2008-11-02 17:16
Reporter:	AbeFM	Platform:
Assigned To:	AbeFM	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:	prototype	Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Complete testing of Low-Z Injector Driver
Description:	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.
Steps To Reproduce:
Additional Information:	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 [^]
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
6	[Bug Tracker] Other	major	always	2008-10-29 11:31	2008-10-31 11:41
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Create normal severity so that this request and others can be assigned to it.
Description:	As per summary, also, make it default if possible. Cheers :-)
Steps To Reproduce:
Additional Information:	(I believe this needs you to edit files? could be wrong...)
Attached Files:

Notes
(0000019) 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?
(0000020) 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?

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
7	[Firmware] Ignition / Injection Scheduler	major	N/A	2008-10-29 11:48	2008-10-29 17:03
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	redesign
ETA:	> 1 month
Issue Type:	Task
Summary:	Replace Scheduling Code
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
103	[FreeEMS-Tuner] User Interface	minor	N/A	2009-09-02 11:09	2009-09-16 15:53
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	feedback	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Improve UI for realtime data
Description:	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
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000167) BenFenner    2009-09-16 15:53    (edited on: 2009-09-16 15:58)	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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
104	[FreeEMS-Tuner] User Interface	minor	have not tried	2009-09-08 09:36	2009-09-08 09:37
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Add datalog sample rate display
Description:	datalog packets/second
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
58	[FreeEMS-Tuner] Features Requests	minor	N/A	2008-11-16 13:39	2009-09-02 21:40
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Yellow Reset Button
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000073) Fred    2008-11-16 14:13	http://www.diyefi.org/forum/viewtopic.php?f=43&t=500 [^] Interrogation discussion (closely linked to this)
(0000091) 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.
(0000092) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
67	[FreeEMS-Tuner] User Interface	minor	always	2008-11-19 21:23	2009-09-02 21:40
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Scroll Events Ignored In Main Tab
Description:	As the title says :-) I scroll, it doesn't move.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000088) 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 :)
(0000089) 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 ;-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
46	[FreeEMS-Tuner] Features Requests	minor	N/A	2008-11-11 11:22	2009-09-02 21:39
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Debug Message Console
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000080) sry_not4sale    2008-11-16 20:58	Whats a debug packet?
(0000082) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
62	[FreeEMS-Tuner] Features Requests	minor	N/A	2008-11-16 20:41	2009-09-02 21:38
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Port Control Screen And Packets
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
56	[FreeEMS-Tuner] User Interface	minor	always	2008-11-15 20:13	2009-09-02 21:37
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Give It the DIYEFI Logo :-)
Description:	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 [^]
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
55	[FreeEMS-Tuner] User Interface	minor	always	2008-11-15 20:10	2009-09-02 21:37
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Good Default Min Sizes For Components And Windows
Description:	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 [^]
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
47	[FreeEMS-Tuner] Features Requests	minor	N/A	2008-11-11 11:24	2009-09-02 21:36
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Error Code To Description Config/Mapping And Display
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
44	[FreeEMS-Tuner] Comm Interface	minor	N/A	2008-11-10 23:40	2009-09-02 21:35
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Task
Summary:	Make It Version Aware
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
37	[FreeEMS-Tuner] Features Requests	minor	N/A	2008-11-04 22:07	2009-09-02 21:35
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Ability To Select From Multiple Serial Devices
Description:	A menu selection for the serial device to use would be a nice low priority feature to have.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000047) sry_not4sale    2008-11-04 22:21	Pull from list in config file

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
35	[FreeEMS-Tuner] Documentation	minor	N/A	2008-11-04 00:06	2009-09-02 21:35
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Administration
Summary:	Document protocol plugin interface
Description:	Please please. Part of this will also be GUI element dependencies
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
34	[FreeEMS-Tuner] Documentation	minor	N/A	2008-11-04 00:05	2009-09-02 21:34
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	confirmed	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Administration
Summary:	Document comms plugin interface
Description:	Please please :)
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
64	[FreeEMS-Tuner] Features Requests	minor	N/A	2008-11-16 22:41	2009-09-02 21:33
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Allow Option To Not Blow Away Log On Restart
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000102) 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? :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
102	[Firmware] Serial Communications	minor	have not tried	2009-09-02 09:58	2009-09-02 09:58
Reporter:	sry_not4sale	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Need method for discovering status of datalogging
Description:	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
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
81	[Firmware] Serial Communications	minor	always	2008-12-02 23:52	2009-02-22 20:03
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Find a way to remove extra start byte hack.
Description:	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?
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000160) 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.
(0000161) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
82	[FreeEMS-Tuner] Comm Interface	minor	always	2008-12-03 00:09	2009-02-15 10:44
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	escaped bytes handled incorrectly causing checksum to be wrong.
Description:	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
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000147) sry_not4sale    2009-01-13 21:37	Packets were being escaped twice
(0000152) Fred    2009-01-14 05:43	Tested fixed.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
66	[FreeEMS-Tuner] Comm Interface	minor	N/A	2008-11-18 21:39	2009-02-15 08:34
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Fix spelling of receive throughout the code
Description:	Common Aaron... lol
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000086) 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 ;-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
70	[FreeEMS-Tuner] Comm Interface	minor	always	2008-11-28 00:12	2009-02-15 08:33
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Packet parser breaks valid packets up and then complains they aren't valid
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
83	[FreeEMS-Tuner] Comm Interface	minor	have not tried	2008-12-03 00:10	2009-02-15 08:32
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Performance unacceptablely bad and data lost due to this
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
72	[FreeEMS-Tuner] User Interface	minor	always	2008-11-28 00:20	2009-02-15 08:32
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	all logged data should be displayed as hex
Description:	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
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
86	[FreeEMS-Tuner] Configuration / Settings	minor	always	2008-12-18 20:06	2009-02-15 08:28
Reporter:	sean94z	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	unable to reproduce
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	my_config.ini not parsed with default.config.ini
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000146) sry_not4sale    2009-01-13 21:36	Can you confirm this with a fresh install of the tuner? Thanks

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
75	[FreeEMS-Tuner] User Interface	minor	always	2008-11-28 00:50	2009-02-15 08:24
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Fails to display hex for large packet
Description:	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
Steps To Reproduce:
Additional Information:	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
Attached Files:

Notes
(0000150) sry_not4sale    2009-01-13 21:55	Was escaping related, fixed
(0000151) Fred    2009-01-14 05:42	Tested fixed.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
97	[Firmware] Structure / Style	minor	always	2009-02-05 00:34	2009-02-05 00:34
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Find areas where static variables should be used
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
61	[Firmware] Initialisation / Configuration	minor	N/A	2008-11-16 15:03	2009-01-02 15:00
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	assigned	Product Version:	0.0.17-SpudEchoes
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Task
Summary:	Go Through ALL ISR Code And Check For References To TablesA-D RAM Locations
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000095) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
95	[Firmware] Documentation	minor	N/A	2008-12-25 22:39	2009-01-02 14:59
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Update existing docs to work better with Doxygen
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000144) Fred    2009-01-02 14:59	This has been started and is currently underway.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
10	[Firmware] Structure / Style	minor	N/A	2008-10-29 16:28	2009-01-02 14:57
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	low	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Document And Standardise Upon Coding Conventions
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000143) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
11	[Firmware] Structure / Style	minor	N/A	2008-10-29 16:48	2009-01-02 14:18
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Define And Reorganise Header Structure
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000007) 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.
(0000142) Fred    2009-01-02 14:18	Some of this has been done, but much more is required. This is related to mantis 61

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
20	[Firmware] Initialisation / Configuration	minor	N/A	2008-11-01 12:17	2009-01-02 13:58
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Task
Summary:	Move Static Initialisation To Single C File From init.c
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000100) Fred    2008-11-26 22:49	This is half done, needs further investigation.
(0000139) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
96	[Firmware] Documentation	minor	N/A	2008-12-25 22:42	2009-01-02 10:01
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Add configuration and setup for index page to code base
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000138) Fred    2009-01-02 10:01	This is complete and available from the git repo right now.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
94	[Firmware] General Features	minor	always	2008-12-22 22:01	2008-12-22 22:02
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	duplication in itoa functions
Description:	itoa functions have duplicated code as do send unsigned functions
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000137) Fred    2008-12-22 22:02	Added for historical purposes.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
93	[Firmware] Ignition / Injection Scheduler	minor	always	2008-12-22 22:00	2008-12-22 22:00
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	No test at run time for always on
Description:	Forgot to add code run time to test for always on in new code layout.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000136) Fred    2008-12-22 22:00	Added for historical purposes.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
92	[Firmware] Injection / Ignition Calculations	minor	have not tried	2008-12-22 21:57	2008-12-22 21:58
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Code attempting to predict future...
Description:	The logic for injectors staying hard on relied on predicting the future, clearly that was no good :-)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000135) Fred    2008-12-22 21:58	Added for historical purposes.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
91	[Firmware] Ignition / Injection Scheduler	minor	always	2008-12-22 21:55	2008-12-22 21:55
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Logic that causes the injectors to stay hard not taking advance into account.
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000134) Fred    2008-12-22 21:55	Added for historical purposes.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
90	[Firmware] Injection / Ignition Calculations	minor	always	2008-12-22 21:52	2008-12-22 21:54
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Engine cycle period used before valid
Description:	Found and fixed bug present in 0.0.10 and probably earlier where engine cycle period was being used before it was valid.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000133) Fred    2008-12-22 21:54	Added for historical purposes.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
89	[Firmware] Ignition / Injection Scheduler	minor	always	2008-12-22 21:46	2008-12-22 21:47
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	PORTA and PORTB get written to randomly after the program runs for some time.
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000132) Fred    2008-12-22 21:47	Added for historical purposes.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
88	[Firmware] Serial Communications	minor	N/A	2008-12-22 20:18	2008-12-22 20:18
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Refactor serial code into functions to reduce large scale duplication.
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
73	[FreeEMS-Tuner] Firmware Protocol	minor	always	2008-11-28 00:22	2008-12-03 00:04
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	received packets ignored due to not handling header bit
Description:	firmware packets received are treated as bad protocol packets.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000103) sry_not4sale    2008-11-28 07:56	Fixed in commit 6dc01ac90d7d38a1cb4ffa89aca6a74624cd4ca0
(0000112) 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]
(0000118) 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?
(0000120) 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 :-)
(0000122) sry_not4sale    2008-12-01 01:17	Two more commits that should fix this: 315ab41edd344850d52297a298bbd1871c291a34 b885669ad9bfd7572e24d148d2bcd4036e5fcb1f
(0000128) Fred    2008-12-03 00:04	really fixed this time :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
74	[FreeEMS-Tuner] Comm Interface	minor	always	2008-11-28 00:25	2008-12-03 00:03
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Tuner reports that ALL bytes in a long packet are escaped wrongly
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:	app.log.zip (16 KB) 2008-11-30 00:59

Notes
(0000101) 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.
(0000113) 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.
(0000114) 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
(0000115) 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.
(0000116) 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.
(0000119) 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 ;-)
(0000123) sry_not4sale    2008-12-01 02:56	Fixed
(0000127) Fred    2008-12-03 00:03	this is no longer an issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
5	[Firmware] Flash Burning	minor	always	2008-10-29 11:19	2008-11-26 22:48
Reporter:	Fred	Platform:
Assigned To:	sean94z	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:	0.0.16-FlashGordon
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Function writeAlignedBlock does not write the data
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:	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

Notes
(0000002) Fred    2008-10-29 11:20    (edited on: 2008-10-29 17:04)	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."
(0000003) Fred    2008-10-29 11:21    (edited on: 2008-10-29 17:04)	Date: 2008-10-27 19:21 Sender: fredcooke "Awesome, note that this is the highest priority bug logged yet (yeah right) ;-)"
(0000004) 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."
(0000005) Fred    2008-10-29 11:22    (edited on: 2008-10-29 17:04)	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 :-)"
(0000011) 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.
(0000012) 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);
(0000013) sean94z    2008-10-30 15:37	I'll take a look at the flashBurn.s file and see what I find. Thanks!
(0000023) 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.
(0000036) 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.
(0000037) 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.
(0000040) 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............................
(0000041) Fred    2008-11-04 20:05	Getting closer :-)
(0000052) sean94z    2008-11-06 16:20	Offset implemented in eraseFunction, it now behaves as ordered. Should have write block ready to go very soon.
(0000053) sean94z    2008-11-06 17:16	Offset implement in writeWord, it now behaves as ordered. Now on to testing/fixing writeAlignedBlock.
(0000054) 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);
(0000055) 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.
(0000056) 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.
(0000057) sean94z    2008-11-07 21:26	RAMAddr offset is NOT needed, I was mistaken.
(0000058) 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 */     }
(0000059) 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 :-)
(0000060) sean94z    2008-11-07 21:55	Changed! Tests fine, as long as I don't comment out the sendUS((unsigned short)RAMAddr);
(0000061) 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?
(0000065) sean94z    2008-11-10 20:17    (edited on: 2008-11-10 20:18)	replacing sendUS with send(" FUQ "); causes it to write a block of CF3Fs Tried replacing the While with a For loop, had no effect.
(0000066) 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.
(0000067) 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.
(0000070) sean94z    2008-11-11 20:57	I'm now working with .17 code, let me see if I can find the WTF.
(0000071) sean94z    2008-11-12 22:52    (edited on: 2008-11-12 23:00)	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.
(0000087) 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
(0000099) Fred    2008-11-26 22:48	Tested successfully this evening, closing.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
41	[Firmware] Flash Burning	minor	N/A	2008-11-08 17:46	2008-11-26 22:46
Reporter:	Fred	Platform:
Assigned To:	sean94z	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Add PPAGE setting to the function and function header.
Description:	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...
Steps To Reproduce:
Additional Information:
Attached Files:	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

Notes
(0000090) 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
(0000096) sean94z    2008-11-25 22:35	Found error in ASM code that incorrectly handles PPAGE, will post fix SOON.
(0000097) sean94z    2008-11-26 20:40	Give those files a go and let me know!
(0000098) Fred    2008-11-26 22:46	Tested successfully this evening, closing.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
54	[FreeEMS-Tuner] User Interface	minor	always	2008-11-15 20:02	2008-11-16 21:15
Reporter:	Fred	Platform:
Assigned To:	BenFenner	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Red button text skewed
Description:	See screen shot : http://i260.photobucket.com/albums/ii15/diyefi/FreeEMS-Tuner/stillBadOnEEE.png [^]
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000079) sry_not4sale    2008-11-16 20:57	Fixed in HEAD. I am unaware of the correct wx code to center multiple line automatically.
(0000081) Fred    2008-11-16 21:15	Confirmed fixed.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
40	[Firmware] General Features	minor	always	2008-11-05 13:43	2008-11-16 13:06
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Hard Reset No Longer Works Since Change To Paging
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000072) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
38	[FreeEMS-Tuner] User Interface	minor	always	2008-11-04 22:09	2008-11-05 23:08
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Zero Padding Of Hex Bytes In Packet Data
Description:	It would be nice if the data displayed was in the form 0x08 instead of 0x8. Again, ultra low priority.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000049) sry_not4sale    2008-11-05 00:29	Fixed, and also now upper case the HEX

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
32	[Firmware] Ignition / Injection Scheduler	minor	always	2008-11-03 10:22	2008-11-03 10:23
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:	0.0.11-Cookin'
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Forgot to add code run time to test for always on in new code layout.
Description:	Forgot to add code run time to test for always on in new code layout.
Steps To Reproduce:
Additional Information:	Fixed some time ago, just creating permanent record of old bugs.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
31	[Firmware] Ignition / Injection Scheduler	minor	always	2008-11-03 10:22	2008-11-03 10:23
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:	0.0.10-Squashed
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	The logic for injectors staying hard on relies on predicting the future, clearly this is no good :-)
Description:	The logic for injectors staying hard on relies on predicting the future, clearly this is no good :-)
Steps To Reproduce:
Additional Information:	Fixed some time ago, just creating permanent record of old bugs.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
30	[Firmware] Ignition / Injection Scheduler	minor	always	2008-11-03 10:21	2008-11-03 10:22
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:	0.0.10-Squashed
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Bad PW Due To Advance
Description:	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.
Steps To Reproduce:
Additional Information:	Fixed some time ago, just creating permanent record of old bugs.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
29	[Firmware] Ignition / Injection Scheduler	minor	always	2008-11-03 10:16	2008-11-03 10:17
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:	0.0.10-Squashed
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Engine Cycle Period Used Before Valid
Description:	As per title.
Steps To Reproduce:
Additional Information:	Fixed some time ago, just creating permanent record of old bugs.
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
24	[Hardware-Dave] Schematics	minor	have not tried	2008-11-02 12:33	2008-11-02 17:16
Reporter:	davebmw	Platform:
Assigned To:	davebmw	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Produce a working design for Knock detection
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000031) Fred    2008-11-02 17:16	Discussion at : http://www.diyefi.org/forum/viewtopic.php?f=9&t=480 [^]

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
9	[FreeEMS.org website] SourceForge Web Space	minor	N/A	2008-10-29 14:30	2008-11-01 12:10
Reporter:	Fred	Platform:
Assigned To:	jharvey	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Create Initial SourceForge Web Space Page
Description:	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!
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000006) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
19	[Hardware-Jared] Schematics	minor	N/A	2008-10-31 09:38	2008-11-01 12:10
Reporter:	Fred	Platform:
Assigned To:	jharvey	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Task
Summary:	Update Schematics To Be Inline With Hardware Spec
Description:	Once the pin out and hardware interface docs are released in their updated form, bring the schematics (and therefore pcb) into line with them.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
18	[Hardware-Dave] Schematics	minor	N/A	2008-10-31 09:37	2008-11-01 03:21
Reporter:	Fred	Platform:
Assigned To:	davebmw	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Task
Summary:	Update Schematics To Be Inline With Hardware Spec
Description:	Once the pin out and hardware interface docs are released in their updated form, bring the schematics (and therefore pcb) into line with them.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
14	[FreeEMS.org website] SourceForge Web Space	minor	N/A	2008-10-29 19:58	2008-10-29 20:02
Reporter:	Fred	Platform:
Assigned To:	FE3tMX5	OS:
Priority:	none	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	> 1 month
Issue Type:	New Feature
Summary:	Come Up With An Awesome Logo For FreeEMS.org
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000008) Fred    2008-10-29 20:00	Welcome to the official FreeEMS contribution tracking task sharing all knowing fun having collaborative tool :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
13	[Firmware] Auxiliary Task Scheduler	minor	N/A	2008-10-29 17:18	2008-10-29 17:18
Reporter:	Fred	Platform:
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Non Time Critical Non Preemptive Task Scheduler
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
12	[Firmware] Structure / Style	minor	N/A	2008-10-29 17:01	2008-10-29 17:01
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Remove Most/All Literals From The Code
Description:	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).
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
42	[FreeEMS-Tuner] User Interface	tweak	N/A	2008-11-09 05:43	2009-09-02 08:32
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Tuner title text - version, etc
Description:	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!
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000063) 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.
(0000074) 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.
(0000107) 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?
(0000110) 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.
(0000154) 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/*
(0000162) sry_not4sale    2009-03-31 20:56	Is this ok for an interface version?: IFreeEMS.Vanilla (v0.0.1)
(0000163) 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)
(0000164) sry_not4sale    2009-09-02 08:32	All done bar interrogation to get firmware version

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
71	[FreeEMS-Tuner] Firmware Protocol	tweak	always	2008-11-28 00:16	2009-02-15 08:27
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	firmware interface unique id is wrong and interface version is wrong
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000104) 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
(0000105) sry_not4sale    2008-11-28 08:00	Fixed in commit 425b85e2264be44e02019394a361d1da18d6bdeb
(0000108) Fred    2008-11-28 13:49	Got the version change, but you missed the I on the front of IFreeEMS_Vanilla ;-)
(0000117) 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 :-)
(0000149) sry_not4sale    2009-01-13 21:43	Now moved to /comms/protocols/IFreeEMS_Vanilla/0_0_1/*

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
53	[Firmware] Analog Input Config & Processing	tweak	N/A	2008-11-15 16:34	2009-01-02 14:15
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	0.0.17-SpudEchoes
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Add Important Variables Into Structs And Refactor Placement Of Existing Ones
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000140) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
23	[Firmware] Build Process	tweak	N/A	2008-11-01 23:38	2008-11-04 22:04
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:	0.0.16-FlashGordon
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Investigate Paged Function Memory Addressing
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000043) Fred    2008-11-04 20:08	I did some solid work on this today and will try it out shortly.
(0000045) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
76	[FreeEMS-Tuner] User Interface	feature	N/A	2008-11-28 23:33	2009-09-04 10:39
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Add ability to cell by cell tune tables to memory dump tab
Description:	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 ;-)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000111) Fred    2008-11-28 23:33	All yours Ben! :-)
(0000125) BenFenner    2008-12-02 23:39    (edited on: 2008-12-04 14:05)	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
(0000166) sry_not4sale    2009-09-04 10:39	New firmware ID's /* Main table manipulation */ #define adjustMainTableCell 300 #define adjustMainTableRPMAxis 302 #define adjustMainTableLoadAxis 304

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
79	[FreeEMS-Tuner] User Interface	feature	N/A	2008-11-30 19:55	2009-09-04 09:42
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	0.1
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Real time vars display for basic datalog packet
Description:	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?
Steps To Reproduce:
Additional Information:	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
Attached Files:	many.many.many.datalogs.zip (18 KB) 2008-11-30 21:54

Notes
(0000121) 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.
(0000124) 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.
(0000130) 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.
(0000165) 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).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
59	[FreeEMS-Tuner] Comm Interface	feature	have not tried	2008-11-16 14:16	2009-09-02 21:38
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Create Interrogation Routine
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
57	[FreeEMS-Tuner] User Interface	feature	N/A	2008-11-15 20:36	2009-09-02 21:37
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Full Screen Mode For Use On Small Screens
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
51	[FreeEMS-Tuner] User Interface	feature	N/A	2008-11-12 09:26	2009-09-02 21:37
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Investigate And Maybe Create A Parser For MTX Gauge Definitions
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
50	[FreeEMS-Tuner] Firmware Protocol	feature	N/A	2008-11-12 09:24	2009-09-02 21:36
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Datalog Parsing Based On Config
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
22	[FreeEMS-Tuner] Features Requests	feature	N/A	2008-11-01 23:15	2009-09-02 21:34
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	The Ability To Load New Firmware
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
78	[FreeEMS-Tuner] User Interface	feature	N/A	2008-11-30 19:39	2009-09-02 21:33
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Ability to lock the table switching tables together
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
84	[FreeEMS-Tuner] Firmware Protocol	feature	N/A	2008-12-03 00:15	2009-09-02 21:32
Reporter:	Fred	Platform:
Assigned To:	BenFenner	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	duplicate
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Basic datalog request button
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
80	[FreeEMS-Tuner] Firmware Protocol	feature	have not tried	2008-12-02 23:48	2009-09-02 21:31
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	0.1
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Ability to turn async datalog on and off
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000126) 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
(0000153) 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 :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
43	[FreeEMS-Tuner] Configuration / Settings	feature	N/A	2008-11-09 21:20	2009-09-02 21:31
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	confirmed	Product Version:	0.2
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Config GUI
Description:	Mainly for comms at this stage, but this seems to be a common request
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
68	[FreeEMS-Tuner] Features Requests	feature	N/A	2008-11-23 21:15	2009-02-15 08:32
Reporter:	BenFenner	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Memory block request tab
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000093) 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 */
(0000094) 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.
(0000106) sry_not4sale    2008-11-28 08:01	Json list of memory locations please Fred :)
(0000109) 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.
(0000129) Fred    2008-12-03 00:06	I've been using it, works well :-)

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
87	[FreeEMS-Tuner] Features Requests	feature	N/A	2008-12-22 20:14	2009-02-15 08:28
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:	0.1
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Tab with 8 generic packet types
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
77	[FreeEMS-Tuner] Comm Interface	feature	N/A	2008-11-29 21:01	2009-02-15 08:25
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Improvement
Summary:	Move serial comms low level stuff into SOA style thread setup
Description:	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 :-)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000148) sry_not4sale    2009-01-13 21:40	Send, receive and comms logic now moved to individual threads

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
48	[Firmware] Serial Communications	feature	N/A	2008-11-11 16:15	2009-01-14 14:31
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	high	OS Version:
Status:	assigned	Product Version:	0.0.17-SpudEchoes
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Complete Basic Firmware Functionality
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000141) Fred    2009-01-02 14:16	Still need to test and/or implement the small table single cell adjust routine(s).

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
21	[FreeEMS-Loader] General	feature	N/A	2008-11-01 22:02	2009-01-08 21:18
Reporter:	Fred	Platform:
Assigned To:	sean94z	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	> 1 month
Summary:	Create This Application
Description:	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.
Steps To Reproduce:
Additional Information:	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.
Attached Files:

Notes
(0000024) Fred    2008-11-01 22:06	Typical linear short address line : S11382407DD37DC57DB67DA87D9A7D8B7D7D7D6F3B Typical linear long address line : S2143801808463844D84388422840D83F883E383CE55 Typical ppage long address line : S214E08170851484FE84E784D184BB84A5848F8479C7
(0000025) 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.
(0000026) 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.
(0000028) 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 :-)
(0000048) 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.
(0000062) 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.
(0000145) 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.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
85	[DIYEFI.org website] Main Site	feature	N/A	2008-12-16 22:11	2008-12-16 22:11
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Move content to Joomla or similar CMS
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
45	[FreeEMS-Tuner] User Interface	feature	N/A	2008-11-11 02:07	2008-11-28 08:06
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	acknowledged	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Table and 3d Views for Main Tables
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
69	[Firmware] General Features	feature	N/A	2008-11-25 11:47	2008-11-25 11:47
Reporter:	Fred	Platform:
Assigned To:	Fred	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Add Useful COP Monitor Function
Description:	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).
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
49	[FreeEMS-Tuner] Firmware Protocol	feature	N/A	2008-11-12 09:16	2008-11-12 09:16
Reporter:	Fred	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Generate Messages To Send Data
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
36	[FreeEMS-Tuner] User Interface	feature	N/A	2008-11-04 00:33	2008-11-05 23:07
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Big red hardware reset button
Description:	Just for fred ;)
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000039) 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.
(0000042) sry_not4sale    2008-11-04 20:06	Created!
(0000044) 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! ;-)
(0000050) sry_not4sale    2008-11-05 23:07	This time!

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1	[FreeEMS-Tuner] Comm Interface	feature	N/A	2008-10-28 21:16	2008-11-03 23:49
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	high	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Set up comms over serial
Description:	This is basic functionality and is required before going much further!
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000009) sry_not4sale    2008-10-29 20:11	Now sends packets over serial!! Still need to tidy it up tho
(0000027) sry_not4sale    2008-11-01 22:28	Code complete, including error handling. Tested with a virtual serial port!
(0000038) sry_not4sale    2008-11-03 23:49	Tested by Fred, worked!!!

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
27	[Firmware] Flash Burning	feature	N/A	2008-11-02 18:53	2008-11-02 18:53
Reporter:	Fred	Platform:
Assigned To:	sean94z	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Task
Summary:	Create EEPROM Write Functions
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

There are no notes attached to this issue.

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
25	[Firmware] General Features	feature	have not tried	2008-11-02 14:58	2008-11-02 15:08
Reporter:	Fred	Platform:
Assigned To:	AbeFM	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	New Feature
Summary:	Write General Purpose PID Function
Description:	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.
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000030) 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 [^]

Viewing Issue Advanced Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2	[Bug Tracker] Permissions	feature	N/A	2008-10-28 22:09	2008-10-29 12:02
Reporter:	sry_not4sale	Platform:
Assigned To:	sry_not4sale	OS:
Priority:	low	OS Version:
Status:	assigned	Product Version:
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Issue Type:	Bug
Summary:	Set up single-sign-on, or at least shared logins
Description:	FreeEMS has a number of admin web tools, and it would be nice to have one login across them all... - Forum - Wiki - Bug Tracker
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0000001) 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 [^]