Show Posts
Pages: [1] 2 3
1  Using Arduino / Displays / Re: DUE + u8glib + ssd1325 (NHD 12864 OLED) = slow refresh rate :( on: April 06, 2014, 09:10:54 am
i have got it working, i haven't tried the analog changes yet, but i am satisfied with the results so far, it is very fast now.

Trick was to leave the first two pins SCK and MOSI  undefined, so
U8GLIB_NHD270LED_2X_GR u8g(pin, pin);

at first i tried to use pin 4 as CS, as it is one of the HW SPI pins, that didn't work very well so I changed it to 10, and BAM!, thng works awesome.

so right now i have it set as:
U8GLIB_NHD270LED_2X_GR u8g(10,9). SCK and MOSI pins are 3,4 of the ICSP header respectively
and its working great.

Thanks for all your help and your detailed responses, means a lot to a newb like me.

I'll play with the analog read code more tomorrow, but right now i have to call it a night.

thanks again!
2  Using Arduino / Displays / Re: DUE + u8glib + ssd1325 (NHD 12864 OLED) = slow refresh rate :( on: April 06, 2014, 08:34:38 am
got the hardware spi working, didn't make much difference.

i must have something terribly wrong, it takes almost a second to render a new digit (i would say ~700-750ms)
3  Using Arduino / Displays / Re: DUE + u8glib + ssd1325 (NHD 12864 OLED) = slow refresh rate :( on: April 06, 2014, 07:51:27 am

  "Hello World!" example code.
  >>> Before compiling: Please remove comment from the constructor of the
  >>> connected graphics display (see below).
  Universal 8bit Graphics Library,
  Copyright (c) 2012,
  All rights reserved.

  Redistribution and use in source and binary forms, with or without modification,
  are permitted provided that the following conditions are met:

  * Redistributions of source code must retain the above copyright notice, this list
    of conditions and the following disclaimer.
  * Redistributions in binary form must reproduce the above copyright notice, this
    list of conditions and the following disclaimer in the documentation and/or other
    materials provided with the distribution.


#include "U8glib.h"

U8GLIB_NHD27OLED_GR u8g(3, 4, 5, 6);   // SPI Com: SCK = 13, MOSI = 11, CS = 10, A0 = 9
//U8GLIB_NHD27OLED_2X_GR u8g(13, 11, 10, 9);   // SPI Com: SCK = 13, MOSI = 11, CS = 10 , A0 = 6

int sensorValue = 0;

void drawanalog(){
  sensorValue = analogRead(A0);
  u8g.setPrintPos(80, 62);
void setup(void) {
  // flip screen, if required
  // u8g.setRot180();
  // set SPI backup if required
  if ( u8g.getMode() == U8G_MODE_GRAY2BIT ) {

void loop(void) {
  // picture loop
  do {
  } while( u8g.nextPage() );
  // rebuild the picture after some delay

Here is the quick and dirty code i hacked together, even with the 50ms delay it is not usable.

going to try and get it working on the hardware spi..
4  Using Arduino / Displays / Re: DUE + u8glib + ssd1325 (NHD 12864 OLED) = slow refresh rate :( on: April 06, 2014, 07:17:31 am
ill do that as soon as i can, im posting this from my iphone, so makes posing code impossible.

I also saw another possible solution further down in the displays section i want to try.

I am curious about the due hardware spi implementation, i must have missed that one in the long list.
I am using the NHD2712864GR constuctor (sorry if thats not exactly the way the constuctor is listed, im on my phone )
5  Using Arduino / Displays / DUE + u8glib + ssd1325 (NHD 12864 OLED) = slow refresh rate :( ---FIXED!--- on: April 06, 2014, 02:46:56 am
I recently received a 2.7 inch 128x64 OLED from new haven, it uses the SSD1325 controller and is supported by the u8glib library.

This is a 3.3v  display, so most of my arduinos wouldn't work with it without the help of a level shifter. I have a DUE on hand that has been woefully neglected for some moths, so i thought it would be a great opportunity to use it.

Long story short, getting the display up and running was quite painless,  the u8glib defines SPI pins that are hardware on most arduino boards, however the DUE has them on a separate dedicated header. This turned out not to be an issue (or so i thought) as i just used the default pins and it worked, ran a few demo sketches and thought everything was fine,  until.....

I tried to write code to see how fast the OLED would update, basically i did an analog read and print routine, thats when i noticed how painfully slow the update was, to the point that digits got garbled and looked terrible.  

How could this be? the DUE is a fast and powerful beast, why does it seem to choke on a lowly 128x64 OLED?

I am pretty sure it has something to do with not using the hardware SPI, the library is obviously implementing a software spi and i am sure that slows it down a bunch, but is that the only issue?

Does anyone know a way to implement the hardware pins with the u8glib library?

does anyone know if the SPI hardware pins can be declared  in the IDE ?( i found no reference to what pin numbers they might be)

is there a better library out there? or possibly one that could be substituted?

has anyone ever tried using one of these displays (or a similar type) in parallel mode (6800 or 8080  interface)?

I would love to use this display as it is well suited for my application, but at its current performance level its pretty useless.

6  Using Arduino / Project Guidance / Re: arduino based fully DIY fuel injection ECU. on: February 04, 2014, 12:01:48 am

or, while it still has the cursed megasquirt associated with it, you could look here and start with code that reportedly already works
7  Using Arduino / Project Guidance / Re: arduino based fully DIY fuel injection ECU. on: February 03, 2014, 11:38:44 pm
wow, this thread is getting ugly. Settra, i think you would do a lot better to tone it down a bit,  PeterH is in fact trying to help, and, although there have been some missunderstandings, your constant acusations and over all shrill tone makes it difficult for anyone, including myself, to attemp to help.

PeterH has said nothing concerning fuel injection systems that i can dissagree with, Yet you insist on insulting him any time he says something you might dissagree with, most of your theories are somewhat on the right path, however you dont always explain them clearly, and attacking others who are trying to help due to missunderstandings or dissagrements on details is simply juvenile and rude.

I am a relative amature at programming, i will say that outright, but i have programmed quite a few arduino based projects with fairly good succsess, an engine controller would be an awesome project, but i am under no illution that it will be easy. the code required, if running on an atmega328 will need to be quite efficient, even if it is spread across several chips, there are a lot of calculations that need to be made in order to obtain the accuracy required to ensure the propper ignition timing and required fuel pulse. i am sure you are aware of this.

while i may be a novice at arduino programming, i am quite knowedgable about fuel injection systems, and tuning them. I have worked on cars for over 20 years, and spent close to 10 building, installing and tuning fuel injection systems on all different kinds of cars and engines. I now work as an electronics technition and do various R&D work on all manner of industial equiptment and computing systems. So, i think i have a lot to bring to the table when it comes to the project you are planning, but when you attack someone for saying things that i agree with i get my feathers ruffled a bit.

Everything Peter said about the timing of the fuel injection pulse is correct, in my opinion, the ideal timing for an injection pulse will be such that the end of said pulse will coenside with the closing of the intake valve, of course you already knew that im sure. or you know that i am wrong either way i am sure you will not hesitate to say so.

As i said, you seem to have a grasp on what is needed, but it seems you are also making a lot of assumptions at the same time.

since sivillity has long since been thrown to the wind, i willl echo Peters sugestion that you take a look at the megasquirt, you can purchase a MS1 kit for around $150, or buy only the stuff you need and for a bare bones board and probably get it even cheeper yet.
while i know you have a pretty strong aversion to it, think about the benifits. you would be starting from the board up, figure out how to interface with your various sensors and get usable output and data from it. Then, if you wanted, pull the motorolla chip out of the board and wire the atmega(s) to the board now you have a tried and true hardware interface with injector drivers, ignition drivers (if you want)  analog input circuits etc.  and, i think, after doing all of this (and reading the massive ammount of documentation) you will have a much better grasp on what will be required of the arduino.

you will have to put some time and money into a board of some sort anyway, injector drivers etc.

Somehow i doubt you will, as you seem more interested in being right than being productive, but i could be wrong.

So now that i have put myself squarley on your s4!t list along side Peter, i wish you luck, i am still interested in your project, and i still hope you find succsess, and, if asked i will still provide input, however i do not enjoy being asked a question and then having to defend my answer, so please keep that in mind.

best of luck 
8  Using Arduino / Project Guidance / Re: arduino based fully DIY fuel injection ECU. on: February 03, 2014, 01:34:16 pm
Settra, sorry, i missed the post where you described your cam trigger wheel, to that end, yes that type of wheel i think would be just fine.

now, if i can manage to continue without further ruffling your feathers....... smiley-confuse

As for the .4ms interrupt timing clashing with a .1ms analog read, that does sound to me like it could cause an issue, mainly because i think you will want to read many more than just 1 analog signal.

I am just starting to learn about ATMega interrupt routines, would it be possible to simply use the majority of these pulses (interupts) to flag clock counts? and will doing this interfere with things like analog read and digital write (or better yet direct port control)?

If these interrupts will cause issues then i think maybe it would be better to use fewer of them, for instance 1 per cyl?

I am toying with the idea of trying to build a "mock up" engine, a motor with a trigger wheel, to test different code schemes.
if only i had more time.....
9  Using Arduino / Project Guidance / Re: arduino based fully DIY fuel injection ECU. on: February 03, 2014, 07:32:55 am
if you have cam position sensor, and you know any given point (etc, at TDC of cylinder 1 , there is a teeth missing) , then by counting teeth, you can know exactly where are you are , at any point of the cycle, without any need for the crank position.
so, all is left for crank sensor is diagnostics, and the "Return me home" mode. (if cam sensor brakes ).

I wish i knew what kind of car you were working on, as it seems to be quite different from any that i have ever worked on.

what you say is true, a cam sensor will indicate what stroke the engine is on, but at what resolution? how many "teeth" or timing references does your cam sensor have?

As far as i know, and i have spent the vast majority of my professional carrier working on cars, engines that  have both a crank, and a cam sensor, the camshaft sensor usually has 1 pulse per 720 degrees of engine rotation, not exactly enough info for the ECM to make accurate timing calculations. Some are different though so who knows?

Loads of engines use a crank sensor only, because in the big scheme of  things, it does not matter if the ECM knows what stroke the cylinder is actually on. Waisted spark ignition and batch fire fuel injection have been around for years and work just fine, and the ECM controlling these never has a clue what stroke a particular cylinder is on, this is not a "limp home mode", but rather a perfectly viable way to controll an engine.

I am telling you this, because you seem to be assuming that because your car has a cam sensor it will provide your would be arduino engine controller with all the info it needs, and i am guessing that it will not. if you insist on using only one of them, i think you would be better off with the crank, as i would be willing to bet that it has more "teeth" or pulses per revolution.

You said my car only has ignition module. so ,  i want a fully functioning, as far as injection goes.
So it it a carberated  car? i was under the impression that it had a fuel injection system as well.....
to say your car has an ignition module is like saying that it has 4 wheels, most all cars have ignition modules, like most all cars have 4 wheels, i'm not sure how this fact relates to your plans for an engine controller, outside of how to interface with it, witch is generally a simple digital signal.

The ignition module on most cars has one main function, to fire the ignition coil(s), this keeps all the high voltage noise seperated from the ECU, in some instances, the ignition module also serves as a crank and or camshaft sensor interface and can provide a base timing referance and spark during cranking.

I am not trying to be rude, but the more you post on the subject, the more apparent it is that you may not fully understand how ECMs and fuel injection systems work. I realize that there is also a language issue here, and i may not understand what it is you are actually saying.  So to remedy this, lets start with some basics, what kind of car is it? how many cylinders? Crank sensor, what kind ( VR, or hall effect) and how many teeth? how many missing teeth? same for the cam sensor, what kind and how many teeth?

First thing to do is to get the arduino to figure out what rpm the engine is turning and how to calculate the timing of events based on these signals.

10  Using Arduino / Project Guidance / Re: arduino based fully DIY fuel injection ECU. on: February 02, 2014, 12:58:47 pm
I your goal is to be able to tune your car correct?

or do you want to build a fully functioning system to replace the existing one?

As i stated before, i think a uno would have enough I/O pins to do the job, though just enough. I would avoid  muxing the analog inputs because some of them, like TPS , MAP/MAF, EGO are time sensitive.

If your car uses both a crank and a cam sensor, it is not simply "for diagnostics"  I am not sure where you are getting your info, but generally the crankshaft position sensor is used for the timing input of the crankshaft, and is the main reference input  to the ECM. the camshaft sensor is used to tell the ecu  whether the cylinder is on a compression stroke or exhaust stroke.

in any case, if your goal is simply to be able to tune your car, you might consider an alternate method. using an arduino to alter the main load signal, and possibly the timing reference as well. this would give you the ability to tune fairly easy compared to building a complete system, and would be far easier to implement.
11  Using Arduino / Project Guidance / Re: arduino based fully DIY fuel injection ECU. on: February 02, 2014, 02:47:29 am
f i go and buy the dollarsquirt, then what exactly is the DIY?

You get to build up the PCB, even order most of the components to populate the PCB if you want, decide what version of the system you want, put it in a box, wire it into your existing EFI system,  then start the glorious process of setting it up for your engine and then tuning it. That's a fair amount of DIY, trust me, i have done it a few times.
You could also design and build your own PCB if you simply had to, even modify the schematics if your adventurous.

read MAF or map sensor (havent figured out)  in order to establish an engine load.

        then, using a wideband sensor, and with a tuning session, you can have the "perfect" amount of fuel, needed for each MAF/MAP on a   MAF-injection time   table...

I think this question, and subsequent statement, have a lot to do with why other members are thinking that you may not understand the complexity of the task you are undertaking. Simply put, and with all due respect, it appears that you do not know what you do not know, so to speak.
but, to move the ball forward....

MAF  stands for Mass Air Flow. It is generically used to describe a sensor that measures the mass of air being pulled into the engine.
Most modern MAF sensors employ a "heated wire" technique, a current is passed through a wire (usually platinum) to heat it to a specific temperature, the current required to maintain that temp increases as the airflow through it cools the wire. that current is usually converted into a 0-5 volt signal. If you know the Mass vs Vout then calculating  fuel injector pulse width is fairly straight for ward, assuming you know the flow rate of the injector.

MAP stands for Manifold Absolute Pressure, and is generally a 3 wire sensor that measures the pressure inside the intake manifold, ideally relative to the atmospheric pressure. Using this type of sensor is called speed density, because it requires the ECU to calculate the Mass of the air going into the engine based on the engines speed (rpm) and the density of the air it is injecting (manifold pressure). All engines are not the same, but MAP sensor signals from a 600cc 4 cyl and a 8000cc V12 could be identical.
So the ECU needs to know how big the injectors are (flow rate), how big the engine is, Volumetric efficiency at different rpms as well ad desired air fuel ratio among other things. Generally though, there is an x-y look up table, RPM vs MAP, that the ecu uses to calculate required duty cycle.

As for a WBO2 being used to determine the "perfect" amount of fuel, this is possible, in theory but generally not in practice.
The O2 sensor is reactionary, its signal only indicates whether or not previous fuel calculations were high or low. The ECU can use this to adjust upcoming fuel calculations, but it is a moving target, so to get  an exact error compensation is a rather  tall order. Yes, it can be done but would require a lot of computing power as well as knowing little things like, for instance, how long it takes the exhaust gas from each cylinder to reach the O2 sensor at different RPMs, the response time of the O2 sensor etc. It is much easier to simply make small adjustments over time. The constants, the numbers programmed into the ECU, are used to try and get as close as possible to the "perfect" fuel delivery, the O2 sensor is used for fine tuning those numbers.

Here is what i would consider a minimalistic blue print for an ECU main processor:

Crank sensor input (RPM)          1 digital I/O // preferably on a hardware interrupt pin
Camshaft sensor input               1 digital I/O // same as above, however either one of these could be used alone, or both paired
Fuel injector(s)                    1 to 2 digital I/O // 2 should be considered minimum, but up to 16 would be ideal
ignition coil(s)                     1 to 2 digital I/O // again, 2 would be a good minimum, however 4-8 would be ideal
Fuel pump                                   1 digital I/O
Idle control                                 2 digital I/O // 1 minimum (PWM motor) but 2 recommended ( stepper motor )
Cooling fan                                  1 digital I/O // completely optional but recomended
coolant temperature                  1 analog
air temp                                       1 analog
throttle position                         1 analog
MAF/MAP                                    1 analog // some sensors are digital though, but not many
system voltage                           1 analog // for measuring voltage available to injectors and coils, NOT optional
O2                                                1 analog
BARO                                           1 analog // measuring barometric pressure, optional   

So by my reckoning, for a bare bones system, a uno could do it, but a pro mini might be a better choice as it would allow a baro sensor and one extra analog. if you had to you could multiplex the coolant, air temp and baro, but i wouldn't want to do that on any of the others.

However, I think it would be much smarter to start with a MEGA board, or better yet a DUE or even a Tensy3.1.
The Mega has pins to spare, but the DUE and teensy3.x offer more pins and more speed and computing power, the extra speed might well compensate for less than ideal coding.

I highly recommend ( as much as it will hurt ) that you find the online manual for the " DIY EFI system that shall NOT be named "
and study it, its very comprehensive, free, and to my knowledge the best resource for learning and understanding what is required to control an engine with an embedded computer.
12  Using Arduino / Project Guidance / Re: arduino based fully DIY fuel injection ECU. on: February 01, 2014, 08:15:36 pm
based on what you sed before, i doubt you have any experiance with the actuall build of the ecu electronics. Configuring an efi, with megasquirt, has nothing to do , with actually BUILDING a megasquirt.

I'm not sure i understand what it is you are saying here, the " DIY EFI system that shall NOT be named " (as it appears to irritate you)  can be built  and configured for a mostly diy experience. You can get ( or even build your own ) PCB, order the parts , and build the hardware, and even buy a blank chip to program. So the only part of this experience that would not be truly "diy" would be the code loaded onto the micro controller and the GUI used for interfacing with it.
So, to that end, if it is the code you are interested in developing, and if i understand you correctly, you want this code to be specific to your car, then I whole heartedly support your effort and i hope you are able to get it working, as i too would love to see an arduino based efi system developed.

As for the atmega 328 not having the resources required, i'm not sure i agree. the motorolla micro used on the  origional (and still available i think )   " DIY EFI system that shall NOT be named "  ( the MC68HC908GP32 ) has been around for a while, and i don't think it would be considered a powerhouse chip, lets compare a few specs:

Micro controller                   Speed         Program Memory           EEProm              RAM           I/O             A/D
MC68HC908GP32                  8MHz         32K (32x8)                       none               512x8           33              8 (8bit)
ATMega 328 (32TQFP)       20MHz          32K (16Kx16)                    1K x 8             2K x8            23              8 (10 bit)

So, looking at nothing else but the banner specs, it would appear that the only thing the MC68 has to offer over the ATmega is total number of I/O, however one only had to look at the ATMega1280 to get all the I/O pins you would need for a basic fuel injection system, though i think it could be done even with a 328. The original  " DIY EFI system that shall NOT be named " did not use all of the available I/O pins anyway.

I like your idea of multiple arduino boards too, there are many things related to controlling an engine that are not particularly time sensitive and would probably be easier to control with separate boards, rather than trying to write code that does everything all on one chip.
i personally have nothing against the   " DIY EFI system that shall NOT be named ", I was one of the first guys to build one way, way back in the day when it was much more diy, and it only controlled fuel and had a very crude fast idle. These days you can buy a kit, and dont have to spend an hour or two putting together a digikey order, or just buy on assembled. 

If i were to start trying to build an arduino based efi controller, i dont think i would use the 328, i would start with something like the DUE or perhaps a teensy 3.1, start with way more overhead than needed.
13  Using Arduino / Project Guidance / reading multiple frequencies effectively? on: January 24, 2014, 02:04:21 am
I don't have any code for this yet, witch is why i am posting here smiley-razz

I want to know what the best, or at least a good way to read 2 separate frequencies with an arduino, fairly accurately, without slowing down or otherwise mucking up already running code.

the Pulsein() command would seem to be the simplest way, however this seems to stop or slow down the loop while it waits for an event. So i imagine two of these would compound the problem. 

The project i am working on uses a mega, I am trying to build a transmission controller/diagnostic tool, and need to monitor both the input shaft speed as well as the output shaft speed. Other functions that the mega are tasked with are controlling a Graphical LCD ( GLCD ) for user interface, monitoring a few buttons ( for shifting via solenoid control ), turning  shift solenoids on or off to select different gear ranges and measuring current going to those shift coils for fault detection. 

Right now I have the GLCD up and running, using a couple of ports, the solinoid shifting is also accomplished with yet another port (there are 8 solenoids on the transmission i am targeting so it works out great to use direct port control  smiley-wink )

All of these functions i have working great and were fairly easy to code using a couple of standard libraries, but measuring the two frequency signals is where i think things might start to get messy and cause long nights of hair pulling, so i was hoping some of the wizards out there could point me in the right direction.

Another option I am considering, to keep the coding simple and the overall speed on the finished product snappy, is to use multiple arduinos. Use the mega for all the a fore mentioned stuff that requires lots of pins, and use 2 pro-micros ( just cause they are cheep ), one for each frequency input. Each micro would then only have the task of measuring the frequency on 1 pin, using an efficient library like FrequCounter, and then sending data out serially to the mega when it requested. This seems like using a sledge hammer to drive a finishing nail, but i think it would work without a whole lot of coding trail and error.

I should also add that the frequencies i am trying to measure are not terribly fast, 1 to ~2000Hz (min/max), so clock counts will be fairly large, witch is why i am worried about the code getting bogged down.
14  Using Arduino / Project Guidance / tone() question, I need more than 1.. on: December 31, 2013, 12:03:42 am
Hi to all, I have tried searching this several ways on google and this forum so i am pretty sure that i know the answers, but i want to ask a couple questions anyway given all the new hardware available.

I want to build a gearbox simulator (and later a controller) that will simulate both an input shaft speed sensor and an output shaft  speed sensor.
Both these signals will be a frequency, with the output shaft speed being a derivative of the input shaft speed depending on what gear the transmission is in.

So, for the simulator, it is fairly easy to use and analog read of a pot and "map" a tone out to simulate a signal. The transmission i am simulating will have a ~400 to 1500hz signal coming from the input shaft speed sensor, so nothing terribly fast. The output shaft speed will be quite a bit lower, how much lower depends on the particular gear reduction.

edit, just found this
and this

ill try these in the morning and see if they might work

So, the question.
Is there any arduino or comparable  board ( Due or teensyX.XX for example ) or library that will allow simultaneous tones?

And on the control side of things, is there a board or library that would be preferred for measuring two different frequency inputs at the same time.

If the tone() function remains just one pin one tone its not the end of the world, i will just use 2 arduino boards to gather the info and relay it through serial communication.
15  Using Arduino / Motors, Mechanics, and Power / Accell stepper lib issue, and advice needed.. on: December 12, 2013, 12:16:32 am
Hello, I am trying to get some stepper motors to do what i want, and they are not cooperating.

A brief description of the application :  I have two arduino boards (pro mini's) and 2 easy stepper motor drivers. One arduino is used for user interface, it controls an LCD and and reads user input from either a keypad, or an IR receiver. It also receives serial data from a weight scale. Based on the data it receives from these inputs it sends serial data to the second arduino board. The second board is tasked with controlling 2 stepper motors through the 2 easy driver boards. One stepper motor is driving an auger at the base of a funnel, the second motor drives a wheel that much more precisely dispenses the media.
When a desired weight is entered, and the "go" button is pressed, the auger spins at a fast rate to dispense  the bulk of the required media, as the dispensed charge approaches the desired charge, the auger will slow down to avoid over shooting.
Once the dispensed charge is within ~5% of  desired, the auger shuts down and the second motor takes care of the remaining deficit.
The secondary motor is working great, but I'm having trouble with the auger side.
I have this working fairly well using simple speed control , The first arduino sends a serial character that is then used by the second to set the "setSpeed" of the auger motor.

Where i am having an issue is at the end of the auger motors cycle, once it has gone through 3 decreasing speeds, i want it to make 1 or 2 revolutions in the opposite direction to clear any media from the end of the auger.

As i am using the simple "setSpeed" followed by the "runSpeed" command, counting steps doesn't really work.
So what i was trying to do was, when the proper serial data came in, stop the motor, use the "setCurrentPosition" command to set the current position to "0", then use the "runToNewPosition" command to reverse the direction for xxx stepps.

I can't seem to get it to work, first problem was the compiler would not recognize the "setCurrentPosition" command. I looked in the keywords file and found that it was misspelled(it was steCurrentPosition), i changed that but it still wont work quite right.

any thoughts? should i approach this a different way?

Pages: [1] 2 3