I don't want any trouble, BUT speeduino

RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

I don't want any trouble, BUT speeduino

Post by RustyGargoyle »

Honestly what do you guys think of the speeduino.

Just heard about it here actually.
http://rusefi.com/forum/viewtopic.php?f=2&t=239&p=1010#p19208

Looks ok, obviously different platform then rusefi.

I hope this topic is not taboo on this forum, really not looking to get banned or shunned.

Looks like a really dirt cheap ems solution, No idea about what types of engines it supports, but it looks like it works with TS.
KLAS
Posts: 23
Joined: Tue Jul 14, 2015 8:58 am

Re: I don't want any trouble, BUT.

Post by KLAS »

i have some hardware for Speeduino, basically at the same stage as my rusefi hardware so it "may run in a not to far away future". as a guess, rusefi will work before speeduino for me because it already has the trigger wheel decoder i need.
i also try to play with FreeEMS and LibreEMS. some older Megasquirt stuff also lying around.
afaik Speeduino can handle 4 cylinders fully sequential with fuel and spark, and everything you can drive with 4 drivers for fuel and 4 ignition outputs. and yes, it works with TS.
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

KLAS wrote:i have some hardware for Speeduino, basically at the same stage as my rusefi hardware so it "may run in a not to far away future". as a guess, rusefi will work before speeduino for me because it already has the trigger wheel decoder i need.
i also try to play with FreeEMS and LibreEMS. some older Megasquirt stuff also lying around.
afaik Speeduino can handle 4 cylinders fully sequential with fuel and spark, and everything you can drive with 4 drivers for fuel and 4 ignition outputs. and yes, it works with TS.
Thank you, for your input.

Yeah, am really loyal to rusEFI, but speeduino looks like it can be cobbled together with parts from an old radio XD.
Maybe its just cause I have a few old arduino boards laying around. :D
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: I don't want any trouble, BUT.

Post by kb1gtt »

We are generally friendly here, so you don't get banned from talking about other projects. We think these projects are cool and interesting. It's good to see people doing cool things.

I forget but I think we got the the speeduino guy to stop by here for a little bit. I'm hoping he has seen the designed hardware suggestions noted here http://rusefi.com/wiki/index.php?title=Manual:Hardware#General_suggested_environment I think he has and I hope that makes his project better. I seem to recall I offered to do a hardware review and let him know my comments. I forget what came of that. I probably saw something shiny and it went by the way side.

It looks like a great project, which should work just fine for many applications. I'm not sure when it will have performance issues. The original low cost AVR Arduino can pump much less bits per second than many more modern processors. This means that as he looks to add cyl's, adds staged injection, and more features it will start to hit performance limits. However the Arduino platform has been ported to faster processors including modern ARM processors. These boards typically cost more, but can bypass most potential performance issues. So that's not a real concern, but keep it in mind you may need different hardware if you hit limitations, and that different hardware may not be currently supported. Also AVR's are known for having a "high" $/CPU cycle ratio, you generally get more CPU cycles for the same $ if you use an ARM processor. However at these quantities, the core chip is below $10, so it's not a huge problem. That $/CPU cycle ratio is important for cell phones and production runs on the thousands scale. Oh, did you know that ARM processors similar to the STM32 have 80%+ of all embedded applications? AVR's are a much smaller player in this field. However again, the Arduino has been ported to ARM processors, so not really a big deal. If AVR tosses in the towel, it can be ported to an ARM processors like rusEFI already is.

I believe the Arduino does not have a path to become automotive qualified AEC Q100. The rusEFI platform has a supported chip that is AEC Q100. However rusEFI currently has not been ported to that particular board yet. We have the board, but haven't ported to it yet as there are other efforts that are higher priority. Both rusEFI and SpeedUino are young projects, which means the bugs and weakness are still being ironed out. I'm not sure which platform has less bugs. I do know that rusEFI has many quality controls in place to prevent bugs. For example, each firmware build is loaded into a simulation system, which then simulates the inputs of an running engine, and it then verifies that the outputs are with-in a certain level of tolerances. This simulation helps prevent accidental bugs from propagating. With out quality control checks like that, those bugs are found on live hardware which can be much more expensive to fix.

