jakestew

Right now I'm sitting here looking at the one open-hardware board design I have on my bench. People can demand all they want, but AFAIK right now there is only one board design that is actually being produced and is available to people. I like discussing new designs, but for right now there is only one board that I know is out there. And the only way I'll really know that new versions are being actually produced is when one shows up in my mail box!


> Jake could you add the code maybe that allows the most options but, rem them out so if a person wants a certain feature they can just un-rem the code? this way the complied code remains as small as possible.

I can only really add code when I know what I'm writing it for. Like you said, if someone wants minor changes then it's up to them to modify the code. I'll be happy to help people do that, but there's only going to be one main firmware for each board design that is actually being produced and used.

Anyone who thinks this discussion is overly-spirited (or not) needs to take a good look at my code if they haven't already. I have commented every single line of code telling exactly what it is doing. Rarely have I ever seen code this well commented. I did this because it's the proper way to code! Even if you have no programming knowledge the comments are written in plain english. Obviously there are complexities to manipulating the hardware of a microprocessor, and I can only explain things these terms. If it seems complicated I can assure you that looking at the datasheet for the chip will clarify the comments as best as is possible.

If something doesn't make sense to you, just ask me about it. Then I can clarify the comment in the next version. To understand what is going on with the processor you will need to look at the code and comments, then look things up in the datasheet. Almost every other line of code I write I have to look something up in the datasheet.

To lay out some basics... Every line of code starts with a statement and ends with a ";" After this will be a comment which starts with "//". Using an IDE or code editor (I often use Notepad++) will help you by highlighting parts of the code in different colors. This will help you see the code vs. the comments more easily.

If you don't understand, just ask! It really is that simple! Most of the time I'll probably explain it to you and show you can figure it out from the datasheet.


Keeping the code tight is my main focus. I probably won't include any runtime changes for different minor board changes. What I can do is add some defines at the top of the code, which will change what is actually compiled into the code.

I should have some defines set up for normally-open vs. normally-closed switches, etc.. That is something that will be in a future version if we cannot agree on the "proper" setup.

All in all I'm pretty happy at the moment... we have a v1.0 firmware that runs great on the only hardware I know of, and I've posted a demonstration video showing it's performance. Nobody can deny that what we have right now works well and has features that no other (under $250+) CDI out there has.

We're the most advanced open-hardware, open-software CDI that exists on all of the interwebs!


-Jake

Gompy

Last try with the hardware.
Just one board to use for one kind of CDI, not a devolpement board.

Why this kind of hardware:

Pin to use of PIC (12F683 / 12F1840)

Pin 1 Power + batterie
Pin 2 Table change - keep low by resistant / normal use jumper must be set / table 1 active // no jumper - table 2 active (safety table).
Pin 3 Killswitch - keep low by resistant / normal use switch must closed / killswitch not active // open switch / broken lead - kill output SCR (safety kill engine)
Pin 4 Special - keep high by resistant / have more functions / MCLR / reset PIC and ........ // personal opinion dont'use, only keep high with resistant.[1]
Pin 5 Input hallsensor or other puls from engine, components on input reduce nois, hallsensor need direct protect against nois with capacitor on leads.
Pin 6 Output SCR to optocoupler to protect PIC from HV / extra LED2 to find degree angle hallsensor / important to set in software.
Pin 7 Output flashlight to control degree angle table // need transistor output for high current LED / flashlight / rpm-meter.
Pin 8 Power - batterie

[1] Without the resistant on pin 4 (not) MCLR the PIC can't be in circuit programmed.
[1] If the pin is used for other options, the PIC can't be in circuit be proigrammed.
[1] ICP-pinheader is not possible, the PCB must be small for model use.
[1] With a program clip (show somewhere on this topic) the PIC can be ICP without the pinheader.

Don't make it harder to use the CDI for user who want only a advance / programmable CDI for there model(s)
For other projects / option / features / .. / make new hardware / software, but don't try to change a bike into a Ferrari.

Final, If some one have a good reason to change this board and design just say so with a plausible explanation.....NOT I LIKE IT.
In- or outputs can be reversed by soft- and hardware and the values I use are common and can also be changed.
If the group deside something must be change and all off the user have the same opinion, I'll design the hardware if possible.

First of all, the hallsensor header can't be change +P- to P+-, the board is to small todo this.
The header pins on the bottom will be there to make a small CDI with a sandwichboard but you are free do use them differend.
You don't have to use the LED's, the LEDs are on headerpins so you can remove them if you don't use them.

<EDIT>
Hallsensor input change to P + - like normal.
Add PDF with 1:1 PCB, schematic and 2:1 component layout

gr8flyer55

