I don't know enough to know what creates serious hardware conflicts and issues. I just know I'm working with a "new" controller right now that has a bunch of great performance spec's and is not as accurate as a controller I use/used (discontinued) that is a 20 year old platform. To simplify the application all it is doing is controlling an analog output at high speed. If this is all simple to hardware guys great. I just don't understand why a newer system with way more processor, 10x faster program execution, is not as accurate when it's simply controlling a high speed analog output based on inputs/lookup tables ... just seems hard to nail down the hardware when you don't know all the pieces you're controlling at what speed? So once the hardware guy lays out his architecture, we should be able to test a small portion of something and see how easy it is based on this hardware being all figured out already (in smaller sections I understand). That's great if it's really that scalable with existing pieces and parts. cheers
You might want to use "Cam shaft position" instead of "Crankshaft position" as the intake valve is only opened once for every 2 revolutions of the crank. this will allow you to inject fuel when the velocity of the port is at its greatest speed and not have fuel sitting in the port while the valve is not flowing.
I was thinking crank position from 0-720 with 0 being #1 TDC. Then injection ends at say BDC on the intake stroke or 540 degrees then you calculate start as 540-(crank angular velocity/pulse length) for something like that. TDC is easy to understand and measure, it seems a good place to reference from.
Yes, as soon as we settle on a processor I will worder a development board, turn the hardware guy loose on the I/O board, and order a JimStim (an engine simulator the MS guys put together) and it's time to test code.
What you can use the Crank Position Sensor is to determine what cylinder is at TDC I.E cyl 1 and 4 on a normal inline 4 engine. This will tell the ECU what cylinders need fuel or spark. The Cam position sensor will then tell the ECU what cylinder to inject fuel into and what cylinder to fire a spark. Since the Crank position sensor will tell the ECU what cylinder is at TDC without a Cam position sensor input the ECU will have to fire a "Waste" Spark or injector pulse. The Crank position sensor gives the reference of what pistons are at TDC but does not tell you what cyl is ready to fire or is on overlap. The only engines that will run without wasted spark and fuel injection is a "Big Bang" 4 stroke or 2 stroke.
Everything you just said is true, doesnt matter really Using the Cam which is a true 720 degree is fine but inaccurate without a crank sensor and is difficult to measure the reference point you are measuring from. Using the crank is more accurate and easy to measure the reference point but requires a cam position reference to convert to 720 degree system. Either way you need both the cam and crank to sensors, but its easier to work in terms a 720 degree crank position so this is the way it is normal done and what will be done on this project.
Development tools It appears the MPC5554 is supported by the free GNU GCC complier, but what else is on the must have list. ? I see phytec sells a tool kit for $799 to go with their board that includes the GNU compiler, debugging stuff ect .but it this stuff out there in free land?
Good day Mke, At times free tools take time to find (correct versions, etc) on various places on the internet, and build (yes you have to "build" the various tools), etc and so spending some $$$ on pre-built tools can save you loads of time. As an alternative, you could contact your local Freescale FAE (Field Application Engineer) to see if they have any pre-built GNU tools for this processor, as this could be used as a starting point... and would be free. Your firmware people would then need to modify the tools a little to generate a BSP (board support package) for the Phytec development board (i.e. support the devices like memory, etc on the Phytec board). Be advised that depending upon the firmware group's experience, several hours could be easily consumed doing this. Cheers, Sam
It sounds like you are recommending buying the phytec package because its there and it works and that sound like good advice. I dont need projects on top of projects. Will 1 seat, one board, 1 engine sim do? And when are you going to jump full in and help? This is a very cool project
Plus Gen1 hardware plan PhyCORE-MPC5554 SOM processor board http://www.phytec.com/products/sbc/PowerPC/phyCORE-MPC5554.html Low power I/O board mounted in case with processor High power I/O board in second case Is everyone good with this plan? Comments? If the phytec board is part of the design I might be able to talk them into a special price for anyone calling and saying FreeEMS+ Is anyone else out there thinking of building one some I can try to get discounts of stuff?
Are there any serious embedded code guys lurking here that can help with the tools...like what we need ans if something decent can be had for free somewhere?
Good day Mke, Indeed, if it were me I would just spend the extra $300 and buy the pre-built tools, as I know far too well how much time it takes to locate, build, and debug a free tool set. That being said, I would talk to a Freescale FAE to see what he may have available... and he would serve as an excellent resource on processor specific nuances. Most distributers like Future, Arrow, Avnet have in-house FAEs too that can assist. It certainly would be worth a call. As for my involvement, I wish I could but I am already doing 70+ hours per week with no spare time until sometime mid next year... In fact, I have 1000's of lines of firmware to write in the next few months on one project alone...let alone two major hardware designs, EMI/EMC compliance testing, an injection molded enclosure design, etc... However, feel free to contact (e-mail or phone)me if you need some candid and abstract input on things. Cheers, Sam
If it was $300 I wouldn't think abotu it...but it's $800 and I have to think about that. What tools do I really NEED? I understand busy, if you can keep checking and and guiding that is a big help too. (your PM mail box is full - my email is [email protected])
Can somebody help me understand why 16 bit code can't be pretty much used on a 32 bit processor? i see the problem clearly the other way around, but I think a bit tune up for the pins and such and we would be good to go for 16 to 32 no?
Good day Mke, Well, you can ... sort of... However, your comment is a little ambiguous, and so there can be a few ways of interpreting it: 1. If you mean you have high level source code (i.e. C, etc) that was written for a 16-bit, then the "port" should be fairly easy... maybe some data type declarations may be need (i.e. long or short data types can have different sizes depending upon the compiler). However, the re-test of the code will be necessary 2. If you have 16-bit compiled code (i.e. library or object code), then this really cannot be done... The reason is that 16-bit compiled code is specific to a processor (independent of the 16 or 32 bit size)... it would like putting a GM cylinder head and place it on a Ferrari engine block... this would not work out too well 3. If you are talking about non-embedded code (i.e. Windows programs) using a pre-compiled 16-bit output then maybe depending if one can use a "thunking" layer or not... If you re-phrase the question or present more detail I may be able to answer your question better. Cheers, Sam
Good day Mke, My apologies, I thought the price you said earlier was for both a development board and the GNU tools and so that is how I came up with the $300 difference. Indeed, $800 is a bit steep but not entirely unheard of. I know of one tool vendor that charges over $1000 for a customized version of Eclipse and the scripts to work with GNU tools (not for the PPC processor). Have you or someone talked to a Freescale or Vendor FAE about GNU tools? Your firmware people should be doing some poking around to see what is available... a few hours on the web should reveal what is available... I know that I would certainly try to find all the tool pieces and at least attempt to build the tools once... As for my PM, yes I know it is full. I rarely check my PM and so it is useless to send me an e-mail if you wish me to see it. The best method is via my direct e-mail and so I will send you one this morning so that you have it. Cheers, Sam
Sam you hit it on #1, sorry I wasn't more clear. Thanks i got a question on the DIYEFI forum that I'd like to ask for your help with Do you think you could make the call to phytec or freeScale to find out how wellthe GCC compiler actually works? I don't know enough (yet) to ask the right question or truely understand the answers. I know you'r not in (until mid next year ) but it you could spend 15 -20 minutes to help us avoid landmines with the compiler it would be much appreciated. Mark
Good day Mark, In general, the GNU compiler is actually very efficient and can go toe to toe with the commercial compilers. The issue typically is support (i.e. the compiler is doing something silly/wrong) and so with GNU tools one has to roll up one's sleeves and go through the source, etc and figure it out. With Commercial tools, one just calls someone... although you are at the mercy/schedule of the tool vendor. GNU tools are very rich and allow for excellent debugging capability... in fact depending upon the processor and infrastructure you could even do remote debugging via the Internet! The biggest issue with GNU tools is that the user really has to have the desire and know-how to dig deep if something runs amuck... It is not for the faint of heart and at the embedded firmware level is not suited to a typical desktop programmer. Now, as for your project with the PPC, I can make a call or two to the people I know within Freescale and see what they say. My feeling is that the eTPU may not be directly supported (specialty subsystem). However, for a seasoned firmware guy this should not be an issue, as all one would need to do is write in the native assembler language for the routines needed and link these into the compiler. The negative side is that the firmware person needs to really understand the TPU, know what he is writing, and how to link/pass variables to/from the calling C-functions. The last two items are a given, but the first is not as grim as it may sound, as there should be enough reference or sample TPU code kicking around... one has to ask and one has to search. Anyway, I will report back when I find out more info. Cheers, Sam
Thank you again Sam. I'll try very hard to limit the amount I drag you into this One follow up....what the h*ll is an eTPU and why do I care if it's supported?
Sam was kind enough to spare a bit of time to chat with me tonight. I need to call FreeScale tomorrow and find out if TPU is supported in the GNU compiler. I know, I know most of you are saying "you didn't check to see if TPU was supported?" ! For the few (like me) who aren't saying that, it turns out that processors like the MPC5554 have built circuits that run independently of the main processor on there own clock. They are not interrupted or bothered by anything else going on in the program/processor so they are VERY accurate at timing things like say the crank trigger, fuel injectors and ignition. There are other ways to do it but TPU is probably the best .and the 5554 has eTPU, even better than plain old TPU. I also got through the I/O doc and maybe 2/3 of the way through the user inputs. I'll get these finished up tomorrow. Afterthis I need to make a fancy flow chart to map out what all the system is supposed to do. Image Unavailable, Please Login Image Unavailable, Please Login
found this tonight http://www.embedded.com/columns/technicalinsights/190400497?_requestid=104094 About 1/2 way down the linked article it says they used GCC to compile their eTPU program Then is goes on to say way the higher end processors are better....and I found a reference to GCC working with the e500 core which is the same as e200z6 in the MPC5554. I think we're in bussiness with a FREE compiler
Here's what the guys who make the process or say: I need to go find out what is out there ready to run ti looks like and see if it's what I need. This eTPU has funtions to do crank angle, injector timing, ect...it's a perfect chip if we can find tools to go with it.
Well, they have every thig we need in c code, but nothing compiled. I've got 1 more hope for the compiler....then I guess I'll have to do it the hard way and write the machine code directly. The eTPU only does very simple things, the c code is only about10-20 linnes long so doing it by hand won't be the end of the world.....I'm guessing 200-1000 lines per function and we only need 3-4 functions I think....somehow this reminds me of when the head bolts were in the wrong place
Good day Mke, I have a suggestion... If you only need the sample eTPU functions compiled, I can do that with my software tools. Like I said earlier I have a full blown Codewarrior development suite for the entire Freescale family... except the iMX family, as these are ARM cores. The best case is that you could see if you could link the resulting object code in your gcc compiler. The worst case is that I can probably generate an assembler to "C" list file so that you could effectively have an outputted assembler listing... so you would not need to write in assembly.... just a thought ... This offer would be totally dependent upon the on what little spare time I have, but if it is simple compiles, then theoretically it should not be too time consuming. Cheers, Sam
Sam, you are the MAN! Linking in the GCC compiler would be the best option so everythign but the eTPU stuff stays in the DIY world. I know you are getting sucked in a bit more than you have time for, so I'll try and keep any future requests to an absolute minimum. Thanks Man!.....this is going to be SOOOO cooool when its done.
