OBD MPGuino gauge

[dcb]

He was just trying to get something working, hadn't been at it very long. you got that ISO direct circuit and code working yet?

[ishiyakazuo]

"Just trying to get something working" is probably the most common excuse for breaking existing functionality I've heard over the years.

It's all well and good if just getting something working, with no hope of improvement later, is the end goal, but my thinking is that we'd all benefit by working from a common code base, so maybe we should concentrate on fixing that before moving ahead just to "get something working," don't you think?

I'm not trying to be judgmental (it sounds like you may have taken it that way), but I think if we can change our paradigm about code reuse on this project, we'll all be happier for it. Updates made by one person will magically propagate through to everyone's units... sounds wonderful to me I'm also worried that this code base is getting/will soon be out of date with respect to the MPGuino base, meaning there'll be extra work later to merge back up if we decided to do so then.

What's done is done, but now that we have a battle plan involving even more logical branching off, it's more important than ever to keep up with each other by sharing a common base.

Don't you worry about that ISO direct circuit -- I'll make that baby purr.

[dcb]

Unfortunately the best way to get "cred" isn't through lecturing and speculating. That is probably the most popular way to kill projects. The code is limited to 14k anyhow so how bad could refactoring be?

I don't want to maintain multiple versions of the same functionality but part of the "mission" was originally to make it as simple as possible for folks to just install arduino and cut and paste the code (no libraries to sort out, etc). That means no tweaking or un commenting stuff or nothin. We have not considered anything but debug type ifdefs to this point.


I do not see an issue with getting a working model then re-evaluating how it should be deployed and maintained. But if it don't work, the rest of this is just wasted air.

[ishiyakazuo]

You're absolutely right -- getting something working is THE most important aspect of a project. But, in my opinion, a good project and a great project are separated in part by how easy it is to take it and run with it. Take a look at Arduino itself. ATMega168 by itself is a pretty lackluster platform. But add a nice standard board a hobbyist can take and run with, along with a nice library and IDE, and you've got one of the most popular platforms I've seen in recent years.

We might not even need #ifdefs if the menuing is done right. It's possible that you can just select a mode you want it to run in during its initialization (hold down a button during startup to go into some "set your interface" screen?) It was just something that could be done to get something working

I'm not trying to "get 'cred'" here. If you think I'm blowing smoke, that's perfectly fine with me -- I know what I've done, and that's enough for me. That being said, I'm also not here to belittle or berate anyone either, and I don't believe that I have any more (or more relevant) experience than any of you either, but it just seems like there is a need for a longer-term plan beyond getting the code to work.

I'm at a bit of an impasse here as far as how I should proceed to get something working. If I knew what the history of both projects were, it'd be a no-brainer: I'd merge the code before moving onwards, and then add whatever I needed to. But I'm unfamiliar with where things were when they branched off, so there's added overhead involved in researching that.

Again, what's done is done -- I need to have some feedback on where you all think we should go from here, that's all. I'm inclined to start with OBDuino's code, since I'm under the impression that it's pretty close on the ISO side of things, but then we're still going to run into the issue of merging later on. I can also take the MPGuino code and just add OBDuino's ISO-specific code and start from there, which is probably the more preferable approach.

In closing, I guess I'll just do my best to shut up now until I do my part.

[dcb]

Right now we are at over 12k of codebase, pretty close to the point where things will start flaking out. I think if we try and do elm AND iso AND injectormonitor that we will definately break.

The one thing I can think of to keep the codebase together on the reusable bits (lcd and buttons) and allow us to have ifdefs to minimize code size AND still be cut and paste, is for me to put a bit of php (or shtml or whatever) together that will basically prepend a #define to the file depending on url parameters to say (Oh, the user clicked on the elm327 version).

The other thing to consider though, is that all these ifdefs are going to make things even more incomprehendable for your beginner programmer. Maybe the php thingie needs to stitch the actual code together? Anyway, I'll be happy to solve it, whatever it is, when there is a real reason to do so (i.e. here's a second working thing that we actually need to maintain)

re: ISO hardware, keep the LCD pinout and buttons the same for now, and keep the additional hardware to an absolute minimum (couple transistors and caps, etc) and use all through-hole if possible.

[ishiyakazuo]

Originally Posted by dcb

Right now we are at over 12k of codebase, pretty close to the point where things will start flaking out. I think if we try and do elm AND iso AND injectormonitor that we will definately break.

Ah, that's an important piece of info.
Good thing AT90CAN has 32k of flash minimum...

Originally Posted by dcb

The one thing I can think of to keep the codebase together on the reusable bits (lcd and buttons) and allow us to have ifdefs to minimize code size AND still be cut and paste, is for me to put a bit of php (or shtml or whatever) together that will basically prepend a #define to the file depending on url parameters to say (Oh, the user clicked on the elm327 version).

That sounds really good as far as keeping things together.

Originally Posted by dcb

The other thing to consider though, is that all these ifdefs are going to make things even more incomprehendable for your beginner programmer. Maybe the php thingie needs to stitch the actual code together? Anyway, I'll be happy to solve it, whatever it is, when there is a real reason to do so (i.e. here's a second working thing that we actually need to maintain)

If the code is being actively modified by multiple people, stitching it together on the fly will present a problem on check-ins. I agree about #ifdefs cluttering up code, which is why I was saying that it would be nice to have a "get me this PID" function that, once it works, you just don't touch it, and the #ifdefs are strictly in that function. (The injector monitor version could emulate PIDs as well, just to keep things consistent.) Anyway, you're right, it's a solution to a currently non-existent problem.

Originally Posted by dcb

re: ISO hardware, keep the LCD pinout and buttons the same for now, and keep the additional hardware to an absolute minimum (couple transistors and caps, etc) and use all through-hole if possible.

Trust me, you don't need to tell me twice about this one RBBB is my Arduino of choice for a reason. I'm planning on building the injector monitor version and just adding the ISO connection to the UART.

[Yoshi]

Originally Posted by Magister

The atmel CAN exist only in a "thin quad flat pack" like you said and unfortunatly there is no arduino like dev board for it.

There are a lot of AT90CAN based dev board.
One of them is...
SparkFun Electronics - Development Board for AT90CAN128 - AVR-CAN

Please note that the CAN message contents are different vehicle by vehicle, and the most hard part is to hack the message contents.

Yoshi

[ishiyakazuo]

SparkFun has another (maybe even better?) board for AT90CAN128: SparkFun Electronics - Header Board for AT90CAN128
They also sell the bare board very cheaply:
SparkFun Electronics - ATMega128/103 Bare PCB

Thanks for the information on the CAN bus. I'm not fully sure we'll ever get there either, but it would be nice to try.

CANについての情報がありましたら、教えていただけますと大変助かります。
よろしくお願い申し上げます。

[dcb]

If it does eventually go that direction I'd suggest the header board for $38


and build or buy an icsp cable.

Edit, or that $3 adapter in the second link, if a 64 pin smd job doesn't deter you. The chip will be another $16 though.

[ishiyakazuo]

Not $16:
AT90CAN64-16AU
or
Digi-Key - AT90CAN64-16AU-ND (Atmel - AT90CAN64-16AU)
http://search.digikey.com/scripts/Dk...0CAN32-16AU-ND

I don't think we'd need the 128 version, honestly. 64k would be absolutely plenty, and 32k is probably doable (although I think the 64k is worth the extra dollar).