Also Ardiuo's generally don't have an OS which means it won't port to other chips very easily. Porting takes more effort for non-OS projects than those that use an OS. This project uses ChibiOS as the core operating system. It makes it much easier to port to other chips that are supported by that OS. So if this chip goes bad, then we can port to one of many other chips fairly easily. That kind of item is much harder to do and more time consuming for code that is specifically written for AVR chips.

However do you really care about those features? Probably not, the above features are more of a developers concern, than an end users concern. What you care about is that it has a certain set of features, and how much X dollars it cost for those features. We have attempted to hit a wide variety of people by offering features that allow growth into other larger projects. So it may cost more, but you are less likely to hit feature limits.

I think the key differences in cost are the PCB layouts. 4 cyls cost less than 12 cyles. The Frankenso board can do up to 12 cyls with many features commonly found on an engine. I forget how many cyl's the speeduino can do. Has it exceeded 4 yet? I've wanted to make a smaller version Frankenso which does 2 or 4 cyls, but haven't gotten the time to do that yet.

Any how Speeduino is a good board, I don't know when it has limitations, so it might not work for your applications, but I suspect it would work well for many applications, which might work for yours.
Welcome to the friendlier side of internet crazy :)
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

kb1gtt coming in clutch again with some straight knowledge! :)

Thanks again.

I agree with you 100% the limiting factor would have to be that outdated AVR chip on there board.

But since you mentioned it, am gonna play devils advocate and ask, does the ChibiOS hinder the stm32s capabilities in anyway?

since its abstracting alot of hardware functionality.? Or is that all optimized in when its compiled and what not?

Sorry for my lack of knowledge regarding the topic. Must be infuriating.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: I don't want any trouble, BUT.

Post by kb1gtt »

No worries.

Yes the OS does add a certain amount of overhead which results in software delays and signal jitter. This is kind of hard for me to describe in a forum thread, but I'll take a stab at it.

Some where in this forum we talked a bunch about the jitter. From memory I recall the expected jitter for a 12kRPM 60 tooth crank signal was something less than 0.1 degrees of rotation. For talking purposes in this post I'll call it 0.1 degrees of jitter. I expect more than this level of jitter from the real world components. The hall sensors typically have circuits that are constantly self tuning which adds jitter, or a VR will have different signal phase shifts at different frequencies, etc. I expect the noise induced by the software jitter is below the noise floor for the overall system. As well the STM32 has several bits of hardware including some timers, which allows separating the CPU jitter from real world jitter. The OS uses a Hardware Abstraction Layer (HAL) which allows control over the STM32's hardware timers, and other such hardware devices.

For example, lets say that at 9 degrees of crank angle the OS calculates the time when the ignition dwell should start. Lets say that the OS would calculate that dwell should start at 10 degrees. So at 9 degrees, the OS calculates that in 1 degree it will need to toggle the pin. The OS knows the existing RPM, and can calculate how many timer ticks are required from the now time until it would be 10 degrees. Lets say it calculates it would need 100 ticks until it's at 10 degree's, and lets say that happens to be tick numbered 1,000. The OS then uses the HAL to set the timers ticks. Once the timers ticks are set, the OS allocates the CPU's clock cycles for other things, while at the same time, the clock cycles that go to the timer are counting down until the timer toggles the IO pin. I seem to recall the timer can be set for something like 15 minutes from what ever now is. So you could handle a really slow engine, as well you can handle 0.1 degrees of accuracy at 12kRPM.

Now lets pretend that with the perfectly optimized machine code, the above 1 degrees of advance is the minimum amount of time it takes to to calculate the crank angle event. Lets also say the OS induced software jitter forces you to calculate the start dwell time at 8.9 degrees instead of 9.0 degrees. Your calculated number of ticks will be more as you are doing the calculation a bit earlier. So instead of 100 ticks, you'll calculate 110 ticks. The end result is still an IO toggled at tick 1,000. So even though there is software jitter, it doesn't effect the final accuracy of the toggling the IO pin.

