gr8flyer55

Hi Jake.
Will the selection between the two curves be accessed by a jumper on the timer board?
If so, I'll have to make changes to the board. Let us know which pins will be used. I can make minor adjustments to the etch pattern to accommodate the jumpers. Making it jumper selectable I think will be the best choice, going between chip pin inputs and a ground connection. Right now, since I use a socket for the chip, to test curve changes I remove the chip and replace with a changed, programmed pic chip. Not that hard, but time consuming. Jumpers would be the better choice.
In the past with a previous version of timer board, we had a test routine for spark operation. This was jumper selectable and worked quite well. Although it used some space on the board, I thought it was very useful.

John

nyemi

Hi jakestew

Two curves eeprom?
For only 256 bytes.
It's just one, ignition curve.
How to solve this problem?

jakestew

I figure only the inflection points need to be stored. The actual value will then be calculated on the fly. Some of the calculation can also be precomputed if needed.

A big limitation of the 683 is that it can't write it's own memory. Otherwise we could compute the table and store it in flash. We'll just have to see how things go, it is possible I'm overestimating what is possible. I'll never know if I don't try.

Looks like you've got the timing maxed out already. I'll probably have to increase the osc to 8mhz just to cover the overhead of writing it in C.


I think it should be pretty easy to use a switch or jumper. I kind of like the idea of repeatedly switching back and forth between curves to see how the engine sounds, so maybe a momentary button would work well. You'd probably only need this for testing so just tacking on a switch as needed would probably work fine. With a momentary type setup you could also just ground a pin with a wire for a sec to switch back and forth.

What is the max RPM and max advance people want to achieve?
At 10,000 RPM, 30 deg. hall position, and 27 degrees advance there's only 50 instruction cycles available before firing when running at 4mhz. Even running at 8mhz that's only 100 instructions, and that's hardly anything to work with.

nyemi

Hi Jake
I do not understand.
Now your new code to work?
Or, old code, repair?
Because in my opinion: Old code can not be much of renewal.
Because 12f683 microcontroller hardware are great limitations.
If you want to change.
My proposal: The type microcontroller, a USB to Communication.




Sorry.
I work with translator.

jakestew

I'm working on a C version of your program. It was requested that I do a 683 version first. I'm still learning how to get around the hardware limitations of the chip.
Your code is very tight, so it will be hard to match it's performance in C.
I see there will be no time to do any calculation other than a table lookup for the curve. Still, there should be room for two tables in memory. EEPROM will just have to be for saving some other settings.

COM

Hi Jake,

I am very curious how it will turn out. I have a C version and it has some issues. Can you give some details on how (in C) you will measure rpm and how you will create a delay based on rpm?

nyemi

Hi Jake

Thank you for your response.
I suggest: your code works well for low RPM operation.
Due to the manual start.
Minimum manage 200RPM, the ignition timing.

jakestew

Sorry Com, I've been busy with school starting back up.
There's lots of ways we can use the timers and interrupts. We could poll the input pin or set it to an interrupt, you can use an overflow counter variable or try to scale the timer right.
I favor using the interrupts as much as possible so that processing can continue. We only have 1 MIPS to play with when running at 4mhz.

As soon as I have some working code I'll post it. If you have any C code please post it and I'll do a little debugging and simulating to see what's going on with it.

I can't wait to switch over to the 12F1840, which we can run at 32mhz for 8 MIPS of processing power, plus all the extra memory and peripherals. But doing this 683 version will make sure the code is tight.

gr8flyer55

Hi Jake.
I am using the RCD pic programmer. While it supports many Pic chips, it does not however support the pic chip 12F1840. Does anyone know if the JDM programmer supports this chip?
The 12F683 I use now with Nyemi's software has been working flawlessly for quite some time now. I understand the limitations of it and trying to add functions is tough at best. With the switch to a different 8 pin chip, my boards will still be useable with minor changes. I guess though I'll need to buy a new programmer.

I watched Nyemi's video showing the multi spark functioning above 2500 rpms and unless it was just me, I thought it switched it off after that rpm. Can anybody shed some light on this? Looks like yet another feature to work with.

John

jakestew

I picked up a pickit2 type (Chinese clone) programmer from ebay. It supports the 1840.
http://www.piccircuit.com

I'm not sure what other programmers will work with the 1840, but the first thing I'll be working on is getting a bootloader running. Then you'll be able to program the chips with just a regular USB serial TTL adapter, which can be found for about $3 if you don't already have one. It should be a lot easier to tune things up when you can easily play with all the settings.

