gemellocattivo.com

Which means "Evil Twin". Lets see your projects where you change boring into fun or create the fun from scratch.
It is currently Fri Mar 29, 2024 8:59 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 8:48 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
I'll add this...after having the ability to right click, add gauge/plot/log for literally any value the system reads or calculate it would be very difficult to give that up. Same with "programming" in a higher level language...hard to impossible to go back. Enginelab got a lot of things right, not everything, but a lot of thinks.

Having been around the open source group....the programmers can be very militant about copy left, the users are on the whole just really REALLY cheap bastards. It was the cheap we couldn't deal with at o5e....shit like lets reprogram GM ECUs, the whole ecu at a junkyard if $100! and 3/4 of the team was running in circles for 6 months wasting time on a nearly impossible project. My point is I don't believe the users actually care if the project is completely open source....closer firmware like enginelab then then lets the user create open projects would almost certainly be fine with 99.9%.....if the HW is cheap enough.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 11:33 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
So something like EngineLab quality hardware, but with a more open user development environment? Where you can write code in the modeling language or C, and load that onto the ECU, and use all of the closed hardware IO libraries (for timing, analog, comms, logging, ...), and a GUI and API for logging and calibration?

I think open-source attracts a lot of people with a variety of motivations, and some of them are definitely motivated by the low cost.

Also the whole idea of Speeduino running on an 8 bit MCU is terrifying to me. There's just no way they will ever achieve more functionality with such a limited MCU.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 12:41 pm 
Offline

Joined: Fri Jun 12, 2020 11:49 am
Posts: 14
I can coment on that as i sell around of 500 standalone ecu's based on speeduino firmware per year, nowadays speeduino can be usef on teensy and stm32 which are very good MCU's, eveb with the atmega the performance is good enough for an entry level system, you have to take in consideration that most people that use it doesn't use it for very high performance engines where mor e protection layers are required but instead its for small engine swaps and budget trackday cars.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 1:18 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
2 question then

1) if you're doing well with speeduino why look at o5e?

2) when you say works well....have you ever seen data on the timing accuracy? I don't know, it might be fine but I never looked at speeduino as I assumed the timing control was inadequate. The rusEFI guys said theirs was good, the data said otherwise....good enough to safely run an engine for sure but pretty far from OEM specs that something like o5e with a dedicated timer on each channel delivers. I've never seen the MS data either but they are using an ECU chip, just pushing it quite a bit beyond what it was designed for channel wise so I have to wonder.

The FPGA would get you equal or better than factory accuracy, that is the only reason to use it or any of the real ECU chips.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 2:36 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
MS is still using an S12X right? So it's a "16 bit" micro with a basic timing co-processor, which should be adequate for a low cylinder count engine (it's designed for very low cost automotive where a 32-bit micro is too expensive). As you get to high cylinder counts it may or may not have issues, depending on how its coded.

I don't think an FPGA vs eTPU or GTM would have any difference in timing accuracy, but anything that uses a basic timer and crank interrupts would probably suffer. I know I saw a massive difference in timing accuracy and engine idle quality going from the MS3 to an older TPU (pre-eTPU) based ECU, but that was a single cylinder engine, and those are fairly notorious for causing crank accuracy problems since the RPM changes so drastically between each tooth.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 3:43 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
yeah, s12 but the MS3 is an s12x....they are using the xgate for all the timing stuff I'm pretty sure in that version. The cylinder limit was timers...as the chip was designed for for low cylinder count and low cost. I think they are taking the timers they have and sending interrupts to the xgate that processes the request and are using a single timer for multiple cylinders which works fine until items on different cylinder want ot happen at the same time and can't....so there has to be some "clunker" points where ALMOST all the timing data look very good.....at least that is what I'd expect to see. Some year back they were claiming up to 16 cylinders....no way that works well at rpm., diesel industrial engines only I guess.

The cosworth F1, then pectel ecu was a 555 but they didn't use the TPU, they added a FPGA for all the time critical stuff as the TPU couldn't keep up with F1 demands but it was wildly in automotive ECUs...the 1st couple generations motec and haltechs also used it. The 5xxx chips were to solve that need for speed and the demo code was created for and used in the V12 F1 engines and validated, as in not more than 0.1degree error up to 24000 rpm.

The S12 and xgate (that I think runs double clock speed) is 16 bit. The eTPU is 24 because 24 is needed to meet the 0.1 degree crank position spec...with 16 bit if you set the ticks per tooth low enough to now roll-over during cranking you just don't have enough ticks at redline to be accurate enough....so I just don't see MS holding anything like the OEM timing specs. And I kind of know they don't...years ago I bought a hall sensor from DIYautotune that they sold for MS setups....I couldn't make it work....they told me they never have a problem...I bought another, also didn't work as in I could not maintain sync with the test wheel I has spinning in the lathe. hmmm....The scope showed a tom of jitter out of the sensor, I switched to a brand name sensor and the sync issue was gone. The jitter was causing the signal to fall outside the time-out window, which I had set as wide as possible and still see the missing tooth. There is no frikin way that sensor can work unless the the ECU is doing an averaging, if it was check not error checking it would not be able to find the missing tooth repeatably. Also, Paul, the guy who did the eTPU setup for us worked on an open source 555 project with the MS guys, lots of aguing and Bruse and Al let and MS was born, but Paul was telling me they has sync issues and he wrote a least means square routine for the TPU that solved it...it looked at 4 teeth, I assume that is still baked into MS....and they can read about ANY sensor as a result but at the cost of lag and accuracy.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 4:19 pm 
Offline

Joined: Fri Jun 12, 2020 11:49 am
Posts: 14
That's how i found o5e, through a documentation from freescale for a megasquirt/freescale ecu something like that!


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 4:56 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
Rafa_bmx wrote:
That's how i found o5e, through a documentation from freescale for a megasquirt/freescale ecu something like that!


I think I still have that freescsle ECU.....unless I sent it to Jon? not sure. The MS3 was designed for a 5634 and they were having eTPU code created, then decided the s12x got them what they needed with a lot less effort I guess and the 5634 died.


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 5:15 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
The biggest difference between the 555/565 with TPU and eTPU is the TPU doesn't have the hardware tooth decoder, it relies on microcode for this, and fundamentally the TPU does not have an angle clock and only can schedule one event in the future. eTPU has the angle clock (so the hardware tooth decoder feeds an angle counter bus, and timer events can be scheduled on the angle counter) and also two events per channel (so it runs code less frequently to reschedule events). The TPU results in similar functionality to the xgate, although most chips had 2 or 3 of them with linked timer buses so you could run a lot of channels.

Averaging 4 crank pulses would definitely cause accuracy problems for an odd firing engine.

I kinda wish the 5634 ECU would have gone ahead, it would have been much better than S12X.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
 Post subject: Re: o5e firmware
PostPosted: Sun Jun 14, 2020 5:22 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
I kinda wish the 5634 ECU would have gone ahead, it would have been much better than S12X.


Yeah....I met Bruce for lunch one day and we talked a bit about the o5e team becoming the MS5634 team and at the time I wasn't interested but in hindsight it was the right choice for the project. Live and learn.

But today, the right choice is an ARM + FPGA + labview 8-)

I tried a bit to talk the rusEFI guys into a next gen and it bounced around a bit...and died as they don't believe they have a timing issue and for most users that's probably true.


Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group