Now in reality, there is potentially some change in RPM between a calculation at 8.9 degrees and 9.0 degrees. The more timer ticks you have before your actual event the more error you'll have. As there could be a change in RPM between the time you calculated the time and time when the event actually happens. This dynamic change in RPM would means that your calculated 1,000 ticks would really happen at something like 1,010 ticks or some other number of ticks. However, how much dynamic change in RPM do you have in 0.1 degrees? Your difference in calculated time vs the time when 10 degrees passes is minimal.

In reality, it's a bit more complicated than this, and I made up the ticks for easier math. However I hope my over simplification and more intuitive version of the math makes it easier to understand the basic concepts.

I forget if the AVR has hardware timers or not. If it does I know they are not as advanced as these timers. These timers allow some advanced features which allows for things like cascading multiple smaller ones together to get a larger timer, with out software, and some features like that.

So yes the OS probably adds software jitter, but it doesn't effect the time when the IO pins would toggle. The additional overhead of the OS could consume some extra CPU cycles. Now lets pretend that it takes 12k CPU cycles for one rotation at 12kRPM. Lets also pretend that each spark event consumes 1k CPU cycles with the OS and would consume 800 CPU cycles if you hand optimized the machine code. This would mean that a 12cyl engine would be consuming all the CPU cycles at 12kRPM and would be at it's max RPM. Any faster RPM would result in failing to calculate the spark event. However the hand optimized would still have un-used CPU cycles at 12kRPM, so it would be able to function at a higher RPM.

So yes the over head of ChibiOS probably does limit the max RPM to something that is a bit slower than if it was hand optimized. I seem to recall the design intent is 12kRPM or more, so I don't expect the OS overhead to be an issue of concern. As well the OS will take a certain amount of physical memory. At some point you run out of space to store the executed program. If you hand optimized you could probably get more features in the same amount of program memory. I know that rusEFI is hitting that limit. There is interest in adding auto-tune features inside the rusEFI code instead of being in TS. It is expected this would take many bytes of program memory which is not currently available. One feature that's nice about the STM32 chip is that it can have an external memory chip, like the chip used on the STM32F429 board. So it's good that we are using an OS which can easily port to a different chip. When we run out of features to develop with this chip, we can easily port to this other chip which has more IO and is capable of much more program memory.

Oh also the STM32 chips have Floating Point Processors (FPU) which allows floating point math in just a couple CPU cycles. The AVR had to do what's known as bin math. By using the OS it simplifies how to use the FPU. We get to simply write commands like blah = 2.9834 + 1000. 89 and it only takes a couple CPU cycles. Using bin math is a bunch of work and there are many odd bugs you have to keep a close eye on. Or your CPU has to consume many many many CPU cycles. Using a FPU with OS saves many CPU cycles, where hand optimized code and AVR code consumes many resources.

Of course this all assumes that who ever is programming it can hand write code that is more optimized than what the OS folks have optimized. Those of us that are less talented at assembly level coding are probably going to consume more CPU cycles that the OS would consume. Remember the OS people are very good an optimizing the assembly level code.
Last edited by kb1gtt on Sat Dec 10, 2016 4:15 am, edited 1 time in total.
Welcome to the friendlier side of internet crazy :)
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

Yeah, sounds bullet proof :D

Would love to see that μFrankenso.

Yeah, I think all AVR microcontrollers come with built in timers, of varying resolution. I think the 2560 has a few 16 bit timers in it.

Seems, legit 12kRPM with >0.1 glitter jitter what more can you ask for 8-) .

You mentioned Fixed Point math. did you mean floating point?

Also a little off topic. Why dont people implement FPGA/PLDs for handling engine cycles and what not?

overkill?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: I don't want any trouble, BUT.

Post by kb1gtt »

Oops, I just updated my post. Yes Floating not Fixed. At least they both started with F and had vowels :) Apparently I can think up other works that start with F and have vowels. I said one of them when you pointed out my blunder :)

