ThumperTuner v0.1 (or so it’s called right now) is my software interface to ThumperFI. I’ve gotten to the point where I want to be able to not only test all aspects of ThumperFI (and that includes reading/writing parameters, tables, etc.) but I need an easier way to change parameters while it’s running – and that means utilizing the UART interface that I’m putting the finishing touches on (well, the v0.1 touches).

I decided to use Python, along with wxPython and PySerial, for the software. Why?

As always, there’s an XKCD for that.

On a more serious note, because it’s cross-platform (wxPython and PySerial, too), easy to write and I already sort of know Python. In short, I’m lazy and don’t have the time to learn OS-specific languages right now. AND I’m wanting to spend the least amount of time possible right now developing this so that I can get back to actually testing and developing ThumperFI.

So far I’ve made a good amount of progress for the small amount of Python knowledge I have. I’ve already talked to ThumperFI and have a basic, really terrible looking GUI that functions.

I swear it will look at least a little better than this.

It’s been tough not expanding my scope like crazy, like I always do, but I want to make sure that the program at least functions and has decent error handling (and flexibility for future development – I don’t want to write myself in to a corner and have to refactor everything in the next minor version).

I’ve compromised with myself, I’m not going to let the command interface get too out of hand but I’m writing it in the most flexible way I can think of – there will be a class that interfaces with my program that handles all of the talking, error-handling (ThumperFI uses an ACK/ErrorCode scheme that I might detail in a later post) and data conditioning, and allows me to add more commands later.

Since starting this post I’ve solidified how I’m going to write the command interface, I’ve got the “Hello” and “Engine Parameter” (“H” and “E”) commands working, so I’ll post a snippet of how that works below:

# Generic command modes (for knowing how to handle)
class TFICommand:
	def __init__( self ):
		self._cc = ''
		self._length = 0

class StringCommand( TFICommand ):
	def __init__( self ):
		TFICommand.__init__( self )
		self._cc = 'H'
		self._length = 17

	def CommandString( self, *args, **kwargs ):
		return self._cc

	def Process( self, data ):
		return data

The real magic of this becomes more evident in the command interface class I wrote.

class CommandInterface:
	commands_dict = {
		"H": StringCommand,
		"E": EngineStatusCommand,
		"R": ReadParameterCommand,
		"W": WriteParameterCommand,
		"P": AllParametersCommand,
		"T": TimeCommand
	}

	def SendCommand( self, command, parameter='', data = [] ):
		# Check that the command exists
		self.command = command
		if self.command in self.commands_dict:
			self.Interface = self.commands_dict[command]()

			# Send command string
			try:
				self._serial.flushOutput()
				self._serial.write( self.Interface.CommandString() )
			except:
				raise
			else:
				# Command sent, time to get the response
				if self.CheckResponseCode():
					return self.CollectData()
				else:
					print "Response code failed (not ACK)"
					return False

So far it’s working really well. I want to write and test the more complex methods soon – like WriteParameter and ReadParameter. The cool part is that if I need to add a new command in the future (which I do, BurnEEPROM, and a few others) I just have to add a new sub-class assuming it works similar to the rest of the commands.

I’m also working on the GUI – that’s been interesting. I haven’t really built anything on the front-end for applications before. I’ve done a lot of web programming when I was still building websites for people but that was all HTML/CSS with a PHP backend and some JavaScript/jQuery magic in the front. I’m using wxPython so I’ve just been doing a lot of Googling for “wxPython” + [something related to it] (+[tutorial/example]). That wonderful looking table you see is a small class I wrote to use the FlexGridSizer to build a table based on inserting a row. It keeps track of the value column so you can modify later by just calling something like:

self.parameterPanel.ChangeValue( "map", self._eparam.MAP )

I tested it out and it works really well so far. I need to add the rest of the parameters to that table but I don’t have simulated inputs for most of the rest yet – I’m also working on that right now (whole lot to this whole building-a-fuel-injection-system thing). Once I get the VR simulator finished (along with a MAP simulator) I’ll be in business for firmware development.

To be continued! (whenever the GUI doesn’t look as awful)