I chose board "B" for the board I made and at this moment I have it built 99% completed. It has the hardware configuration which is able to use both existing software and the version 1.0 recently released. Switches and headers work well, the board is still small and I will show on mine where I will adapt an off board ICP jumper. What's not to like?

John

Gompy

Nyemi make me attent to the rise and fall.

Please take a look to the schematic wat he means and if I have to change the schematic / PCB.
I don't know wat Jack use into his software and wat we need.

gr8flyer55

I am assuming this subject was covered about 10 pages back in this forum with a few lines in the software changes you can make by editing the lines in YOUR source code to give the proper signal. Maybe I'm wrong but thought it was addressed before.

John

Gompy

I find it also into the code, but I want to use the original code of Jack and not modify lines.
Thats wat I mean with ONE code and ONE piece of hardware, for ONE CDI.
Not make changes in software or hardware, not even by Exelsheet..
Not all users are smart enough to change the code, it must be plug and play.
Make the boards, program the PIC and fly away

gr8flyer55

I think you are right Rob. If we are all working towards the same goal, there should be just one board with one software program for that board. I guess I am just used to tweaking everything that is proposed on here to my way of doing things that I overlooked the main objective.
I haven't etched the newest "B" board yet, but I will. If Jake's software works with it then it should be the final version of the hardware if the limitations of the 12F683 chip's have been reached. The "B" board should be the BASIC version which would be a standard version, suitable for the beginner in this project. If we do split off into the 12F1840 chip project, which I feel we should to avoid the confusion, then it should be started in a different thread. Most of us have developed this project into what it is because we care enough to share. A new project should bring new ideas and possibilities.

In your testing Rob, does the latest software support this version of the board in it's present form?

John

Gompy

For the moment I can only test the latest hardware on the bench with the testrig.
It's very bad weather and I don't have a barn (yet) and some lawsuit about the barn take my time this week.
The timerboard is given a puls, HV-board fired the spark, but I can't see if the spark is coming at the right time (rise / fall).
My digital LCD scope is to slow and I given my old fast tube scope away

I need a timerboard to see if the HV-board, I work on for the bikes, will do wat it have todo.
The timerboard is not priority number one at the moment, we use differend software and timerboards for the bikes.
Some one have to tell me if there is something wrong with the timerboard your using.
But I can see you are the only one who test......others are waiting for your results.

I'll sent you today the latest software for the timerhardware.
Same board I using, so it must to be good

jakestew

To make the current code work with this new timer board, just delete the first line of code in the main loop which calls CheckPins(). It reads "CheckPins();" followed by the comment. This will disable the table switch and kill switch.

I'll put out another version of the code with these changes made and I'll also change it to use the magnet leaving the sensor for the timing.

In other news... this board just lost another post of mine. And I can't properly post any code here, even within the "code" tag. It doesn't handle files right either.

I'm sick of this ****e, so I'm ready to move the project thread over to RCG or wherever when I find the time to write up a first post. If someone else wants to do that instead, please do and post the link here.


-Jake

Gompy

If I understand well......
Removing the lines will also remove the function of the pins (2 and 3)
The functions must be there, only the high or low detection have to change.

The output to the opto / SCR can be change, rise or fall, just wat you like.
This can be done without changing the software, but I have to know wat I have to create !
Rewrap a small part of the PCB isn't a problem.

I think the users will wait for some time to get the best

gr8flyer55

Jake, in order for the "B" revision board to function properly, Rob tells me that pin 4 must remain as it is set on the board for the ICP function to work. If that pin is used for any other input or output, the design would have to undergo Major changes. Keeping pins 2 and 3 as switches does work fine. Changing the trigger to the magnet leaving the sensor is just fine and is basically the industry standard so that is good.
A new board will be designed for the capabilities of the 1840 chip. I'm sure with the capability of the 683 chip at its max, this board now is at it's peak. Like you mentioned before, board B is a one design board. Rob is willing to develop the next one for us, but keep this last design as the final.
Later today I will post a clearer PDF file of the etch pattern for it. The JPG copy that is online now is a bit fuzzy and didn't make a good print for me so I graphically enhanced it for better etch.

John

Gompy

But have to reverse, if the jumper is not set table1 must be active and if there is no closed contact for the killswitch the engine must stop.


Keep the Exelsheet in mind, it have to calculate with this change.

gr8flyer55

Jake, in another message from Rob, he suggests leaving the sensor trigger where you now have it, otherwise the sensor has to be moved on the engine 10 to 20 degrees to have it work. Some engines would not be hard to change, but others it is a catastrophe!
I tried the current software with the last board before B board and didn't have to move a thing.

If anyone else has a different view on this, tell us.


John

w8ye

My Feedback: (16)

