Sam, I was concerned about the soldering of Surface mounts and DIY as well. We need to get you signed up over on DIYEFI if you have a little time to discuss a bit in more detail? http://www.diyefi.org/forum/viewtopic.php?f=5&t=738 I think you are probably right on the RS-232. I have a plug in card for my laptop to give me a serial, but it would be better not to need to go that way. Again, if you have some time to discuss it on the hardware thread so I'm not just tying to repeat everything back and forth, but I'll do it anyway you perfer beccasue I appeciate the help and input. I'm going to copy and paste your post(s) for now to make sure everything is captured. Is RS-485 usb? Mark
No, 485 existed long before USB. 485 is a very noise-immune 2 wire differential signal with bus architecture. I understand automotive designers are often now implementing CAN bus. USB is typically 4,6, or 8 wire and a completely different protocol. I've heard 485 is still an excellent application for automotive use.
Good day, Indeed, USB is not RS-485... completely different protocol and electrical interface requirements. RS-485 is an electrical signaling standard only, whereas USB involves electrical, mechanical (i.e. connector types and usages), and the communication protocol. Although RS-485 uses two wires for its electrical signaling, it really needs a third wire as reference. So, to have a bullet-proof RS-485 network, three wires should be used (two for signal, one for reference). I could go into more details on this, but I do not want bore people too much . I could be mistaken, but USB is actually a total of four wires where two are for communication (D+ and D-, and the other two for supplied power, if needed, and ground). Cheers, Sam
Right on 485 Sam, I neglected the ground wire. Correct that there are 4 wires for USB 1 or 2, but I've been told there's a newer USB3 spec that has more wires. After checking, I see it's not 6 or 8, but actually 9 wires. Not claiming to be an expert, though.
USB 3.0 isn't really out in the market yet. I don't suspect we'll need that kind of data rate to talk to the ECU anyway. It is on the order of 4Gbps or so. USB 2.0 (or even 1.1) compatibility is likely sufficient if we're talking about RS-232 replacement.
I knew you guys were out there lurking Does 485 make sense for this application? The EUC and pc need a 2 way connection so sensor data and ignition timing, fuel pulse ect are displayed on the PC while map cells are adjusted in the ECU? Here's the software plan seem though the eyes of an ME, help me out where I'm going wrong. I'm thinking elegant code is not what we're after....we want it as modular as possible so multiple people can be coding and it's as easy as possible to add features. Start with the basics and roll in the cool stuff or additional options. My plan is to make a list of all the software functions listing what inputs, what outputs and referencing all timing from Cyl1 TDC. The code for the timing will be the first thing done and everything to follow will pick up the timing and other sensor data from some common location so in theory we can just go down the feature list adding stuff. Does this sound right?
I signed up a system architect tonight. I’m scaring some of the original FreeEMS guys….something about not possible this and can’t do that and I can’t wait to see how you handle blah, blah blah and TR heads don't fit on a 400 block. No vision. The project is right on track I’d say We need to pick out a chip.
We are eyeing up this chip http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5554&nodeId=03t3ZGpnLnPCbf%25200325 This chip would give us a motec killer when finished. The real problem is that it's 416 pins....not a DIY thing. The board, at least the chip part would have to be made commercailly and we'd be pushing right up against the $1000 price target most likely and I has hoping to come out more in the $600 range on the board. Another option I'm thinking would be to design the board with 0805 components that are large enough to install be hand then have the board made with just the chip on it and DIY the rest of the stuff. Does anybody here know anything about getting boards made (or have the equipment to do it by any chance ) and can comment of cost or have any suggestions for holding cost down?
The new thought is it makes more sense to use 2 boards. 1 for the processor, inputs and anything sensitive and a second for the power supply and high power outputs. It also doesnt appear there is any real hope of much DIY on the boards. The processor has 416 pin al by itself. So commercial surface mount boards then DIY any through hole stuff and wires and the case. I still feel good about the $1000 cost even in small runs .and it will still be one hell of a bargain
Good day Mke, The PPC processor that you are thinking about has a BGA footprint... fortunately it has a 1 mm pitch when means that you can have the PCB fabricated rather easily. Pitches less than 1mm (like .85mm and smaller) will require via holes that exceed/push the capability of mechanical drilling and so the PCBs for these pitches will need laser drilling... which is not too common here in North America and so the PCBs would need to be fabbed overseas... which means reasonable PCB volumes otherwise PCB cost can be expensive... As for the PCB itself, with 416 pins, you will need a minimum of 6 layers as a quick guess and perhaps even 8... So, your PCB fabrication costs will be a factor. Even your prototype PCBs will be somewhat pricing ... over $1000 per prototype design + a test fixture. Also selecting a BGA package will force even the prototypes to be automated assembled... which again will add an increased cost just for initial testing (i.e. setup, stencils, etc) I suspect that you do not want this project to cost more than an off the shelf solution so I would try your best to see if you can select another processor that can use a 4 layer PCB and in a QFP (quad flat pack) package (so that you can hand assemble the prototypes) in order to keep your out of pocket development costs reasonable. The other issue that really must be considered with the processor is the firmware development tools. Commercial PPC tools can be expensive (over $5K or $1K per year for a lease), although open source ones may be available. Sometimes the optimum processor choice may not make sense because of tool and assembly/production costs. I personally do not use the PPC architecture, as I prefer Freescale's Coldfire and iMX product lines... as they typically have a breadth and diversity that allow me to use them in almost all of the products that I design. I am doing one project now using the ARM Cortex M3 which is indeed nice, but I find the tools not as rich as the ones I use with Freescale's processors (Codewarrior). My last two points I mention involve component availability and longevity. These days a lot of electronic manufacturers are not maintaining any inventory and so lead times are stretching out to 4-6 months in cases. So, select a processor that has good availability (I am currently having a nasty time finding Cortex M3 processors... a number of them are unavailable until late October) and one you can purchase in reasonable volumes. A number of suppliers may have a MOQ (minimum order quantity) which can be a bit pricey. Longevity is also something I would consider important. Many processor manufacturers obsolete parts and so you could be hooped if you need a processor in a few years time. So, having a separate board for the processor may be a good idea to allow for a processor change if needed. For what its worth Freescale has an excellent record for maintaining long life on parts. This is because Freescale (used to be Motorola) designs a lot of their parts for the auto industry which must have a 5-7 year availability. Texas Instruments (TI) is one of the worst for obsoleting parts and have burnt me a few times because of this. Cheers, Sam
here are a couple suggextions that were thrown out on the other forum. Boards made here: (http://www.goldphoenixpcb.biz/special_price.php) Assembly here: http://www.lil-brother.com/ And this: "To go back to Mark's question, if I were to build a Motec killer, I'd look into the MPC5554. This is specifically designed for engine management and while it will do much more than what is specified, that's not necessarily a bad thing if you shooting for the best. The problem is that it's a BGA package but if you get a professionally made board that may not be an issue. A second issue is the dev tools but it seems that gcc is available for PowerPCs (which is what the MPC5554 is) and specifically for the MPC555 (a previous version). I have no idea if it's a good solution and how easily it would be adapted to the new chip but it would worth looking into." What do you think about this? You are correct that the idea is that this should not cost much to develop in $, only time. At 6-8 layer the board would be 2 for $750 and then assembly costs, 4 layers is a lot cheaper. There are other Freescale chip versions with lower pin counts .where do we need to be to put it on a 4 layer board? The chip has to be automotive grade and have a good number of timers, but only about 100 pins are actually required. The issue as I understand it is the low pin count chips assign 2-4 functions per pin making it very hard to actually get all the stuff you want to work vs the a 1 function per pin chip where you are guaranteed to have what you want. The general thought was that with more pins is was just plain easier to get the processor board right on the first crack does that sound right? I was thinking the go would be to do the design and make 2 boards and hope they are right. The other option is to buy a development board for $1000 and use it. Make the final power/output board and a temp input board and the thing should work .but wouldnt be pretty until I order proper board leaving me stuck with a $1000 development board. I dont know which direction puts more money are risk?
Sam, what about this 256 pin version http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5554&tid=tApom Will this go on a 4 layer board? It's only 24 channle though vs 40 ch on the 416 lpin version....that might make things harder.
Good day Mke, I have no experience with either of the PCB or assemblies houses you recommended. My concern is primarily with PCB manufacturers and quality can be all over the place. For simple circuits this is not a big issue, but as frequencies and edge rates (switching rates) increase so does signal integrity and EMI issues. Consequently, I do a fair amount of signal integrity simulations so that I am extremely confident that my boards work the first time out... However, this only works if the PCB house is experienced and has an excellent process. If not then the PCBs and all of your mounted components are basically throw-aways... There is nothing worse than debugging a design only to find the PCB house has a sloppy process. So as a minimum, all PCBs (> 2 layers) made should have electrical test done by the the PCB house to rule out at least some basic continuity issues. So, whoever is designing the hardware I would let them choose the PCB house they feel comfortable with (i.e. have used them in the past). Don't select a PCB house simply by price! The same can be said by the assembly house. Mounting BGA's is not overly hard (by an assembly house), but you must know what you are doing. Ideally you are supposed to x-ray the BGA attachment or use special inspection prisms to check, but to date I have not had the need to do this as my assembly house has been fantastic (0% failure on all of my BGA designs). As for what dictates the number of PCB layers... there is no exact rule of thumb here. Typically the more pins you use the more layers you will need. Again for reducing overall design costs, selecting a QFP package device will the costs... however at the expense of perhaps more PCB real estate and possible signal integrity issues (QFPs can be big packages and so longer bonder wires from the IC to the pins... so more parasitic inductance and possible integrity problems... that is the make reason why manufacturers have went to BGAs as well as less mechanical stress... BGAs occupy less mass, etc) As for the PPC chip, indeed these chips have roots in the automotive field and could be a nice chip. But unless you have worked with these chips in the past and know what idiosyncrasies await you (erratas on the device), you increase the risk of having a poor first design... experience plays a big role here especially to minimize out of pocket costs. My suggestion would be that the hardware designer select a chip that he feels most comfortable with, meets the design's needs, and is suitable for the firmware people (i.e. good tools, etc). As with all designs, before running out and selecting a processor a firm functional spec needs to be generated. Here the number of I/O, Uarts, memory, temperature range, and other specialty functionality (i.e. USB, Ethernet, etc) is included. Next an idea of the performance and memory needs (RAM, Flash, and possible external DRAM) are also required. From here a list of possible candidates can be chosen and then weighted (price, availability, firmware tools, design complexity, etc) to determine what would be the best candidate. In order to expedite the project, it would be best if you could find a development board you could use. The reason here is that the firmware guys can start writing some cold as the main processor hard is being designed and tested... thus you have a few tasks running in parallel. Secondly, using proven hardware will assist with the debugging and start-up of your custom hardware. In the end you could then sell your development board on EBay or something and recover some of your investment. My suggestion would be that you purchase an already made industrial controller board that meets your processor needs and then just make your own I/O board. This would be the least expensive approach and would remove the necessity for you or whoever to worry about the complex PCB manufacturing, assembly issues, and component purchasing/sourcing issues. There are a number of companies that make these type of small compact modules (i.e. DIMM form factor) and not too bad of a price (anywhere from $100 to $600)... for all sorts of processors and memory configurations. Cheers, Sam
Good day Mke, This would be dependent upon how many i/O pins you are using, the number of power/ground connections, and how the escape routing would be done. Given my feeling of how many I/O you will be using, I would think that 6 layers may be needed. If you plan for 6 and can ultimately route to 4, then great... but if you budget and plan for 4 and you need 6, then there could be issues. Remember there may be signals that may cause you to go to more layers because of integrity/EMI needs... Secondly, the number and location of power and ground pins may close off routine channels or may reduce your power/ground pins to swiss cheese and thus reducing their effectiveness. I think that first step is to define all of the functionality you require and then the number of I/O pins needed... plus a few more for testing and debugging. The last item is missed a lot of times and if implemented correctly can save a bunch of time during development. On a related note, I would also think about some sort of test apparatus to emulate some of the vehicles sensors... This would assist the hardware and firmware group in their efforts, as this way they could easily test and debug without having to always having a real car/engine around. On a number of my projects I write simulation models for testing and debug. In one design I emulated (in VHDL) the read/write functionality of a processor as it related to a specialty hardware device in a FPGA... this saved a few weeks of testing for sure. So, please have your hardware and firmware group(s) think about test hardware and what needs they may have for real-world testing. Cheers, Sam
Good day Mke, I just did a quick search and found this already made controller: http://www.phytec.com/products/sbc/PowerPC/phyCORE-MPC5554.html These guys tend to have pricey controllers, but could be open to negotiate on price? On last thing, if you guys choose this processor, contact Freescale to get an idea as to where its at in its lifecycle... I think that it is a mature part and given the shake-up in the auto industry it may not have a reasonable longevity... Cheers, Sam
Thought from the DIYEFI site "MPC555 = working GPL FOSS ECU code in diyefi.org site right now. Compiler plus timers = your choice. I was under the impression that the etpu stuff etc wasn't handled by gcc, but i never checked... So much else to say, i'll have to post this thread again tomorrow. fred." The 555 isn’t as powerful or fast as the 5554, but it should be plenty adequate (I may have to give a little on the optional I/O count but those numbers are not magic), is basically compatible with the base FreeEMS version code and development tool wise and gets us back to at least talking about DIY boards….although I still like the phytec (or similar) option, at least to get started. Here’s what I’m thinking. Phytec processor board packaged with a I/O board to do the inputs and low power outputs. Then a second case for the high power output like injector drivers and ignition. Not the neat 1 box answer I wanted, but not bad and way less risky to get working. The I/O and driver boards shouldn’t be real hard or real expensive so id there is a mistake or something does work as planned it’s not a real big deal.
Heres what Im thinking on the function spec .but I need to think about it a little more. This will be a document to show what needs to happen and what it need to do it. Does this seen useful or is there a better way to lay it out? This is going to be a BIG list. Image Unavailable, Please Login
I'm not sure if I thru you off on my "function" nomenclature, but in C++ a "function" is a piece of code that you want to stand alone (meaning passes variables in and out which is what makes it unique) that can be integrated into other programs IF you include the library that contains the "subset" of functions that you are using ... the extra library may or may not be necessary, but generally for certain hardware you are going to be given/include the ".LIB" file ... it's been a while since I've had to setup my compiler .. it might be a ".OBJ" file come to think of it. So when you say function and you have air temp for instance how is that related? I'm sure there's some system you're using. What I would do to outline this is group what I think you are calling functions into the specific I/O you are planning on using .... i.e. 16 bit analog inputs, 0-5V ... list them. Same for outputs, etc. with the current, etc. ... edit: some of these inputs will have a way faster clock speed or be interrupt based ... this would be another way I'd group input/output tasks (better term than function when dealing with C++ programmers ) ... like the high speed input for the crank trigger. make any sense? cheers
It does make sense and I was thinking was the next step. What I'm doing was just trying to sort out what need to happen. I should have said "measure air temp" instead of just "air temp" What I am trying to do is come up with a good way to tell you programmers what the softwhere will need to do so read all these and do that. "Measure air temp" is going to depend only on the air temp sensor, its a primary function. "calculate injector pulse" will depend on air temp, coolant temp, MAP, TSP, TSP change rate, fuel map, fuel trim , and a few more so it goes way down the list. "fire injector" will depend on "injector pulse" and "crank postion" off the top of my head. What I want to do is spell out all the relationships. Does this make sense? Oh, and appearently we will be using C and GIT not C++. who knew. Last if we use the MPC555 processor it appears most of the existing and mostly working code will work. It's an older chip but....it saves a LOT of work.
And this is totatly simplifying, but once you get the data in memory from the inputs, you use multi-dimensional lookup tables to create non-linear relationships/values that ultimately will be read (or "pointed to") by devices/outputs ... but at some point someone is responsible for defining all of this ... that someone is you, but we are doing what has already been done already no? .. in terms of engine management? .. meaning the basic physics of the i/o ... I've not read every post here so maybe you'e going off the deep end . cheers edit: I think my point of this post is I'd lay out the hardware config and get your hardware guy to understand the clock speeds and interrupts that need to be going on with all the inputs & outputs. This is the issue with robotics .. how may axes we controlling? .. how many analog inputs and outputs at what speed? ... discrete I/O isn't an issue which gets lumped into the I/O which makes "thousands of inputs and outputs" not seem like a big deal (edit 2: ... getting really geeky now but it is an issue if it's "interrupt" I/O which I don't think we need) ... A/D D/A is a memory/clock hog though vs. just discrete I/O ... basic thing but a reason to make sure hardware guys understand all the goodies you want AND at what RPM ... big big factor.
I think we are pretty good onthe hardware at this point for most of the stuff. The processor board is a bought item now The I/O stuff is already designed for the basic version, we just need twice as many of everything. We need to have a clean top level plan that spells out the physics. It's all been done before but we done have that closed source code, we need to write new open source code and make sure we get the physics right. What we need to do is spell out the physics clearly THEN spell out how the code will make it happen or sure as **** will will miss something important.