Yeah FPGA's can fairly easily get into the 5nS latency range, and it's fairly easy to add channels for ignition and fuel. However why do you need to be that fast. The S12X used by FredEMS has low latency IRQ's which are something like 10 or 15nS latency, which isn't far from the FPGA's, but again not a huge benefit. I think the SPC56xx's ETPU's were also in that category. I think the low latency processors is more because they can do it, and not so much because then need to it.

Is the complication really helpful for something that's not a needed feature? What features could an FPGA or CPLD offer? Every tiny change to the FPGA fabric would require massive amounts of validation, as any small bit of logic can effect the other core logic and mangle things in a really funky way. Remember that two bits, one commanding high, and one commanding low for 5nS causes some really messed up memory corruption, and is harder then hell to find.

FPGA fabric is a less energy efficient, so it would likely consume more electrical watts which means more heat-sinks. As well most low cost chips have less desirable temperature ranges. As well adding the memory chip to dump the program into the processors, is allot of pieces and expense. I'm assuming it would be a soft core, with external memory chip for program execution. So you have to first load the soft core, then you can start executing code. This would increase the amount of time it takes to get into a good operational state. Most people want to turn the key and go.
Welcome to the friendlier side of internet crazy :)
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

[video][/video]
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: I don't want any trouble, BUT.

Post by mk e »

RustyGargoyle wrote:
Why dont people implement FPGA/PLDs for handling engine cycles and what not?

overkill?
They do.

Adaptonic uses an FPGA, at least in the 1280 model
The Pectel ECUs do fuel/spark/crank, all time the critical stuff control on an FPGA
The motec M1 series use an FPGA for logging.... 2000 channels at 1000hz can be logged or something silly like that.

So they're out there.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: I don't want any trouble, BUT.

Post by AndreyB »

I will buy a speeduino once they have a miata pnp board I am curious to compare.

As for pricing I'd say there is no $100 way since wbo alone is $150. My focus is probably on usability, if we keep improving wiki we might get somewhere.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

russian wrote:I will buy a speeduino once they have a miata pnp board I am curious to compare.

As for pricing I'd say there is no $100 way since wbo alone is $150. My focus is probably on usability, if we keep improving wiki we might get somewhere.
https://github.com/noisymime/speeduino/tree/master/reference/hardware/Pro

mk e wrote:So they're out there.
Am not even sure if those should be called ECUs.
Should be referred to as engine domination units.

Those things look lethal.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: I don't want any trouble, BUT.

Post by AndreyB »

picture of assembled miata unit?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

russian wrote:
picture of assembled miata unit?
I think they are far AF to an assembled board for the miata pnp.

http://speeduino.com/forum/viewtopic.php?f=14&t=661&start=60

No idea why, its just the other board they had with a damn connector on it. Thing is in complete disarray.


Someone should step in and lend them a copy of kicad XD
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT speeduino

Post by RustyGargoyle »

They also threw in an mc33814

Which really confuses me.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: I don't want any trouble, BUT speeduino

Post by AndreyB »

RustyGargoyle wrote:They also threw in an mc33814

Which really confuses me.
Not in stock at mouser and digikey today but in stock somewhere else, so why not? https://octopart.com/search?q=mc33814

If we had unlimited Jared we would be using some integrated 10+ channel driver as well :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT speeduino

Post by RustyGargoyle »

russian wrote:
RustyGargoyle wrote:They also threw in an mc33814

Which really confuses me.
Not in stock at mouser and digikey today but in stock somewhere else, so why not? https://octopart.com/search?q=mc33814

If we had unlimited Jared we would be using some integrated 10+ channel driver as well :)
What do you mean by Jared?

And are you saying they are relying on that chip to drive the 2 pairs of injectors and ignition?

Thats garbage.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: I don't want any trouble, BUT speeduino

Post by AndreyB »

RustyGargoyle wrote:And are you saying they are relying on that chip to drive the 2 pairs of injectors and ignition?
No, I am not saying this. I know very little about this specific chip or speeduino, I am just not against propriatry integrated chips.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT speeduino

Post by RustyGargoyle »

Image

Maybe its not all that bad if they throw in another one, so they get full control of all injectors.

It has a o2 heater which is pretty cool.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: I don't want any trouble, BUT.

Post by mk e »