I agree that there are problems with the editor of RCU. The biggest thing I see is that there is no automatic saved draft function for the editor like with V-Bulletin. There's no draft saver period! There are many people that edit their posts on their computer editor and then copy and paste the content to the RCU editor. So when the entry evaporates into thin air, they have not lost their work and can try again.

I would like to see this website support more alternative attachment formats and sizes also.

The owner of this web site is Internet Brands who also own V-Bulletin. (RCG and FG use V-Bulletin). IB has been saying for two years that they are going to change the format over to V-Bulletin but so far, it has not happened? Someone at IB with enough authority has not taken the interest or effort to make it happen?

This website's operating system is written in a hodge podge of code patches. At the time it was written, along about 2002, (the original code person, Mark Vigod is no longer with the organization) it was better than the existing V-Bulletin software. Since then, V-Bulletin has surpassed the RCU patchwork of disorganized code which is not written in distinct documented modules to make it easy for a new code person to just jump in and start adding features.

I wish I could give you some answers or promises but at this time the support is just not there.

gr8flyer55

Well, I just tested the "B" board with my ignition and used version 1 software in a 683 chip and it is working. You need a jumper on both pins 2 and 3 for it to start. If you take pin 3 jumper for the kill switch off, the ignition quits just like it is supposed to do. The table switch does work but I have 2 very closely programmed curves in my chip at the moment and could only tell you that it switches curves, but at this point I'm not sure which one is in position 1, jumper off.
Pin 4 jumper didn't seem to matter if it was on or off since there was no real function for it at this time other than the ICP with the chip clip adapter that Rob showed. The LEDs also work.

So I would say the board is 100% functional with version 1 software as is. Any changes from here will need to be tested and documented per function.

John

Gompy

Have you change the software line(s) Jack say todo or not ?

BTW, if you switch pin 4 to ground the PIC will be reset........normaly.
It will do the same if you shutdown the power and connect again.
If pin 4 isn't use, Jack have to set pin 4 to normal use into the cnfiguration sertup of the PIC.
The resetswitch must be a normal pushbutton.

gr8flyer55

I didn't change any software lines at all. I want to test the reset function of pin 4 jumper though since I had it off during my test.
If you leave the kill jumper off, the ignition fires a few times and then quits. Must be the loop for checking pins and the 4.7k resistor in place so till it doesn't see a full ground it fires a few times. That part of the code needs some work I think. Probably the same thing with pin 2 table jumper, but at least the board is functioning as built Rob!! Nice work!!

If Jake fixes the code now to reflect my test results, we have a winner.

John

Gompy

The switch of pin 4 must be open, it have to be a pushbutton.
If you make contact to ground, the PIC will be reset.
Do not change the capacitor or resistor of this input, they must be 4k7 and 100nF.

The problem of pin 2 and 3 will be the capacitors of 100nF in combination with the 4k7 or 10k resistor.
The capacitor delay the time to switch off, but they also filter the nois.
You can lower the value of the capacitors to 10nF without problems.
Don't lower the resistor, it will pull to much current with a lower value.
It will filter also a bad switch and vibration of contacts.



Maybe I have to add the 100R resistor.

gr8flyer55

Just tested pin 4 jumper. It does nothing either way, on or off as far as I can tell. In the timer I was using, pin4 was tied direct to ground and I think Jake left it that way in the software. I used a 7.2 volt battery pack for all my testing and the regulator works great. Instead of the 100uh choke you use, I had a 1uh choke and that also works. I will order some 100uh chokes if required but what I used seems fine, no noise spikes on the supply + line.

John

Gompy

With some luck you have the latest cosmetic PCB and schematic changes into your mailbox
You make it complete with Jack ?

I'm not the programmer, but I think Jack switch off the MCLR into the config line
Line 49

__CONFIG(FOSC_INTOSCIO & WDTE_OFF & PWRTE_ON & MCLRE_OFF & CP_OFF & CPD_OFF & BOREN_OFF & IESO_OFF & FCMEN_OFF);

Change to
__CONFIG(FOSC_INTOSCIO & WDTE_OFF & PWRTE_ON & MCLRE_ON & CP_OFF & CPD_OFF & BOREN_OFF & IESO_OFF & FCMEN_OFF);
This will change the MCLRE on again I think

===============================================
Line 239

WPU = 0b110100; // Internal pull-ups on GP2,4,5

Change to
WPU = 0b000000; // Internal pull-ups all off
This will shutoff the internalpullup resistors, not needed with external resitors

