Arduino stuff/ programing/so cheap

[flyingbrick]

You are a god damn genius

[NickJ]

31 minutes ago, Roman said:

Woops have been lazy. 

But did a bit more on this today. Had some garbage  values coming through so thought I'd better have a single place to check them all:



Found a few problems in the code or arrangement of canbus frames and now most things are working.

So now I can try make some more useful screens and know the values are as expected.

Still need to get all of the pots working but my soldering sucks on things that small and fiddly. Bah.

But you can see when each of the values updates and the refresh rate is reasonable, that's with canbus running at 500kbps, can go up to 1000kbps so might try that too. But it might not be the canbus itself that is the bottleneck to values refreshing. My code can definitely be optimized a bit by putting more of the tasks into the "if" structures I have in place but for starters its been good to just group all of the commands together and run them all through each loop, just for sake of easy troubleshooting. (Like when you copy pasted a piece of code 20 times and forgot the ; each time)

Really liking this little project, so rad what can be done

[Roman]

For version 2.0 I will switch the pots for rotary encoders and then have some arrays that work as load vs rpm tables in the arduino. 

So when I turn the dial it only affects the rpm/load area that you are currently in, rather than changes across everything.

And once I have my cam angle / inj timing / goal AFR sorted I think I will try an automated ignition trim method that floats the timing by a few degrees either way and see what gives the best economy value. And then hone in by a smaller margin for a few iterations. 

I think this might help cover situations like where air temp etc vary away from the conditions in which you initially optimized the ignition timing. 

So might be a good way to either setup a 4d ignition table orrrr just leave it running all of the time when the car is in cruise conditions. Maybe when cruise control is turned on. 

It's pretty sweet to be able to add some experimental functions to the ECU this way! 

[NickJ]

//Lame double post
 

[Roman]

I just found a cool piece of code for optimising how long your loop takes. 
 

unsigned long start_time = 0;
unsigned long end_time = 0;

void loop() 
{
  start_time = micros();
 (code goes here in the middle)
  end_time = micros();
  Serial.println(end_time - start_time);
  }

So whatever is inbetween start_time and end_time it will tell you how many microseconds it runs for.

Currently my loop when not going through any of the IF commands because canbus isnt connected. 
Takes 13,000 microseconds so full loop run time is about 75hz.

So there's no point trying to log anything at 200hz or send canbus commands at 200hz. Good to know!

Will be interesting to see how/if that drops when the code is tidied up.

Also you could partition this out to smaller segments of code to see how long each of them take.

After all, what use is an economy based tool that doesnt have economical code

EDIT: With some liberal application of IF commands, got it running at over 150hz now. woot

[Ned]

looking good roman!

[IvyMike]

This is just a thought for anyone looking to do something similar to this. The mks baseboard used on a lot of 3D printers uses an atmega2560. If you get yourself an arduino mega and one of the 3.5" touch screens off aliexpress, you should be able to refactor the marlin firmware or at least adopt the required driver for your own interests. Might save you some hassle.

[flyingbrick]

I used similar code for testing screen response time etc. Damn handy you are picking this up stupid fast David!

[h4nd]

Nice nice.

also, if you really are running out of processor power:

Arduino Due. 32bit processor, (not 8 bit)  running at 84MHz , (not 16). Mind, it's 3V, not 5V, but basically the same footprint as the Mega2560.

[Roman]

Oh snap! 

That sounds awesome. As I'd been considering making next project on a Rasberry Pi instead. 

But that sounds ideal as I can use my existing shields. I thought the Arduino Mega was the big boss.

[Roman]

Ahhhh maybe I wouldnt be able to run my shields with only 3.3v though. pooz. 

[Roman]

Aahhhh its got a can interface built in! Lush. 

Would only need to run my shield for the screen which I can power externally if needed. 

 

[Ned]

 Just gotta check the LCD will be OK listening to 3v3 signals... And you'll need to resistor divide the 5v coming back from the LCD for any returning data pins...

[Roman]

Thanks Ned, 

Are you able to tell from this datasheet whether the shield for the screen will cause problems with 3.3v board? 

http://www.4dsystems.com.au/productpages/4D-Arduino-Adaptor-Shield-II/downloads/4D-Arduino-Adaptor-REV2.xx_datasheet_R_1_3.pdf

From my understanding it just has 5v and ground for the screen power (I can power it externally isntead if needed)
and uses a digital pin to reset the screen (Would this be 5v currently and needs to be 3.3?)
and then uses serial to communicate data to the screen (Would this need adjusting as well?)

Either way, I've ordered one. 
Even if the only thing it acheives is being a 2nd canbus device to simulate my ECU so I can bench test my canbus instead of going down to the car, to plug into ECU.
Then its worth its weight in gold already. 

[Ned]

im not sure what LCD you use, but i looked up the uLCD-70DT and its actually 3V3 anyway, with 5v tolderant pins. Still needs a 5V supply, but the data lines will be fine

[Roman]

Thank you!

I'm definitely going to add a glut of extra code for a V2.0 of this project now haha. 

[Roman]

Okay sooooooo

I have been scope creeping the shit out of this project before finishing the basic task I want it to do haha. fail.

But it was super easy to setup some 3d arrays to write some values to. 

Currently have one pot that can scroll up or down, one goes left or right, and a 3rd pot can adjust the value in the cell. 



But the idea is that my arduino will lookup rpm and load from the ECU, which will be the axes on the table.
Which is where I will store ignition trim values for my closed loop ignition trim cruise control mode. 

In the GUI for the screen each of the cells is an individual string with an ID. 
So I have setup a second array that stores all of the values of the stringIDs. 

So when it needs to write to the current cell, it just looks up that same value in the second table so it knows which string to write to. 
Time consuming to enter all of the data but will be cool to see what it does.

Really need a rotary encoder instead of a pot though so I'm not changing cell values the instant it reaches that cell value. (Can use the button on rotary encoder to tell it to store the value)

Hard part from here is that I want to store these table values somewhere apart from ram so the values are persistent after the screen turns off. 

Any ideas on best way to acheive this? Thinking a txt or csv file on SD card somehow.

I'm not sure if eeprom will be too much of a ball ache to try store things into. I guess a file on SD card is nice because it persists after I update arduino code.

[Ned]

Why not make it read the values from the ECU on bootup? That way you're sure its correct. You can just store them into the eeprom, and add a CRC to do an error check to see if its actually any good as EEPROM can be a bit hit and miss when you try and write to it as the power is going off or the wind is blowing from the south south west or the little hand of the clock is in the same place as the big hand

[Roman]

Because I want the values to all be zero initially, and for troubleshooting the screen I wanted them to all show VAL for starters to make sure it works (I found one or two cells out of order)

Is using eeprom a ball ache to store bytes in? Like do I have to write each bit? 

EDIT: Aahhh nevermind I see I can write bytes. easy! Might be easiest to make my table values 0-255 and store them as a byte position that matches the String number on the lookup table for the screen. 

[Ned]

I'm not following your string lookup thing TBH... 

Eeprom wise, a super easy way is you create a unioned strict with your values and an array of bytes and then you can just write them all to the eeprom super easy. Also easy to calculate CRC that way