RustyGargoyle wrote:
mk e wrote:So they're out there.
Am not even sure if those should be called ECUs.
Should be referred to as engine domination units.

Those things look lethal.
They are pretty powerful, much MUCH more than most people need. I had an M150 but decided to ebay when I realized how much it cost to make it actually do what the spec sheet says......everything cost extra wiht them so I switched to the enginelab that is 1/3 the price and very nearly as capable....once you write a model for it, but I enjoy that work so for me it's a much better setup, even if it can only log 200 channels at 1000hz :)

Speedunio is at the other end of the specrum.....there is a balance there somewhere I suppose. No one wants to spend more than they need and if you have a simple setup then cheap is GREAT!.....but sometimes its nice to just have something that works. Balance.
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

mk e wrote:[
They are pretty powerful, much MUCH more than most people need. I had an M150 but decided to ebay when I realized how much it cost to make it actually do what the spec sheet says......everything cost extra wiht them so I switched to the enginelab that is 1/3 the price and very nearly as capable....once you write a model for it, but I enjoy that work so for me it's a much better setup, even if it can only log 200 channels at 1000hz :)

Speedunio is at the other end of the specrum.....there is a balance there somewhere I suppose. No one wants to spend more than they need and if you have a simple setup then cheap is GREAT!.....but sometimes its nice to just have something that works. Balance.
So enginelab also makes hardware? sounds like its just a generic platform and you "program" or configure it for your applications and needs?
did i get that right?
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: I don't want any trouble, BUT.

Post by mk e »

RustyGargoyle wrote:
So enginelab also makes hardware? sounds like its just a generic platform and you "program" or configure it for your applications and needs?
did i get that right?
Yes. You have to buy the hardware of course, but the software to run the models posted is free and has a nice simulation I thought some here might like even if you wouldn't like the HW prices.
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT.

Post by RustyGargoyle »

mk e wrote:
RustyGargoyle wrote:
So enginelab also makes hardware? sounds like its just a generic platform and you "program" or configure it for your applications and needs?
did i get that right?
Yes. You have to buy the hardware of course, but the software to run the models posted is free and has a nice simulation I thought some here might like even if you wouldn't like the HW prices.
Definitely, Thanks for looking out.
Would have never heard of it otherwise.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: I don't want any trouble, BUT speeduino

Post by kb1gtt »

RustyGargoyle wrote:What do you mean by Jared?
Jared is top secret voice or e-mail activated PCB layout tool that @russian has access too. No body knows why he has access to it, including @russian and @kb1gtt. Figuring out how to get this access is the key in getting productivity from it. Joking aside @kb1gtt's wife calls him Jared.

What ever happened with this? Did I forget todo something :) http://rusefi.com/forum/viewtopic.php?f=4&t=398&p=4345
Welcome to the friendlier side of internet crazy :)
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT speeduino

Post by RustyGargoyle »

kb1gtt wrote:
RustyGargoyle wrote:What do you mean by Jared?
Jared is top secret voice or e-mail activated PCB layout tool that @russian has access too. No body knows why he has access to it, including @russian and @kb1gtt. Figuring out how to get this access is the key in getting productivity from it. Joking aside @kb1gtt's wife calls him Jared.

What ever happened with this? Did I forget todo something :) http://rusefi.com/forum/viewtopic.php?f=4&t=398&p=4345
:lol: :lol: Maybe a case of beers might crack the code.


Why hasn't that chip been plopped on the Frankenstein? time constraints? or just not needed? Did you end up using a different method to drive those outputs?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: I don't want any trouble, BUT speeduino

Post by AndreyB »

RustyGargoyle wrote:time constraints
time and 4 layer test runs are pretty expensive
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
RustyGargoyle
contributor
contributor
Posts: 55
Joined: Sat Dec 03, 2016 2:57 am

Re: I don't want any trouble, BUT speeduino

Post by RustyGargoyle »

russian wrote:
RustyGargoyle wrote:time constraints
time and 4 layer test runs are pretty expensive
yeah the board is pretty big.

What board house are you sourcing from?
noisymime
Posts: 2
Joined: Wed Dec 14, 2016 12:40 am

