Change variables utility to give to customers

[benallenuk]

Hi, I am producing a Fuel controller for people who run their cars on veg oil. See pic of solution below.

What I want is a way for someone to change variables, for example the temperature the water coolant needs to be before you switch to veg, but without giving them a copy of my basic code so they dont either rip it off or change to much and write off their engine. I suppose there is two possibilities:

1. Make changes myself from requests and email them a code, or have a number of variations available to download. i would need to protect the code and also have an easy way to upload

2. Write, or get a utility where you specify variables with names like (coolant temp), the person then selects the values and clicks upload to PIC. They dont see the code or have access as its hidden inside an .exe maybe.

Help please

 

[hippy]

Welcome to the PICAXE forum.

Would it not be easier for yourself and customers to be able to enter such configurations through the display screen ? You can use a long button push to switch in and out of configuration mode and make adjustments via the same buttons. That may depend upon what PICAXE you are using as to whether it has enough memory.

If you want a utility that the customer uses to set configuration, you can write that, generate the appropriate source code within your application, then call the PICAXE command line compilers to download the program code into the PICAXE without them ever seeing the source cde.

 

[MartinM57]

If you want a utility that the customer uses to set configuration, you can write that, generate the appropriate source code within your application, then call the PICAXE command line compilers to download the program code into the PICAXE without them ever seeing the source cde.

Can you explain more please - is this the way that end users can update their software without me having to send the source and the end user seeing it in the PE?

I know this feature has been in and out of the PE revision list/to do list a few times - is it now possible?

 

[hippy]

The process is to create your own compiler IDE rather than using Programming Editor. This works at a Windows command line ...

cd "\Program Files\Programming Editor\Compiler"
echo Do:SerTxd("WOW"):Loop > myFile.bas
picaxe08M -cCOM1 myFile.bas
type myFile.err
del myFile.*

What you'd do is create a Windows application which does all that and instead of "echo" writes the source code you actually desire.

 

[MartinM57]

Very interesting! I never knew when I woke up this morning that I would learn about this....

Where are the individual compiler switches documented? Is there a "-silent" option so that the user doesn't see he's got a PICAXE and thinks its a raw PIC?

Problem 1 (maybe) - the myFile.Bas could be intercepted and source code therefore compromised? Would be nice if you could pipe program lines into the compiler rather than using a file as the interface...

 

[Technical]

Martin - there is a whole compiler section with documentation, example source code etc on the software page (for Windows, Linux and Mac)

 

[MartinM57]

Hopefully not too OT...

...and now this has been raised (I was going to start a thread anyway) could you:
- start a PE session and load a .bas file
- setup a serial port monitor
- press F5
- let the monitor record all the output bytes, and save them
- edit them to remove the first few bytes that seem to be various retries/hansheking at the start of teh program download - yes I've looked
- write a (general purpose) program that takes these bytes and plays them to a PICAXE with it's download circuit - doing a BREAK command and the retries/handshaking like what the PE does

You could hen give your user the general purpose program plus the (essentially hex) file of bytes and that really would be secure?

EDIT: Technical's reply crossed in the post I must admit I've never looked EDIT2: "further down that page than the PE"! I'm off to investigate...

 

[BeanieBots]

I'd go for a simple user menu system which can be selected either by a combination or duration of buuton switches. Alternatively, hold down button at power up method of accessing the menu commands.

Another option would be a replacement EEPROM.
Have a look here for some idea of the menu levels possible with just two buttons and an 18X.
http://www.picaxeforum.co.uk/showthread.php?t=10986

 

[hippy]

The #No_Data directive also provide an ability to download a calibration program or something which sets Data Eeprom values then download a subsequent program including #No_Data ( so data is not wiped or zeroed ) which can use that calibration data.

That doesn't get around the issue of having to have a means to download a second program but it is a useful options to have.

There is no equivalent where only Data can be downloaded without a program being downloaded as well. #No_Data is available on 18X, X1 and X2 parts.

 

[BeanieBots]

How about adding a #No_program directive?
Then data or table could be downloaded without over-writing the existing program.

 

[hippy]

Is there a "-silent" option so that the user doesn't see he's got a PICAXE and thinks its a raw PIC?

Not as such but it depends how the compiler is invoked. Wrap it in a suitable ShellExecute() or whatever and the user would never know the compiler was executing.

If you can figure out how, you could embed the PICAXE compiler within your application executable, create it on disk when needed, run it and delete it. There'd be no trace of anything but your single application executable.

Problem 1 (maybe) - the myFile.Bas could be intercepted and source code therefore compromised? Would be nice if you could pipe program lines into the compiler rather than using a file as the interface...

It could be intercepted, but that can be mitigated against by using random filenames and random directories in which to create source and so on. You can even create random directories, sub-directories and files to make it quite hard to predict. Pipes can be just as easily intercepted as files.

Reality is that anyone determined and skilled enough can get your source, even determine what your source is without having it, and the other reality is that most people are either not determined, do not have the skills or are not motivated enough to pay the cost of someone who can do the job.

 

[hippy]

How about adding a #No_program directive?
Then data or table could be downloaded without over-writing the existing program.

Not possible without major alterations, debugging and testing to the firmware inside PICAXE's, Programming Editor, AXEpad and all the compilers. Not saying it couldn't or wouldn't be done but would be a major effort.

Added: It should already be possible with X2's. You'd still download a program with the data but that would just be a jump to another #Slot which contains the code to run.

 

[benallenuk]

Thanks for the suggestions. I like both solutions. Im using an 18M, which was a bit of a mistake when ordering, because I have nearly used all the 80 line memory already. I would love to use menu type system for the user to change variables.

