Tim, I may be just wasting your time, but I suggest that you get a basic design, without any consideration for cost, worked out first. Then rework the design with cost and manufacturability in mind. If you go the MOSFET route, you will probably use a MOSFET driver, just like the Megasquirt. Then you don't have a need for 300ma per channel at max current, then a LM2937-3.3 will be fine.
I used the Megasquirt power supply circuit in my own design a long time ago, after spending some time asking questions about why it was built the way it was. There are A LOT of hours in the MS design and it has many years of proved functionality, using what they've learned is a good thing IMHO.
Your target price of $10 isn't possible, the Propeller costs $8 alone, then you need an EEPROM, driver, power supply, etc. If you come up with a real OSS design, you won't have to worry that it costs $25 and you sell it for more, people will either fab it themselves or buy it from you. Be prepared for all the wacky stuff that people are going to do, but it will make your product platform more versatile and position you to do some even better things.
I was one of 4 original Megasquirt pre-built manufacturers, that market blew up and now there are some really well known, established, companies that have thrived on the Megasquirt -- serving the main and corner markets for vehicle specific kits and special form factors.
All that said, I DO think MOSFETs are a good idea because they can handle a lot more current than the TIP42C, which means more idiot safety factor is builtin. In addition, people will want to do more than run 2 solenoids, they will want to put this on full electronic trannies and do line pressure and all the clutches, so you will probably be faced with expanding the design to be a full trans controller.
This is just some thoughts, I'm not trying to push you around, but I've been down this road years ago and know what I'd do differently today.
So would a switching regulator be a better option? I am piecing together a order on Digikey for testing purposes but I don't want to just order $10 or $20 worth of parts and I don't want to have to order a minimum 1000 pieces either. I would still need 2 regulators for the 5v and the 3.3v correct? Should use a switching regulator on the 12v side to lower the voltage to 5v, then convert it from there to 3.3V with a regular regulator?
Tim, I may be just wasting your time, but I suggest that you get a basic design, without any consideration for cost, worked out first. Then rework the design with cost and manufacturability in mind. If you go the MOSFET route, you will probably use a MOSFET driver, just like the Megasquirt. Then you don't have a need for 300ma per channel at max current, then a LM2937-3.3 will be fine.
I used the Megasquirt power supply circuit in my own design a long time ago, after spending some time asking questions about why it was built the way it was. There are A LOT of hours in the MS design and it has many years of proved functionality, using what they've learned is a good thing IMHO.
Your target price of $10 isn't possible, the Propeller costs $8 alone, then you need an EEPROM, driver, power supply, etc. If you come up with a real OSS design, you won't have to worry that it costs $25 and you sell it for more, people will either fab it themselves or buy it from you. Be prepared for all the wacky stuff that people are going to do, but it will make your product platform more versatile and position you to do some even better things.
I was one of 4 original Megasquirt pre-built manufacturers, that market blew up and now there are some really well known, established, companies that have thrived on the Megasquirt -- serving the main and corner markets for vehicle specific kits and special form factors.
All that said, I DO think MOSFETs are a good idea because they can handle a lot more current than the TIP42C, which means more idiot safety factor is builtin. In addition, people will want to do more than run 2 solenoids, they will want to put this on full electronic trannies and do line pressure and all the clutches, so you will probably be faced with expanding the design to be a full trans controller.
This is just some thoughts, I'm not trying to push you around, but I've been down this road years ago and know what I'd do differently today.
--Perry
You are not wasting my time at all! You actually stated everything I am trying to work for to a T. I don't expect to have a $10 or $20 cost. There really is no budget at the moment since I really don't know what it will cost. I just want to ensure that I will be ordering the correct parts and not wasting my money on things that I don't need. Building a quality product with robust features I think can grab the market, but with my limited knowledge, I need to reach out to a community that knows what they are talking about when it comes to electronics and the spin language. Everyone on this forum has always been a great help through every problem I have run across which make me want to stay with the parallax community even though there are cheaper alternatives. I have some of the advanced mosfet things that were posted earlier in my cart for digikey. I think adding 2 of those to the circuit would be a plus since I do plan on running several different things other than the solenoids from it. My idea for the project is to build it as robust and stable as possible so when it is released, it comes with a pre-made, ready to run platform that users can modify from there. With help from as many people on here as possible, I am sure I can accomplish this goal! This will also be a HUGE learning experience for me since the Prop is new to me and I am slowly starting to catch onto the Ohms Law formulas
I took a look into switching regulators and even with the price being higher than a linear regulator, I think it may be worth using for my application. The question I have is, I have seen switching regulators that have 2 regulators in one package (5v and 3.3v) and was wondering if that is what I should get or should I get one 5v switching regulator and 1 3.3V linear regulator or both switching regulators? I am hoping to put in an order at DigiKey today so I can have the parts this week to start assembling my own stand along proto board to put in my car.
I think the 3.3+5v regulators are expensive enough to not warrant it. The 3.3v regulator, dropping from 5v, won't dissipate enough heat to worry about. Since your main concern is heat and not power consumption, you only need "good enough" efficiency.
Note on DigiKey: there's a $5 handling charge if you order less than $25, so try to get over that mark. Also, lithium batteries can't be shipped via usps.
I have the shopping cart at $25 right now. Just need to add the 3.3 volt regulators to it now. I think I am going to try using the 7805 with a heat sink since I have 100 of them in stock at my house now. My question is, will the 1A output of the 7805 be too low for the input of the 3.3V 1.5A output of the other regulator? I just want to ensure I order parts I know I can use. I am still unsure whether to use SM or Through Hole for the 3.3V. The 7805 is a through hole, but allows me to add a large heat sink. Should I stick with Through Hole on the 3.3 just in case I need a heat sink? Do I need 1.5A output of the 3.3 to run the Prop? Most of the Prop pins will be inputs since there are only so many thing that require an output. Sorry for all the questions, I just want to ensure I order the correct things.
I have the shopping cart at $25 right now. Just need to add the 3.3 volt regulators to it now. I think I am going to try using the 7805 with a heat sink since I have 100 of them in stock at my house now. My question is, will the 1A output of the 7805 be too low for the input of the 3.3V 1.5A output of the other regulator? I just want to ensure I order parts I know I can use.
The 3.3 regulator won't draw more than is drawn from it. The prop doesn't draw more than 120ma, so unless there's more on the 3.3v rail than the prop and the EEPROM, you'll be fine.
Heat doesn't come from things being overloaded, but from any draw at all. So, any 3.3v regulator will dissipate ((5-3.3)*.12)=.204 watts. So, look into thermal resistance values listed in the datasheet for whatever regulator you use to see what temperature rise you'll face.
I am still unsure whether to use SM or Through Hole for the 3.3V. The 7805 is a through hole, but allows me to add a large heat sink. Should I stick with Through Hole on the 3.3 just in case I need a heat sink? Do I need 1.5A output of the 3.3 to run the Prop? Most of the Prop pins will be inputs since there are only so many thing that require an output. Sorry for all the questions, I just want to ensure I order the correct things.
What should I use to ensure it will cover what I need and allow room for a little more in the long run?
All of the regulators mentioned are far more than necessary for your application. Take the cheapest one. I'd use a surface mount regulator for the 3.3v rail. Just make sure you connect it to a ground plane. It may not actually be necessary, but it's a good precaution.
Out of curiosity, do heatsinks normally come with screws with them? I can't seem to find any information on it.
EDIT : I did not see anything on screws coming with them so I ordered some the same size as what is on the SX proto board Only $3 more for 100 screws and nuts... Can't lose there.
Now for the programming side of things. Since I have a basic program working on the Prop, I would like to be able to add more into it including reading the RPM signal from the ignition module which is a 5V square wave and the throttle which I tinkered with using RCTIME. What I would like to do for now is create a cog that runs all the time which reads the RPM signal. I am completely new to the whole cog thing and need some help with this. I also have working code on one of my previous posts to read the RPM on the SX, but I need to convert it over to the Prop. Could someone help me with that?
Is that kind of like an INCLUDE? How is the code called? I am beginning to pick up a little on the SPIN language, but have some difficulty understanding a few things. I see a PUB init(b) so would I call the function by something like this :
[PHP]
VAR
LONG rpm
OBJ
rpmreader : "jm_freqin"
PUB main
rpmreader.init(6) ' Start reading RPM on PIN 6
rpm := rpmreader.freq * 60
' Do something with RPM
[/PHP]
Is there a way to start a COG as the chip begins processing code, have that COG loop while the circuit is on, and update a global variable (rpm) while it is running?
Well, I just burned up my development board I hooked up the parallax 2X16 backlit display and powered it from it's own stand alone 7805 then ran a common ground between to the 2 boards and hooked the serial wire to the development board. With everything powered up, the 7805 got extremely hot and I instantly unhooked everything. My finger print is now on the back of that regulator.... Not sure what happened, but I have 5 more props on their way along with some 32k EEproms. The Prop on the development board got hot as well. It can still be programmed, but all the pins are dead. Can't get any output from them. I have the worst time with regulators!
Maybe this is just the way I do things, but what I like to do is start off with a new folder, and copy all the 'objects' into that folder. I copy them from the obex and if you have a moment, just scan through the obex because there is a lot of really useful code there. (an 'object' is just a .spin file). I also like to call my main program a name with 'main' somewhere in the program, so I can remember which is the main program in amongst all other objects.
Your example
OBJ
i2c : "Basic_I2C_Driver"
means to include a file called "Basic_I2C_Driver.spin" (which will be in your current directory) and to refer to it with the name "i2c". So you might have things like "i2c.start" and "i2c.read".
This might seem a bit convoluted, but what it means is that you can define "display" as meaning a TV object, and then later by changing one line in the OBJ section, redefine "display" as meaning a VGA object and you don't have to change the rest of your code.
A typical spin program might have a number of objects. I typically use a TV or VGA object, mouse, keyboard, sd driver and serial port. If you use objects from the library and don't modify them, you can happily copy them into multiple directories.
If however you decide to modify an object, you need to keep track of those modifications somehow, maybe with a name change with the version number in it.
What else?
Oh yes, PUB and PRI. In an object, a PUB subroutine is something that your main program can call, eg i2c.start means that in the i2c object there will be a "PUB start" somewhere. PRI methods are internal to the object.
Is there a way to start a COG as the chip begins processing code, have that COG loop while the circuit is on, and update a global variable (rpm) while it is running?
Yes there is. In fact, you can have 7 cogs doing this in parallel.
Take a look at some objects that have pasm in them. There are pasm instructions like rdlong and wrlong that move data from the cog to the hub memory and this is how your spin program interacts with the cog program.
In general you declare a variable in your main program eg "rpm", and then when you start up the cog, you pass the location of that variable to the cog. Often there is a list of variables and the first thing the cog does is grab that list and copy them to local variables within the cog.
Pasm can be a bit tricky to learn. I found it best to pick a typical object (eg mouse, or keyboard) and pull it to bits and try to work out what it is doing.
So basically, I would have to do that in pasm? It is extremely confusing to me and I can't seem to locate any good help indexes for it. I have checked the help files, but nothing explains anything for me.
I was thinking you could set a global variable in the "Main" and start a new cog with COGNEW which would basically call a Public function. The public function would just repeat the code in that function. Guess it does not work that way?
I still don't understand how to use the jm_freqin code. I can't even get it to output anything to my LCD display. I don't know how to properly call it to start reading RPM. The whole spin language to me is 100% new. I don't remember even writing the code I already have since it was done probably a year ago. I have tried to read over help files and tutorials, but what I am trying to do does not come in a tutorial The basics are kind of easy to understand though.
I do like the idea of keeping everything in one folder and named accordingly. I will have to do that right now.
Well, I just burned up my development board I hooked up the parallax 2X16 backlit display and powered it from it's own stand alone 7805 then ran a common ground between to the 2 boards and hooked the serial wire to the development board. With everything powered up, the 7805 got extremely hot and I instantly unhooked everything. My finger print is now on the back of that regulator.... Not sure what happened, but I have 5 more props on their way along with some 32k EEproms. The Prop on the development board got hot as well. It can still be programmed, but all the pins are dead. Can't get any output from them. I have the worst time with regulators!
Always bring power up on a new system SLOWLY, and watch the current whilst doing do.
If the device is in a socket, remove it on first power apply and check Vcc.GND pins are what you expect.
Common mistakes are Vcc-Gnd shorts (not fatal), Chips backwards (not fatal, provided you avoid amps of flow), and over-voltage.
You are powering the Prop off 3.3V, right ?
Yes, the Prop was powered by the regulators which were already on the Prop development board. I used a 7812 adjustable regulator that was set for 8.8V to supply power from the 12V battery to the Prop Development board. Then, on a standard project board (the kind you push in the components), I had the 7805 which was connected directly to the battery, then the output was connected directly to the 2X16 display. I had the ground of the battery connected to both the Vss and the ground of the second project board to ensure there was a good ground between both of them. Once powered on, it took about 3 seconds to make the 7805 get extremely hot. The circuit did come on and show the boot screen like it should, but then I checked the temp and pulled everything as fast as I could.
Come to find out, the prop board is still ok. I just wrote a sample program to it and it is blinking the display like it should Now I have to figure out why it is not working anymore with my code. I am using the same code posted earlier. I don't think I made any changes to it before I locked it up over a year ago
Maybe I am missing something.... The Prop development board has a 5Mhz crystal on it already. Is it connected to the Prop without having to solder anything?
That is strange. I wonder why the code on the first page of this thread does not work on my proto board anymore Can anyone see a potential problem on why it is not working?
EDIT : To be a little more specific other than "Ouch something hurts"...lol. With the code above, the load into the eeprom or ram goes good. Once it is finished the display does not come on. I don't have anything hooked to the solenoid circuitry since before I programmed it, it worked correctly.
If I put the code in it's own file and program it, after naming Test to Main, the LED's do blink properly. If I add the code below PUB Test to the beginning of my Main, nothing happens No Compile errors or anything.
Ok, i think I figured out what is going on... I nulled out the XIN and the CLKMODE lines and it started working. Could I have burnt out the crystal on the board?
Sounds like you need a way of debugging. Test each line one at a time.
Debugging can be done with a fancy display showing numbers, but many times you can debug just fine with a LED. Take circuitsoft's "Test" routine and copy it to a routine called (say) Test2, and change the waitcnt value to, say, 40_000_000.
Now you have two routines - one flashes fast and one flashes slow. You can test if the program gets to certain points eg
repeat
if ina[upbutton] == 1
flash_fast ' flash led fast 8x
gear++
gear := shiftgear(gear)
if ina[downbutton] == 1
flash_slow ' flash led slowly 8x
gear--
gear := shiftgear(gear)
Addit - re the crystal - probably the crystal is ok, but the crystal part of the propeller chip might be damaged. You did cook it quite badly earlier, right?
When the 7805 got hot, the Prop did heat up pretty good. Everything else seems to be working. I would hate to have to chunk this board over 2 pins on the prop.
Well if it is just the xtal bit not working and you don't need perfect timing, then it will be ok.
However, if that bit of the prop chip is zapped, other bits might be zapped too, and it is going to get hard to debug if, say, one cog is unreliable, or one pin works but the next one doesn't.
Did you ever work out why it got hot? eg rebuild that circuit with just the regulators and no propeller or display attached, and see if it gets hot. If it does, pls post a photo.
I've always found it helpful to have two of everything when building new circuits. Worth getting another prop board? (You can never have enough propeller boards, right?!)
Comments
I used the Megasquirt power supply circuit in my own design a long time ago, after spending some time asking questions about why it was built the way it was. There are A LOT of hours in the MS design and it has many years of proved functionality, using what they've learned is a good thing IMHO.
Your target price of $10 isn't possible, the Propeller costs $8 alone, then you need an EEPROM, driver, power supply, etc. If you come up with a real OSS design, you won't have to worry that it costs $25 and you sell it for more, people will either fab it themselves or buy it from you. Be prepared for all the wacky stuff that people are going to do, but it will make your product platform more versatile and position you to do some even better things.
I was one of 4 original Megasquirt pre-built manufacturers, that market blew up and now there are some really well known, established, companies that have thrived on the Megasquirt -- serving the main and corner markets for vehicle specific kits and special form factors.
All that said, I DO think MOSFETs are a good idea because they can handle a lot more current than the TIP42C, which means more idiot safety factor is builtin. In addition, people will want to do more than run 2 solenoids, they will want to put this on full electronic trannies and do line pressure and all the clutches, so you will probably be faced with expanding the design to be a full trans controller.
This is just some thoughts, I'm not trying to push you around, but I've been down this road years ago and know what I'd do differently today.
--Perry
You are not wasting my time at all! You actually stated everything I am trying to work for to a T. I don't expect to have a $10 or $20 cost. There really is no budget at the moment since I really don't know what it will cost. I just want to ensure that I will be ordering the correct parts and not wasting my money on things that I don't need. Building a quality product with robust features I think can grab the market, but with my limited knowledge, I need to reach out to a community that knows what they are talking about when it comes to electronics and the spin language. Everyone on this forum has always been a great help through every problem I have run across which make me want to stay with the parallax community even though there are cheaper alternatives. I have some of the advanced mosfet things that were posted earlier in my cart for digikey. I think adding 2 of those to the circuit would be a plus since I do plan on running several different things other than the solenoids from it. My idea for the project is to build it as robust and stable as possible so when it is released, it comes with a pre-made, ready to run platform that users can modify from there. With help from as many people on here as possible, I am sure I can accomplish this goal! This will also be a HUGE learning experience for me since the Prop is new to me and I am slowly starting to catch onto the Ohms Law formulas
Note on DigiKey: there's a $5 handling charge if you order less than $25, so try to get over that mark. Also, lithium batteries can't be shipped via usps.
Here are a few regulators I have spotted on Digikey for the 3.3V :
http://search.digikey.com/us/en/products/LD1117V33C/497-1492-5-ND/586013 (950ma Output, Voltage Drop : 1.1V @ 800ma) Would the voltage drop cause the prop to hit brownout?
http://search.digikey.com/us/en/products/LD1117AV33/497-1485-5-ND/586006 (1.2A Output, Voltage Drop : 1.15 @ 1A)
http://search.digikey.com/us/en/products/MCP1826S-3302E%2FAB/MCP1826S-3302E%2FAB-ND/1635996 (1A Min Output, Voltage Drop : 0.25V @ 1A)
What should I use to ensure it will cover what I need and allow room for a little more in the long run?
EDIT : I did not see anything on screws coming with them so I ordered some the same size as what is on the SX proto board
[PHP]OBJ
i2c : "Basic_I2C_Driver"
BS2 : "BS2_Functions"
throt : "RCTIME"
lcd : "Serial_Lcd"
num : "simple_numbers"[/PHP]
Is that kind of like an INCLUDE? How is the code called? I am beginning to pick up a little on the SPIN language, but have some difficulty understanding a few things. I see a PUB init(b) so would I call the function by something like this :
[PHP]
VAR
LONG rpm
OBJ
rpmreader : "jm_freqin"
PUB main
rpmreader.init(6) ' Start reading RPM on PIN 6
rpm := rpmreader.freq * 60
' Do something with RPM
[/PHP]
Is there a way to start a COG as the chip begins processing code, have that COG loop while the circuit is on, and update a global variable (rpm) while it is running?
Maybe this is just the way I do things, but what I like to do is start off with a new folder, and copy all the 'objects' into that folder. I copy them from the obex and if you have a moment, just scan through the obex because there is a lot of really useful code there. (an 'object' is just a .spin file). I also like to call my main program a name with 'main' somewhere in the program, so I can remember which is the main program in amongst all other objects.
Your example
means to include a file called "Basic_I2C_Driver.spin" (which will be in your current directory) and to refer to it with the name "i2c". So you might have things like "i2c.start" and "i2c.read".
This might seem a bit convoluted, but what it means is that you can define "display" as meaning a TV object, and then later by changing one line in the OBJ section, redefine "display" as meaning a VGA object and you don't have to change the rest of your code.
A typical spin program might have a number of objects. I typically use a TV or VGA object, mouse, keyboard, sd driver and serial port. If you use objects from the library and don't modify them, you can happily copy them into multiple directories.
If however you decide to modify an object, you need to keep track of those modifications somehow, maybe with a name change with the version number in it.
What else?
Oh yes, PUB and PRI. In an object, a PUB subroutine is something that your main program can call, eg i2c.start means that in the i2c object there will be a "PUB start" somewhere. PRI methods are internal to the object.
Yes there is. In fact, you can have 7 cogs doing this in parallel.
Take a look at some objects that have pasm in them. There are pasm instructions like rdlong and wrlong that move data from the cog to the hub memory and this is how your spin program interacts with the cog program.
In general you declare a variable in your main program eg "rpm", and then when you start up the cog, you pass the location of that variable to the cog. Often there is a list of variables and the first thing the cog does is grab that list and copy them to local variables within the cog.
Pasm can be a bit tricky to learn. I found it best to pick a typical object (eg mouse, or keyboard) and pull it to bits and try to work out what it is doing.
I was thinking you could set a global variable in the "Main" and start a new cog with COGNEW which would basically call a Public function. The public function would just repeat the code in that function. Guess it does not work that way?
I still don't understand how to use the jm_freqin code. I can't even get it to output anything to my LCD display. I don't know how to properly call it to start reading RPM. The whole spin language to me is 100% new. I don't remember even writing the code I already have since it was done probably a year ago. I have tried to read over help files and tutorials, but what I am trying to do does not come in a tutorial
I do like the idea of keeping everything in one folder and named accordingly. I will have to do that right now.
Always bring power up on a new system SLOWLY, and watch the current whilst doing do.
If the device is in a socket, remove it on first power apply and check Vcc.GND pins are what you expect.
Common mistakes are Vcc-Gnd shorts (not fatal), Chips backwards (not fatal, provided you avoid amps of flow), and over-voltage.
You are powering the Prop off 3.3V, right ?
[PHP]CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
solenoida = 2
solenoidb = 3
upbutton = 0
downbutton = 1
VAR
OBJ
num : "simple_numbers"
PUB Main(gear)
gear := 1
gear := shiftgear(gear)
repeat
if ina[upbutton] == 1
gear++
gear := shiftgear(gear)
if ina[downbutton] == 1
gear--
gear := shiftgear(gear)
repeat while ina[downbutton] == 1 or ina[upbutton] == 1
waitcnt(3_000_000 + cnt)
waitcnt(1_000_000 + cnt)
PUB shiftgear(tmp)
if tmp > 4
tmp := 4
if tmp < 1
tmp := 1
dira[solenoida]~~
dira[solenoidb]~~
outa[16..23]~
dira[16..23]~~
if tmp == 1
outa[solenoida] := 1
outa[solenoidb] := 1
if tmp == 2
outa[solenoida] := 0
outa[solenoidb] := 1
if tmp == 3
outa[solenoida] := 0
outa[solenoidb] := 0
if tmp == 4
outa[solenoida] := 1
outa[solenoidb] := 0
outa[16..23] := numbers[tmp]
return tmp
DAT
numbers byte %0000_0000, %0101_0000, %1100_1110, %1101_1010, %0101_0011[/PHP]
EDIT : To be a little more specific other than "Ouch something hurts"...lol. With the code above, the load into the eeprom or ram goes good. Once it is finished the display does not come on. I don't have anything hooked to the solenoid circuitry since before I programmed it, it worked correctly.
Next, I'd insert a simple program at the top:
PUB Test dira[16..23]~~ repeat outa[16..23]~~ waitcnt(cnt + 80_000_000) outa[16..23]~ waitcnt(cnt + 80_000_000)See if that makes the LED blink 8.
Debugging can be done with a fancy display showing numbers, but many times you can debug just fine with a LED. Take circuitsoft's "Test" routine and copy it to a routine called (say) Test2, and change the waitcnt value to, say, 40_000_000.
Now you have two routines - one flashes fast and one flashes slow. You can test if the program gets to certain points eg
repeat if ina[upbutton] == 1 flash_fast ' flash led fast 8x gear++ gear := shiftgear(gear) if ina[downbutton] == 1 flash_slow ' flash led slowly 8x gear-- gear := shiftgear(gear)Addit - re the crystal - probably the crystal is ok, but the crystal part of the propeller chip might be damaged. You did cook it quite badly earlier, right?
However, if that bit of the prop chip is zapped, other bits might be zapped too, and it is going to get hard to debug if, say, one cog is unreliable, or one pin works but the next one doesn't.
Did you ever work out why it got hot? eg rebuild that circuit with just the regulators and no propeller or display attached, and see if it gets hot. If it does, pls post a photo.
I've always found it helpful to have two of everything when building new circuits. Worth getting another prop board? (You can never have enough propeller boards, right?!)