Re: I don't want any trouble, BUT speeduino

Post by noisymime »

Hey guys... Someone linked to me to this thread so I thought I'd register and say hi. I'm the main dev over at Speeduino and whilst our 2 projects have different aims in mind, we definitely share a lot of the same challenges etc.

First and foremost, Speeduino is designed to be a very low cost, hobbyist friendly system. Whilst I'm working on SMD designs at the moment, the main boards available currently are intended for people to be able to put together themselves in a way that works for them. If you only want 2 channels to do wasted spark on a 4 cylinder, then you only need to populate 2 channels on the board etc.

Around the use of the MC33814, I decided it was worth trying out as it really does have a lot to offer. As it stands at the moment, I'm not using the injector or ignition outputs on the IC at all, but instead using it for it's dual referenced regulators, watchdog timer, relay outputs (Eg fuel pump) and onboard VR conditioner. Even without the inj/ign outputs, I consider it to be fairly good value both in terms of dollars and board real estate.

With the arduino, the first thing nearly everybody tells me is that it's not powerful enough and its just a toy. The short answer is though that it has more than enough power for what I'm doing with it and I'm not yet running into issues with performance at all. That said, the firmware has had to be written very carefully to achieve this, it doesn't just happen by accident. The firmware is also now cross-compilable to the K64 and K66 ARM chips used on the Teensy range of boards, with about 95% of the code remaining common between the 2 platforms (It's still a single codebase, not a fork or anything). This work isn't ready to use yet, but all the hard parts (hardware timers etc) are complete. Once it is ready, there will be an adapter board so anyone with an existing unit can plug in a Teensy in place of the Mega and be good to go (if they want).

Anyway, I love the work you guys are doing on rusEFI and I really do hope that both projects can succeed to get more openness into this market.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: I don't want any trouble, BUT speeduino

Post by AndreyB »

Welcome @!
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: I don't want any trouble, BUT speeduino

Post by kb1gtt »

Hello @noisymime and welcome.

I see we have chatted before in e-mail back in Jan to Feb, subject "speeduino V0.4 inquiry" I think I saw something shiny and lost track of it.

I know these days the AVR is considered limited, as well we are approaching the STM32 as being considered limited. We now have massive multi-core multi-GHz 64 bit ARMs, and ARM's sitting next to FPGA fabric, etc. But I also know that engines and transmissions once used things like the 68HC11 with something like a 1MHz clock which would be considered limited compared to an AVR. It seems these days the more bit pumping capacity you put in the chip, the more we just use lazy bloated high level tools. Why write assembly level code when you can use a C compiler? Why use bin math, when the FPU allows floating point? Why write lower level code when you can let an OS and HAL deal with the chip specific stuff, etc. I'm sure in another year or two we'll have a multi core 64 bit, and we'll verbally suggest how it should evolve, then we'll let it stew for a bit and it will code itself. If C and C++ are considered high level coding, I guess that would be called higher coding :) In reality, pretty much any processor these days can do the crunching required for a traditional engine. I think that things like electric / hybrids or the multi firing of direct injection might require some more resources. However I think the larger bit pumps haven't really changed the engine controller much, the IO is still pulsing about the same as it always has. It's really a question about the developers preference. The every day end users doesn't really know the difference.

Any how welcome to the forum. Should we start a Speeduino thread where we can discuss Speeduino stuff? I guess this thread has speeduino in the name, should we consider this thread a speeduino thread?

I'm a big fan of combined efforts. I kind of feel like a place were we could have some common ground would be in a simulator. Something that simulates things like load dumps, VR signals, ambient temperature, etc. Such that we can test against some kind of real world environment to ensure bugs don't get out. We recently had an 8 hour drive in Dallas. I was expecting it to overheat, with out a heat sink, but it didn't. It's nice to know it successfully upheld the design intent at least under those circumstances. I still question if that was simply because it wasn't at the max ambient, or something like that. It would be nice if we could validate that the hardware has upheld design specs in a more controlled environment.
Welcome to the friendlier side of internet crazy :)
Post Reply