since we do seem to have a few programmers here, anyone mess with an Arduino before? it seems like it wouldn't be that difficult to learn it's language compared to a 6811.
Printable View
since we do seem to have a few programmers here, anyone mess with an Arduino before? it seems like it wouldn't be that difficult to learn it's language compared to a 6811.
I have an Arduino Uno sitting on my bench.
I'm having trouble learning the program language to get it to do what I want, I understand the basics, in that you need to set up everything in the sketch and then have loops and such running, but I just don't seem to understand how to actually write it to get it to work. :(
people don't post examples anywhere?
it seems pretty simple to me, from taking a look at the instruction set, though i have yet to view any programs. from the looks of it, i may want an Uno for controlling some things in-car that i would have otherwise needed to use an ECM as a BCM for.
and supposedly, the instruction set is based off of C? i can't understand C at all, i tried making a tunerpro plugin or even trying to understand how a plugin works and got nowhere real quick.
i can program the hell out of motorola 68xx code, but i can't seem do anything PC based at all beyond simple HTML and it's derivatives.
The Arduino is a lot of fun. I had been wanting to muck with microcontrollers for a long time, but found it a bit confusing and the easier stuff was very costly. The Arduino makes it easy to get started. The 'reference' hardware (even though it's nothing special) gets everybody on an even playing field that needs nothing additional for programming. The language is pretty easy to pick up on. I'm far from an expert but have been able to do a couple of good projects with some help from google. The best part is the abundance of information out there since it has become so popular.
I started with the usual blinking LED and hello world on an LCD stuff, and then fought my way through a couple of projects that were a little over my head. The first project was a whole house power monitor (based off this project: thttp://openenergymonitor.org/emon/node/58) that measures voltage and current usage, displays it on an LCD, and sends it to a linux box wirelessly via XBee modules. On the linux box I log the data, generate graphs of usage over time, etc.
The second bigger project was my own design to monitor the state of battery banks in RVs/Camping Trailers. There's some commercial products that do this, but they are big bucks and every one I played with had some quirks. Here's the circuitry breadboarded up for testing when I first started:
http://www.shadetree.org/electronics...r/DSC03370.jpg
Once the hardware was working I etched a PC board for it:
http://gallery.shadetree.org/main.ph...serialNumber=2
And built the prototype:
http://gallery.shadetree.org/main.ph...serialNumber=2
The software is about 75% done. Discharge tracking works, and charge tracking mostly works. I need to finish up the charge portion and the rest of the user interface. Right now it's been back burnered while I get some furniture built. When I get a chance I'll see if I can make a quick video of it working..
Another thing I thought would be a fun Arduino project would be a little box with LCD to display a mini "dash" from ALDL values.
- Frank
it does support TTL communications(either natively or via an adapter), from what i've read, which will work with ALDL.
i've considered a great many uses for it, the most exciting of which is similar, though i am leaning more toward the HUD route and have values projected onto the windshield.
True Heads Up would be cool. The TTL should be very easy to handle, as that's pretty much the native capability. To go to RS232 they use an interface, just like we do to talk to the ALDL. USB is also handled in a similar manner.
Does anyone know what the original powertrain engineer HUDs looked like? That could be an interesting thing to try to replicate.
- Frank
I agree with you on C and the TurnerPro plugin. I've never been able fathom C that well. I guess I don't agree the philosophy behind C. I've taken a look at the C source to BitHoist & that makes my head spin. Took me several hours to find where the author was parsing the command parameters.Quote:
and supposedly, the instruction set is based off of C? i can't understand C at all, i tried making a tunerpro plugin or even trying to understand how a plugin works and got nowhere real quick.
i can program the hell out of motorola 68xx code, but i can't seem do anything PC based at all beyond simple HTML and it's derivatives.
I assume you could program it in assembler if you want.
A lot of it will be how well the manufacturer documents the micro. With C, you end up having to learn how the hardware works then having to learn how to access the hardware through C. In assembler, your good to go once you learn the hardware.
Anyway, programming in C on one of these boards should be easier because you will be writing the code in your own style. From a C coding perspective, I think C is more suited for the micro processor environment. You can avoid a lot of the complexities of C. I think C falls down in the large system programming environment.
I'm familiar with one or two of the Micorchip pic controllers.
Robert
the GM instrumentation module.... that thing will never see the light of day. i can guess what some of it does based on my disassembly of A1, but from the way it's been described before, it was essentially a datalogging/real-time data viewing device, so not that much different than tunerpro RT itself.
Yeah, my main reasoning to start with the Arduino was to build a display for my dash, much like the Tuner View II, since I'm getting ZERO after sale support for the device now, got a couple bugs worked out, and then was told politely to "Go fuck myself"...
I know the Arduino can do it, it's been matched to the Honda ECMs, and Megasquirt for the same purpose, I just need to learn the language.
From what I can see, a MAX232 style circuit will be needed to interface with the serial RX and TX lines on the Arduino itself, after that, I'm almost lost. The basic principle I understand, assigning pins, and basic layout of some stuff, but I haven't dove too deep in actually writing the code, since there were some things that didn't make sense to me, and it's been a few months since I have played it with it.
I did the usual LED flash and Hello World stuff as well, I then went to adding LEDs, flashing together and alternatively, bucket brigades, with and without delays between LED on time, glowing LEDS, etc written by me, by that didn't get me even close to where I need to be.
I need to get back to working on that sketch.
that doesn't sound like Moates...
i really need to pick up an Uno and play with it, i mean worst-case scenario, i pay $30 for a board that i could resell if i can't figure it out either.
Craig Moates is not the creator of TunerView. He is a reseller. HRTuning sells the Tunerview. It looks like a nice setup. If only it were compatible or open source. But it's not. :-(
I just need to take the time to learn Arduino. And bug a friend of mine who DOES know it.
Take a peek here at the hardware reference (we'll use the Uno since it's the most current): http://arduino.cc/en/Main/ArduinoBoardUno
You can see in the docs that digital pins 0 & 1 are RX & TX out of the microcontroller. At this point it is TTL level data. On the Uno, a seperate microcontroller (ATmega8U2) is used to convert that TTL to USB. On the older boards, an FTDI chip did the TTL to USB, and on the older serial stuff, a MAX232 (or similar) was used for the same purpose.
Anyway, since you have TTL level data at 0 & 1, you should be able to go straight from those points to the ALDL with no real additional circuitry required.
If someone is familiar with the ALDL datastream and can give us a couple of pointers, a quick overview, or even a link to a doc, we could all give it a shot right here. I'm pretty sure I have a few 7730's laying around somewhere for testing. I'm not familiar with how the ALDL is handled, if there's a "handshake" or something needed, or whatever - I've always been lucky enough to be able to use existing software to get the info. The needed data might be right here on the board, or even available in a tunerpro ADS. I've never looked, but will do so.
I have an Uno for the rare occasion I want to mess around with one of the sheilds. Most of the time when I'm prototyping my own junk I use either a Bare Bones Board or a Really Bare Bones Board from Modern Device (http://shop.moderndevice.com/collect...ino-freeduino/). I like that they plug directly into a breadboard vs. having to flywire it. Either way the software is the same.
- Frank
I haven't looked too deeply, but I suspect that the info is in the TunerPro ADS files. That file would also tell you if you needed to send any commands to the ECM (handshaking) to start the output. But I can't see that as being too difficult. <shrug>
They also have an Arduino bluetooth module. What would really be awesome is an interface that would output the data right to your smartphone or iPod Touch. Then you'd need Apple's SDK to write a program that would allow you to display the info in whatever manner you wanted. Sort of like a TunerPro dashboard right on your phone. But I digress...
EDIT: The bluetooth module is no longer available.
ALDL is just 8192 baud, 8N1 format, the sending procedure is:
1. send a message to a module
in this message are a couple of different things, 1st being the module that is being addressed. 2nd is the length of the message. 3rd (since we're dealing with polling for ALDL data) is the specific mode message we want sent back(a mode 1 message). depending on the mask, this can be 1 byte or 2, depending on how many messages there are in the mode 1 message system. assume it's a simpler unit and it's only 1 byte. 4th byte sent is a 2's compliment checksum of the entire message.
2. the PCM will now dump the requested stream (most do ~63 bytes of data), and then a 2's compliment checksum of all of the information it sent.
the first byte the PCM sends back is the module identifier, followed by message length, followed by the mode requested, followed by the data, followed by a 2's compliment checksum.
simple enough explanation?
Thanks Robert, that is perfect! I actually just opened the $A1 ADX to see you wrote it :)
So (using $A1), if I am understanding correctly, I would:
- Send the hex string F4 57 01 00 B4
- Receive 63 bytes of data to be processed/displayed
- Take a short break
- Do this over and over again
And as far as processing the data, I would find the TPS value as the 9th byte of the response.
Is that correct? If so I guess I'm going to go crawl around the attic and see if I can find a 7730.
- Frank
you'll actually receive 67 bytes of data back from the PCM, 3 for the header, 1 for checksum, the other 63 for actual values.
no break needed, you can immediately retransmit after the received checksum is finished. i get ~10.67 samples averaged per second on TP.
and yes, TPS A/D is the 9th "value" byte that will come back. the 10th is TPS %.
if you get this pounded out, i'll have to send you the info on mode 4 stuff.... i'm sure that would be quite a hit as well.
Good deal. This doesn't sound too difficult to pull off. Time to go dig up an ECM and start playing around.
Damn. Now I'm going to have to buy an Arduino and a bunch of dot matrix displays.
I wonder if you can drive Nixie tubes with an Arduino?
they can natively drive ~40mA.... i imagine a good FET or two could drive that up though.
You guys playing with this Arduino thing and the other day when I was searching for PWM controller for jim_in_dorris I found one for it!
i always have uses for a good MCU, whether it's to control my refrigerator the way i want it to run, or if i want to build up my own retained power circuit for the car to power the radio/power windows/etc for 5 minutes after the ignition is off or some other crazy project.
i can do all of these things with a motorola 6811(GM OBD1 P4 ECM), but they aren't exactly easy to come by these days for as cheap a price and as versatile for off the wall applications.
Just a few notes for thought...
"ALDL is just 8192..."
Some calibrations play very nicely with this rule. Some do not. $58, for example, is notorious for not working with ALDL displays or software which works fine on $8D. Of course even $8D doesn't work like $8D if it's installed in a Corvette. And there are the Olds / Buick / Caddy systems where "somebody else" wants to be in charge.
"Has anyone seen the GM Display...?"
Rumor has it, or had it, that Doc Plecan (Grumpy from thirdgen) had one for a while. While "I never saw it," it might have been about as wide as a small computer desk, about 8-10" deep, and maybe that much tall. It might have had controls to allow one to change specific values in memory or to simulate sensor data to work through bugs and it might have had various points to connect additional instrumentation. If painted it would have been gray, and it might have looked like images of NASA equipment in the 1960s. It definitely wouldn't have appeared to be the powerful tuning device that it was. Lockers is a hobbyist level version of the GM HUD.
"i can't understand C at all" "In assembler, your good to go once you learn the hardware. "
C is a high level language. You say "Go get this done" without worrying about how it gets done in the hardware. After writing your program it's the job of the compiler to work out the details for the processor. With proper compilers, an EFI control algorithm written in C would work in a 68HC09/11 system, and 68000 system, an Intel based system, or even in a PC based system. The programmer should only need to know how the control algo works, not the details of implementation. In assembly you are making the decisions about how the code operates, what data structures to use, how to use memory in a way you want. In C it's the job of the compiler to translate your instructions to machine code. There are plenty of arguments for and against higher level languages over assembly language for microprocessors but each has it's strength and either can be the best choice in a given situation.
edit: Didn't have time to say this originally. Seeing this conversation here is impressive and rewarding. I'm willing to help if needed with coaching on C or C++ related stuff. Four years chasing CS/EE major gave me a fair amount of practice coding in these languages and if I can give back I'm more than happy to. This is not an offer to do all code writing (boss is in the hospital and I'm spending 80-85 hrs/week at work covering his job and mine) but definitely an offer to help with WT??!!! questions.
i was thinking about it...
J1850 VPW: an Arduino can probably be used as a VPW to USB interface, couldn't it? and with the amount of RAM available, i'm thinking it could be the basis for an OBD2 flashing cable without any issues. no idea about CAN stuff, but VPW should be covered.
i need to research this some more, but it looks like it's possible to use it as such.
Here is an implementation by Luke Skaff, "Automotive Diagnostic Interface."
http://lukeskaff.com/wordpress/wp-co..._Interface.pdf
There is a complication with ALDL. The ALDL is bi-directional on one pin. With separate input & output pins, you need to merge this data onto one wire. Luke show a circuit for doing this.
Robert
SLIGHTLY inaccurate at times, since mode 2 actually dumps 64 bytes per message, IIRC.
mode 4 being deactivated is also false.
ECM reading only up to 6375RPM? also false, i've had nAst1 code run up to 12,750RPM on a bench and nothing bad happened.
otherwise, a good project.
That was some really good info from the date though!
I actually built the 2 Square wave signal generator to hook up to my still needing to be built test bench. It does work nicely.
After looking over some of this thing, I may have to order one and start playing with it. It would probably work great for some of the things I am wanting to implement.
Well, I haven't spent any time thinking about this, but would this work to base a ECM test bench around? It should would be a quick way to get into a test bench.
It could possibly be used for a test bench, but I would use the Megasquirt Jim Stim for a test bench, instead of the Arduino.
Here's a thread we had awhile ago on EFI test benchs.
http://www.gearhead-efi.com/Fuel-Inj...ECM-Test-Bench
Reviving a (semi) old thread. :D
I got my Arduino Uno today and was playing with it. I have a very limited understanding of the code. I can modify the Blink code and played with IF and ELSE statements.
Can someone point me to some good tutorials on reading serial data? The only serial read functions I see just return the first byte of data. The 16197427 ECM requires handshaking IIRC and outputs a stream of data and then waits for another prompt before outputting data again. At least that's how I understand it.
I guess I need a way to read the entire string (store it in memory, perhaps?) and then pull out the various data as I need it.
Some of what you are looking for may be found on page 22 here: http://lukeskaff.com/wordpress/wp-co..._Interface.pdf
Commands for accessesing data in $0D are from ALDL.ds file A217.
Code:MODE 1 (TRANSMIT FIXED DATA STREAM)
ALDL REQUEST:
- MESSAGE ID = $F4
- MESSAGE LENGTH = $57
- MODE = $01
- MESSAGE = $00
- SUM CHECK
THE PCM WILL RESPOND WITH THE FOLLOWING MESSAGE:
- MESSAGE ID = $F4
- MESSAGE LENGTH = $95
- MODE = $01
- DATA BYTE 1
.
.
- DATA BYTE 63
- SUM CHECK
Yep, I'm currently cleaning off my computer desk in hopes of getting back to this.
and i'm still brainstorming on what all i can monitor/command with one as a BCM. recent additions include those interesting electrically controlled struts seen on some of the higher end GM cars from the early 90s and onwards.... the current struts in the 91GP are adjustable manually, but on max setting, they will shatter hips if you're not expecting a road transition. i'd like to just press a button and go from a fairly soft touring mode to track ready.
now i just need to figure out how to get them to work with the W platform. :laugh:
Yeah, I also thought of a couple simple, but possibly cool things I could do with the Arduino and some of the existing circuits in my car...
I'm going to get serious about this display, since I REALLY want something that will display more than what I currently have on my TVII.
Well, I'm back to working with, or on, or maybe against(?) the Arduino...
I have decided that the ALDL Display is a bit above me right now, so I'm attempting a "simpler" project, a simple display to mount on/in my dahs or on top of my steering column that will take direct inputs and display something on an LCD display.
Since I replaced my OEM tach with an aftermarket I lost my turn signal indicators, though I have LEDs in a small ABS panel attached to the top of my steering column, it just lacks the finsihed look I want, even using triangular LEDs wouldn't satisfy me. I also don't have an OEM CEL, so I thought what better way to figure out this programming than to have something that will display turn signal indication and "CHECK ENGINE" right on an LCD?
So far I have it displaying the 3 functions from 3 separate inputs. The only issue is that the else statement to clear LCD affects all but the last item in the loop. I need to figure out a different way to reset the LCD, or maybe use switch statements, which I'm about to attempt.
Eventually I want it to display multiple things on the screen, maybe not only the CEL, but which code is set...
I also need more switches/buttons to make testing easy LOL, I have one one button, that I scavenged this morning, I'm sure I can find more if I look hard enough.
Here's an idea for an end goal, pretty sweet unit but in the $1200 range...
http://www.autometer.com/dataloggers.aspx