===============================================
The piece below have also change to make the switches work OK.
I think I know wat have to be change......Jack correct me if I'm wrong.
I will learn !
===============================================
static void CheckPins(void){
if(GPIObits.GP4 == 1){ // If kill switch is on (grounded)
if(KillSwitch < 10){ // Less than debounce value
KillSwitch++; // Increment value
if(KillSwitch == 10){ // Debounce value reached
INTCONbits.GIE = 0; // Disable interrupts
sGPIO.GP1 = 1; // Make sure HV trigger is off (turn GP1 on)
GPIO = sGPIO.ALL; // Update GPIO
}
}
}
else if(KillSwitch < 1){ // Kill switch off (low)
KillSwitch; // Decrease counter
if(KillSwitch == 0){INTCONbits.GIE = 1;} // If debounced back to 0, enable interrupts
}
if(GPIObits.GP5 == 1){ // If Table switch is on (high)
if(TableSwitch < 10){ // Less than max value
TableSwitch++; // So increment
if(TableSwitch == 10){ // Debounce value reached
TablePointer = AdvanceTable2; // Point pointer at table 2
LoadSettings(); // Load the user settings from the currently selected table
}
}
}
else if(TableSwitch < 1){ // Table switch has been turned on
TableSwitch; // Decrease the debounce value
if(TableSwitch == 1){ // Table switch really is on
TablePointer = AdvanceTable1; // Point TablePointer at table 1
LoadSettings(); // Load the user settings from the currently selected table
}
}
}
================================================== =

bluejets

Rob,
To disable internal pull-up, shouldn't the line read 0b000000....????

bit 2-0 WPU<2:0>: Weak Pull-up Control bits
1 = Pull-up enabled
0 = Pull-up disabled

Gompy

Your right, I count from the left to right, but I've todo from right to left.....I make allways the same mistake

jakestew

Hopefully I can remember everything to reply to...

The MCLR pin is used as input. It should not reset the pic. (This should be disabled by the __config line I use)

Disabling the switches is just a quick method so you can test the boards. I will fix this shortly to the new board setup.

Since John is cool with the new board design I assume he's finished with the v1.0 boards (I guess we'll call them that), and is ready to switch to Rob's version B boards.

The switch thing is probably getting a little complicated for people. If you use v1.0 with version B you can jumper the switches OR disable them by removing the "CheckPins();" line. I just posted this so people can test the new boards and actually get them to run. Each time I put out a new version I have to do quite a few things and check to make sure everything works right. The code edit is easy, but then I have to put that into the Excel file and check everything to make sure it works! I also have to make sure the instructions work right and people understand what is what. That's why I'm not cranking out new versions every few days.

As far as I can figure... if you jumper the pins right now with version B you will have the internal pull-ups on and the external pull-downs will be fighting. Hopefully this just wastes some current, it should not burn anything out but is not optimal.


Right now I have too much going on in my life! I will release a new version for the new board tomorrow, but I can't test it because I just don't have the time to etch and make the new board design. Somebody needs to send me a new version B board! Otherwise I'll put out a version B firmware, but will have to keep developing on the board I have.


As far as this forum is concerned... I try to copy and paste or write in an editor, but sometimes I forget. Losing posts really pisses me off and I'm ready to switch. My preference is vBulletin, phpBB, or UBBthreads.

RCgroups was suggested, and I don't really care. I think I'm registered on most of them. Let's just take a vote and switch! I'd even set up our own forum with phpBB on one of my domains, but it seems silly to not just move this somewhere else if there's something decent available.

So let's vote... Who wants RCgroups or something else? Who's unwilling to switch? Who's willing to ditch the people unwilling to switch? (I'm willing to occasionally post back here, but the main thread needs to be on a better forum software.) I like phpBB because it is open source, but vBulletin and UBBthreads are good commercial solutions that I'm willing to use.


-Jake

Gompy

@Jack, I can sent you a board but it takes 2 or 3 weeks befor you get the board.
I hope John will be so kind to make a board for you too.

This will be the last version (B) I make of the timerboard.
I make only some cosmetic changes, like lead / connector positions (P + -) and power into the middle.

Here you can download a free demoprogram to print the PCB files like they are.
http://www.baas.nl/layo1pcb/uk/downloads.htm
Download PCB.txt, rename it to PCB.zip en im port the files into the Lay1 program.
The PDF-file have a 2:1 and a 1:1 layout.

BTW, I think we can close down this topic if your code is ready to use.
To vote if we have to move somewhere for this last post is silly.
For the new 12F1840 CDI we can move to a other forum.

jakestew

Right, to turn off all the pull-ups the line should be: (1840 or 683, respectively)
WPUA = 0b000000;
or
WPU = 0b000000;

Pullups on the sensor can be left on, the pullup on the LED output doesn't matter. To have pullups on the sensor line...
WPUA = 0b000100;
or
WPU = 0b000100;

AFAIK either of these will work just fine. I've tested both and it makes no difference IME. I suggest keeping the sensor pullup on (2nd set of lines), but it probably doesn't matter witch one you use.


-Jake