1. How are these variables stored if the unit loses power? I dont believe they can be stored on the PIC can a seperate eprom be used,
2. Or would it be better to use a battery backup?
3. If a seperate eprom is to be used, then which one is best and how would I get data from it. 4. Im using the flowchart editor to program my PIC's at the moment and finding it really easy. Will I be able to design a menu system in there or will I have to use basic code instead.

 

[BeanieBots]

The 18M has a lot less memory than the 18X so text for a menu system could be a bit short. However, there a few tricks you can do with EEPROM for menu texts.
Have a look at the code I've used in the link I posted.
Note the use of READ & WRITE.
This saves the user values to EEPROM so that is saved even after power down.
Only the X series parts can use external EEPROM but for just a few numbers it not required.

 

[Andrew Cowan]

You'll probably need to use BASIC for a menu system - I've done it, and it's not that hard.

A

 

[BeanieBots]

You'll probably need to use BASIC for a menu system - I've done it, and it's not that hard.

A

You'll DEFINITELY need to use BASIC if you do it with a PICAXE !

 

[atharvai]

i don't know if u can change ur circuit but if u have a EEPROM with the variables, you can get the PICAXE to read the variables at the beginning of the program. and the user can just update the variables in the EEPROM using a compiler on the PC. that way your source code stays in the PICAXE and only your variables are changed in EEPROM.

i don't know if i explained it well, let me know

 

[jonphenry]

The menu system is the easiest way to go. Ive attached the page to my hot water heater timer. The basic concept would be the same for you. It has a menu the user can go through and set times for the water heater to come on on weekdays and on weekends.
In your case, you would use an i2c eeprom in place of my ds1307, offer a menu for the user to change the temp you want to change and then store that variable to wherever your storing your target temp.

http://www.lancer3.com/prgtimer.htm

 

[boriz]

One option is a preset pot on the PCB. It only takes one line of basic to read its value at the start of the program.

 

[hippy]

Im using an 18M, which was a bit of a mistake when ordering, because I have nearly used all the 80 line memory already.

The 18X has eight times the memory of the 18M and is a drop-in replacement in most cases as it has the same pinouts as the 18M. This will take you from an approx 80 line capacity to approx 600 line.

All PICAXE's ( except 08 ) have on-chip Eeprom accessed with READ and WRITE so no external memory needed.

So going from 18M to 18X should not involve any hardware changes.

It is possible to use flowcharts for larger and more complicated programs though it's perhaps better and easier in the long term to use the Basic programming language.

 

[benallenuk]

Excellent this solves a number of problems. Having some internal memory will help no end.

For example I plan to do the following.

Press button A on startup to enter into the setup menu. Select variable with next button, then use an up/down button to set variable which is displayed on LCD, then maybe pressing up & down buttons together to store variable.

I was thinking of using a preset and ADC to set value which is displayed on screen for fine tuning then read it back every time the pic boots, but I ditched this because I didnt know I could write this setting somewhere.

Also with the write command I can tell the controller the last state, i.e if the car stops for 30mins you can leave the car on veg oil and store the variable in memory, so when you turn it back on it knows what mode its in.

Excellent. Why did I buy an 18M, silly me.

 

[benallenuk]

The menu system is the easiest way to go. Ive attached the page to my hot water heater timer.
http://www.lancer3.com/prgtimer.htm

Im looking at doing this in my project. I can understand the basic code, but cant see where in normal operation it checks every 2sec for the program button to be pressed.

Thanks

 

[hippy]

Any menu system needs to be tailored to what buttons you have. For example, if you have + and - it may not be wise to have both held together to write if + or - changes the value immediately when pushed.

I have found four buttons ideal; Back, +, -, Store/Select sub-menu. You can drop - and require the user to use + to cycle round. You can also go less by relying on timed pushes. If the menu is only rarely used it doesn't matter if convoluted or difficult as much as it would if used frequently.

Your 18M won't go to waste - I'm sure you will find some future use for it as you get hooked on PICAXE

 

[benallenuk]

Thanks, Im still a little unsure. Do i have to put the 'if pin 1 =1 then goto menu' part in each subroutine, just incase the user want to go to the menu. Or is there an interrupt function, ie if this is pushed where ever in the program it will go to....,

cheers

 

[inglewoodpete]

I suggest you have a close study of Jon Henry's code. Entry to the menu is done via the interrupt routine. While it breaks a couple of rules of interrupt routines (routine should be very brief and any variables used in the interrupt handler need to be preserved and restored), it shows how an interrupt can be used.

When you understand how JH's code works fully, you could adapt parts for your own project.

 

[BeanieBots]

Whilst I agree with Hippy about the number of buttons, the 18M/X does not have many inputs.
If you have a look at the link I posted, it has the ability to set & save many variables with just two button.
The first button scrolls through the items and saves the current value displayed, the second button increments the value. If the value is too high, just keep pressing until it rolls over.
Then press the first button to save and move on to the next.

It's a little clumsy but not too painful if you don't need to change things too often. The main feature is that just uses two buttons.

I'm guessing that your app only needs a one-off or infrequent changes.

You could activate the menu by holding down both buttons or maybe only at power up as mine does.

 

[jonphenry]

Well I didnt want to burden it to actually execute code every two seconds in order to check if anything was pressed.
I assigned the program button(pin0) to an interrupt. when the button is pressed the interrupt routine is triggered. After going to the interrupt routine the code verified the button is still pushed then pauses for two seconds and re-verifies. If the button is still high after the pause then the interrupt routine calls the set routine and thus the user menu begins.

Given that this project was for a hot water heater timer and would only be reset by the user every few months or so, I assigned the task of getting into the menu to an interrupt as opposed to scanning the program button constantly.