There's a bootloader called "ds30 Loader" that should work.
http://mrmackey.no-ip.org/elektronik/ds30loader/
I changed the settings around to run on the 1840 and it seems to compile fine, but I haven't tried it yet.

There should be no problems continuing to use the 683, but there's no way to do a bootloader since it can't self-write its own memory. There's also no serial UART so there's no way to communicate with it. The two chips are pin compatible, so there shouldn't be any changes needed in the timer board.


Nyemi's program does switch off the multi spark after a certain RPM. I think MSD is only really usable at lower RPMs since at higher RPMs your piston has moved a long ways before you can generate the extra sparks. There's also the current draw issue and how fast you can actually generate the sparks with from the HV side.

I assume he tested how fast you could generate the sparks and determined some sort of compromise. According to the simulator, the multi sparks are2.4ms apart. The assembly looks like it's running a 6uS loop for the multispark. This doesn't seem to make sense...

jpanhalt

The newer chips are all supported by the PicKit3. You can get the OEM version, adapter boards and cables off ebay for only a little more than the programmer itself from DigiKey or Microchip. I got mine from Josuha1 (http://www.ebay.com/itm/ICSP-Adapter...#ht_5673wt_806 ). You may not want or need the complete set of adapter boards.

PK3 does both the 5V and 3.3 volt versions. One gotcha is the need to set the voltage with the software when you first fire up or change chips. Microchip says autovoltage detect is not active yet. Maybe it will come, maybe it was intended, but didn't work.

John

nyemi

Hi Jake
The proof of the pudding is eating it.

Regards nyemi.

jakestew

I've finished the first alpha/beta version of the PIC 12F683 version in C.

Features...
-Runs at 8 MHz
-Completely interrupt driven
-Uses the 16-bit timer to time from the top end of around 15K RPM all the way down to about 916 RPM.
-Uses a 256 point, 16-bit table for timing
-The timer provides 256 uS resolution with rounding on the 8 low bits to provide a max error of 128 uS.
-Using the high 8 bits of the timer naturally divides the uS per rev by 256. (then rounds with the high bit of the low 8)
-This works great for using Digi-Degrees (1= 360/256 = 1.4 degrees), which uses very little math on the PIC
-Calculated time delay for 120-915 RPM, under 2 RPS the engine is assumed to have died.
-Start mode for timing the first spark
-Spreadsheet for creating tables and calculating user settings

To use this version you need Microchip's XC8 compiler to compile the code, and a spreadsheet program to open the supplied spreadsheet to edit your table.
You should edit the source to put in your custom ignition curve and set your settings for start mode, and the low RPM advance. MSD is not working yet, so don't mess with those settings.

I have NOT tested this on an engine yet, but it works well in the simulator. I'm just putting this out there to get the ball rolling. You WILL have to change the settings, the default ones probably won't work on a real engine unless you're lucky. There's no documentation except comments in the source code right now, so if you have any questions feel free to ask.

Whatever this file attaches as, download it and rename it to 12F683_v0.8b.zip

-Jake


EDIT: Old version removed, use newer version below.

Gompy

I don't know if I posted befor, but this coil spark like hell !
http://heetgasmodelbouw.ridders.nu/W...kst_engels.htm

COM

Hi Jake,


thanks for doing this. I am having problems opening the file you posted. I saved as you said to and I can't open it. can you email me the stuff? charliem38(at) hotmail.com

jakestew

Release 12F683 v0.9b


New features...

-Multispark working!
-You can set the degrees between multisparks
-You can set the number of sparks for each mode - start, low RPM, and normal running
-You can set the MSD cutoff RPM for normal mode so that you aren't trying to multispark at high RPMs


Right-Click on the attachment link and choose "Save"
Then rename the file to: 12F683_v0.9b.zip
Extract the two files.


-Jake

P.S. COM,I sent you out the files. If anyone else is having problems let me know. The links seem to work for me.

EDIT: Old version removed, use newer version below.

gr8flyer55

Hi Jake.
Both files saved and opened fine for me. Working on getting the edits for my curve established. Seems like good code to me, but when I get the first chip programmed and working on my test engine I'll let you know.
Having a bit of trouble locating that compiler right now on their site. I can't afford another $400 program right now.

John

Gompy

Is't possible to get a free RPM programmed pin out ?
I need it to open a extra petrol valve for burst at ~8000 rpm.

jakestew

Step by step, how to get started...

I've tried to make things as easy as possible, but it still takes a little doing to get your own custom CDI firmware up and running. Unfortunately, I don't have any compiled versions that I actually know to work, so if you work out a good curve and settings please post it here or send it to me at my email. Hopefully we can get prefab versions ready for the common engines out there.

#1. Go to http://www.microchip.com/pagehandler...abx/#downloads
#2. Download the "MPLAB X IDE" and "MPLAB XC8 Compiler" for your operating system.
#3. Install the IDE and compiler. Default settings should be fine.
#4. Open the IDE and...

-Select File->New Project
-Choose "Standalone Project", click next.
-Select Family -> Mid-Range 8-bit MCUs (PIC12/16/MCP)
-Select Device ->PIC12F683 Click next.
-Debug header does not matter, I usually select the one you can choose, now click next.
-Select "Simulator" under hardware tools, or choose the programming device you use. Click next.
-Select "XC8" under XC8, click next.
-Choose a project name and location. I usually use a more convienient location than the default. You might use "12F683_v0.9b" for the name.
-Check "Set as main project" and click next.
-Copy the source file "12F683_v0.9b.c" into your project directory.
-On the left hand side of the MPLAB X IDE screen right-click on "Source Files" under your project name and select "Add Existing Item".
-Select the source file"12F683_v0.9b.c"and hit OK.
-Double click the 12F683_v0.9b.csource file that now shows up. This should bring up the source code.
-Select Run -> Build Main Project, from the menu. Source should compile with no errors.
-Congrats! You just compiled the code! You know things are working, so any new errors are your own doing.

-Now edit the source file, adding your custom table and the settings you want.
-Use the included spreadsheet to make your advance table and help figure out the settings.
-Build the project again and the .hex file should be in [Project Directory]\dist\default\production
-Now you can program the .hex file into your processor via whatever method you prefer.

I realize this is a lot of downloading and hassle if you're not into this sort of thing, so I'm happy to compile for people if you email me exactly what you want compiled. You can edit the source with just a text editor and send it to me and I'll do the work for you.


-Jake

jakestew

@John - I'm happy to compile whatever you need. The links in my last post should help. I think the code should compile under the free version, or you can activate a free 60 day trial of the pro version very easily (no registration hassles).

The pro version compiles a hex that uses 20% of the RAM and 41% of the memory. The free version uses 22% and 46%. Not a very big difference. I've tested the timings with the pro version and I can't know for sure if the free version will be exactly the same, but I don't see how it could be much different.


@Gompy - I'd be happy to write a function for that if you'd like. The reason I don't have any compiled versions is because I don't really know what settings to use and haven't tried the program on any engines to actually tune the settings. I tried to make everything as simple as possible, but some settings will depend on the application or need some general know-how to choose.

Check out the code and spreadsheet file. Design an advance curve and pick out some settings you want for the rest of the options. I'm happy to compile and test setups in the simulator. If anyone wants me to compile and check out their settings on the simulator at a certain RPM that is no problem. Just post or send me the code/settings and the RPM you want tested and I can easily produce a simulated O-scope image for you.


-Jake

P.S. My email is listed at the top of the source code. Anyone I forgot to mention in the credits, please email me. This code is free for personal use and limited commercial use. If you want to actually sell a product containing the code or a derivitave work of the code please email me, commercial licensing will be very reasonable.

lovefool

First of all, thanks for posting a lot of information here.

I am new to this hobby and I have been writing a timer code for CDI for a couple of months. I have studied scope data and codes found on RCU or the other site. So far, my very first version of code (POCroof of concept) written in CCS-C works okay on a glow 4c-90 engine.

Jake, I have a question about triggering SCR gate. I am using the hardware that is similar to the schematic of RCexl, and the spark occurs when HV output's falling edge. (GP1 become high to low) But your code seems expecting the spark when GP1 set to High. How the turning-on of SCR works?



sGPIO.GP1 = 1; // Turn on HV output (GP1) bit in shadow
sGPIO.GP0 = 1; // Turn on LED/tach (GP0) bit in shadow
GPIO = sGPIO.ALL; // Update GPIO <- expecting spark here ?
__delay_us(Dwell_Time); // Load dwell time (uS)
sGPIO.ALL = 0; // Turn off all GPIO pins in shadow
GPIO = sGPIO.ALL; // Update GPIO

Jay.

jakestew

The code you posted is simply turning on the output to the SCR. It is triggered by an interrupt caused by the falling edge on GP2.

The hall sensor is normally at 5v. When the magnet passes it causes GP2 to go to 0V (low). So you could trigger on the rising edge if you want the interrupt to trigger just after the magnet passes. If you trigger on the falling edge, as I do in the code posted, you will enter the interrupt service routine when the magnet first triggers the sensor to go low. Either way will work fine, I just figure that triggering when the sensor first hits gives you a little more time.

The code section you posted is only called after the falling edge of GP2 triggers an interrupt which sets a timer. The code is called when the timer compare matches.

I probably didn' t explain that to well. Here is what happens...

1. GP2 interrupt is called when the magnet first triggers the hall sensor (falling edge since the logic voltage is reversed).
2. GP2ISR reads the timer value, which equals the time since the last sensor trigger (1 revolution). The ISR then looks up a value in the ignition advance table based on the revolution time and loads it into the compare module of the timer.
3. After the time expires the timer compare module triggers an interrupt, when the values match (the set time is reached).
4. This interrupt service routine (the code you posted) turns on the GP1 pin, which tied to the SCR. It then waits the dwell time and turns the pin back off.

That is the basic flow of the code. It is entirely interrupt driven. The sensor interrupt triggers and the delay time is set, when the delay time expires it triggers an interrupt where the pin is activated. And so on.


-Jake

lovefool

Jake,
thanks for explanation. Since I am C programmer on PIC for long time, I could read your program and understood.

The question is when actually the spark occurs. When GP1 is high or GP1 is low.

My test circuit fires spark when GP1's falling edge. So according to your program it means after dwell time (500usec).

>4. This interrupt service routine (the code you posted) turns on the GP1 pin, which tied to the SCR. It then
>waits the dwell time and turns the pin back off.

Jay.

jakestew

I tried to comment every line of code so that it could be easily worked on, but a general explanation will probably help understanding better.

The program is interrupt driven. The main function only initalizes the processor and turns on the interrupts. The actual main loop does nothing at all, it's just a while(1) loop with no instructions.

There are three interrupts. GP2 falling edge, Timer1 compare match, and Timer1 overflow.

-[Timer1 Overflow] Timer1 is a 16-bit timer that runs at 1 uS per tick. It overflows every 65ms if not reset by the GP2 interrupt. If it overflows we know that the sensor on GP2 has not triggered in 65ms. Each overflow we add 1 to the TMR1_Overflow counter. If the counter goes over 7 we know that the engine is turning at less than 120 RPM (2 RPS), and we declare the engine not running.

-[GP2 Interrupt] happens once every revolution when the sensor activates. We then store the value from Timer1. Then we take the value from Timer1 and use it to look up a delay value from the ignition advance table. Then we reset Timer1 and load the advance table value into the Timer1 compare register.

-[Timer1 Compare] this is called when the Timer1 value increases to the Timer1 compare value. We then know it is time for the spark, so we turn on GP1 (SCR trigger/output), wait for the specified dwell time, and turn GP1 off.


And that's it! Pretty simple huh? It took me many hours, and several false starts that turned out to be overly complicated dead ends, to distill that pure simplicity.
If you add the other features to that basic outline you'll understand all of the program. I didn't explain the MSD code, starting code, or calculation of the speed at RPMs below the table values, but that's all just extra trimmings.

The main thing to understand is that Timer1 ticks at 1uS and gives us the uS per revolution. The Timer1 value can be accessed as a 16-bit value or two 8-bit values. Because of this we can avoid all sorts of slow math that would bog down the processor.

Using the high value (top 8-bits) we automatically already have the uS per revolution / 256. So instead of using 360 degrees per revolution we just figure on 256 digi-degrees per revolution (1dd = 1.4 deg.). This also automatically gives us the uS per digi-degree! All of this is done by simply taking advantage of the way the timer is set up, no math at this point at all!

So now all we have to do is multiply the timer value by the number of degrees we want to wait before sparking and load it into the compare module. Multiplying is slow, so we use a table for the faster values, and only calculate the delay at lower RPMs where we have the time to do so.


Hopefully this all is clear enough. Feel free to ask questions. I wanted to explain the digi-degree thing before it caused too many problems. There's probably a proper term for them, but I don't know it.

1 revolution = 360 degrees = 256 digi-degrees
degrees * 360/256 = digi-degrees
digi-degrees * 256/360 = degrees
1 digi-degree ~= 1.4 degrees
1 degree ~= 0.7 digi-degrees

jakestew

lovefool... You actually caught a bug. GP1 should be switched off to trigger the spark.

I've fixed this in v0.9b3...
The only thing changed is the GP1 polarity bug.

Thanks for catching that lovefool! I'll put you in the credits in the next release.


Right-Click on the attachment link and choose "Save"
Then rename the file to: 12F683_v0.9b3.zip