Jump to content

Arduino stuff/ programing/so cheap


flyingbrick

Recommended Posts

Every time I add a text box in the GUI editor its called something in the program like GenieString55, GenieString66, and so on sequentially.

So in the Arduino, to update a value. I want to write to two places, once to the array and secondly to the screen. 

So if GenieString55 was Row 1 Column 1 and I wanted to write VAL to it. I would need to write something like
 genie.writestring(55 "VAL"); 

But instead it can just write 

 genie.writestring(CurrentStringVal "VAL"); 

Where it finds CurrentStringVal from the 2nd array which is a lookup table with all of the string numbers in it. So it updates the correct text field.

Sorry if this doesnt make sense, one of those things that is easier to explain seeing it in person.

I think I'll try move my array(s) to eeprom tonight.

Link to comment
Share on other sites

  • Replies 416
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

  • 3 months later...

Hahahaha awesome. 

I'm at the stage of "Why the fuck did I put all those houses there and what do I do from here" then look at my code for 10 mins and go do something else hahaha.

Need to start again with the canbus code for the arduino Due which is waaayyy simpler.

Too many 1/10th finished projects at the moment haha.

 

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

Okay soooooo

Arduino Due. Its canbus can work between two Arduino Dues, but you need a transceiver chip to make it work with a "proper" canbus. 
So bought some transceivers, which apon arrival I realised they are the wrong ones. D'oh.
So rethinking it some more, although I like the fast speed of the Due, and the fact that it's got a native canbus thats easier to write for.
Eventually I want to add some other canbus devices in addition to ECU and dash, in which case I dont need or want the bulk of a Mega sized arduino board.
So thats the next problem, if I write a bunch of code for a Due, and then want to add a smaller arduino device I'd need to rewrite all the code rather than just chop snips out of it to make it work. 

So from here. 
I found out about the Teensy. 
Teensy V3.6 is 180mhz 32 bit and basically trumps the Due in every conceivable way while being exceptionally tiny! And it's arduino sketch compatible.

https://www.sparkfun.com/products/14057

It's also got 2 canbus lines and can use this exceptionally small double transducer.

https://www.tindie.com/products/Fusion/dual-can-bus-adapter-for-teensy-35-36/

So since it's small enough and not incredibly cost prohibitive I'll probably make everything on my bus use a teensy + that transceiver for sake of keeping the code easy.

Then 3d print some housings to suit.
Now that I understand things a bit better I dont need to use any of the shields I had.
Should be nice and compact for whatever they end up doing. 

  • Like 3
Link to comment
Share on other sites

14 hours ago, Roman said:

Okay soooooo

Arduino Due. Its canbus can work between two Arduino Dues, but you need a transceiver chip to make it work with a "proper" canbus. 
So bought some transceivers, which apon arrival I realised they are the wrong ones. D'oh.
So rethinking it some more, although I like the fast speed of the Due, and the fact that it's got a native canbus thats easier to write for.
Eventually I want to add some other canbus devices in addition to ECU and dash, in which case I dont need or want the bulk of a Mega sized arduino board.
So thats the next problem, if I write a bunch of code for a Due, and then want to add a smaller arduino device I'd need to rewrite all the code rather than just chop snips out of it to make it work. 

So from here. 
I found out about the Teensy. 
Teensy V3.6 is 180mhz 32 bit and basically trumps the Due in every conceivable way while being exceptionally tiny! And it's arduino sketch compatible.

https://www.sparkfun.com/products/14057

It's also got 2 canbus lines and can use this exceptionally small double transducer.

https://www.tindie.com/products/Fusion/dual-can-bus-adapter-for-teensy-35-36/

So since it's small enough and not incredibly cost prohibitive I'll probably make everything on my bus use a teensy + that transceiver for sake of keeping the code easy.

Then 3d print some housings to suit.
Now that I understand things a bit better I dont need to use any of the shields I had.
Should be nice and compact for whatever they end up doing. 

Please excuse my ignorance. I don't know how this canbus stuff works, BUT I have successfully moved my arduino code directly to an ATtiny45 chip and it ran without issues, all contained on a single chip. Can get them in 2, 4 and 8 KB variants if I remember corectly (ATtiny25, ATtiny45, ATtiny85).

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet-Summary.pdf

Cheap as chips:
https://www.aliexpress.com/item/20PCS-LOT-ATTINY45-20SU-TINY45-20SU-SOP8-ATTINY45/32809882098.html?spm=2114.search0104.3.23.1f1d630cWRA1XH&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10151_10065_10344_10068_10342_10547_10343_5722611_10340_10548_10341_10696_5722911_5722811_5722711_10084_10083_10618_10307_10059_100031_10103_10624_10623_10622_10621_10620_5722511,searchweb201603_2,ppcSwitch_5&algo_expid=c4c137fb-0e6a-4392-9b17-43858c127174-3&algo_pvid=c4c137fb-0e6a-4392-9b17-43858c127174&priceBeautifyAB=0

Please let me know if this helps, or if I'm completely off track!

  • Like 2
Link to comment
Share on other sites

Hey thanks - That's cool but the Teensy is way gruntier :)

It can have 32 bit variables instead of 8, and it's got a floating point processor so it doesnt take a zillion years to calculate a float.

And processor is many times faster.

Canbus itself is usually 2 chips (a transciever which converts canbus frames to SPI or similar, and one that acts as a filter for messages)

My main dash unit / ignition trim computer thingy will be trying to do a lot of stuff at once, so faster the better.

Link to comment
Share on other sites

  • 1 month later...

So I've been busy working on my dash some more.
It was a battle getting the canbus working on the Teensy but figured it out. 
It's funny how just one simple thing can bloat your code so much. 

I've been drawing up the layout for my digidash in MSpaint, because, thug life. 
And you get this super crisp looking font on it that's great. 

bms3cnxa.puw.jpg

But then when I blank out the text, and put the same sized font into the display editor so the numbers can change in realtime.
It looks yuck at pixelated. 

xytmwbiq.mgl.png

Well, it turns out that the screens processor isnt smart or grunty enough to anti alias the text to smooth the edges against the background, which is what most PC programs do.
 Neither the 4Dsystems or Nextion screens can do this. Shitballs.
So I was pretty frustrated here as it makes my screen look like shit when I already know it can look so much better with a smoother font..

However since I'm only really changing numbers on the screen, rather than words. (I can just make the titles part of the background image)
I thought I'd give it a try by making a small image for each digit 0-9, and then so a 4 digit number would be 4 seperate "Write" commands to the screen, that tells it to bring up image number 9 to show 9. and so on.

Previously my code for writing a 3 digit number to the screen was as simple as this: (Where IAT is Intake Air Temperature variable)

genie.WriteStr (9, IAT) ;

Which is essentially just "Write IAT value to String number 9 on your screen"

But because I'm now sending so many more write commands, they are by far the most time consuming thing in my loop of code. 
I cant write every single value that comes in because it will slow things to a crawl and I lose the advantage of my fast processor.
So I need to economize the amount of writes that I am doing to the screen as much as possible.
So for starters I am comparing the existing value to the last one, if it's the same then dont bother doing anything else.
Then it measures the difference in each digit by subtracting the new number from the old number, decides if it needs to write a new value and then writes that digit.
Using the modulo command which is what all of the %10 bits are.

All of this is great but what was previously one line of code has now bloated into this for every variable I write to the screen:

        if (IAT != IAT_old);                                                    
          {
            IAT_Diff = (IAT - IAT_old);                                                                   
              if ( ( (IAT_Diff / 100) % 10) != 0);      {genie.WriteObject (GENIE_OBJ_USERIMAGES, 9, ( (IAT  /  100) % 10) ) ;}        
              if ( ( (IAT_Diff / 10) % 10) != 0);        {genie.WriteObject (GENIE_OBJ_USERIMAGES, 8, ( (IAT  /  10)    % 10) ) ;}         
              if ( ( (IAT_Diff / 1) % 10) != 0);          {genie.WriteObject (GENIE_OBJ_USERIMAGES, 7, ( (IAT  /  1)       % 10) ) ;}            
          }
          IAT_old = IAT; 


Now works pretty sweet! The write to screen time, even when optimized is still about 1000 times longer than anything else in my code though. 
So might try a Nextion screen as apparently they're faster in every conceivable way. They use a cortex m3 which is the same as the brains of an Arduino Due. Dont know what the 4dsystems screen uses but dont think its very grunty.

  • Like 5
Link to comment
Share on other sites

Theres nothing actually wrong with the factory dash it works very well.

But I want to finish this one way or the other as everything im learning is very relevant to work. And it will be the first thing ill have made in a while that combines a lot of different disciplines. (Cad, 3d printing, tuning, canbus, electronics, programming, gui design) so will be satisfying to finish it even if i do end up preferring the standard instruments.

The Nextion screen can run fast enough to have analog type gauges that are useful. So ill see what i can cobble together.

 

  • Like 1
Link to comment
Share on other sites

17 hours ago, Roman said:

Okay so my idea sucks. 

Reading digital digits while driving is distracting and.... shitty.

Back to the drawing board.

You might want to try changing the sensitivity if your struggling to read them, i.e if they are changing to quickly then they are impossible to read.

For digital gauges best use case I think is for something like temps, pressures etc where you want to know what specific value they are running at a glance.

For analogue they work best for quick moving values e.g. rpm, or where you are wanting to look for changes over time.

However using a standard display for fake round analogue gauges i find to be a waste of time, as the resolution and lack of physical needle makes them harder to read.

I ended up with this:

Digital rpm value is waste of time while moving (but is useful in odd case where you want to see exact figure), yellow bar however works well as changes to orange then red at set points.

The temp and pressure values will change to a red back ground if they go out of acceptable range. This is a really good UI pattern to follow, highlight and make standout only in an exceptional state.

For me this works well, the values are there if i want to look, but i'm normally to busy to, so highlighting when something bad is happening is far more useful (bonus for buzzer noise)

Driven Wheel speed is really hard to read, but not important in my use case, but for a road car you would want it to stand out as it's something that is critical to operation of vehicle (so in the center with other values around it).

Note: Values are at bottom as I couldn't see them over the wheel when they were at the top but I would have preferred them at top as your eye would go past them when going to view speedo/rpm.

I modeled it loosely off this dash (Honda City Turbo designed by Mugen) as it's one of the best i've seen on any car to date (improvements would be to get rid of the yellow boxes):

5b56b1baaa03e_1984HONDACITYTURBOII7.jpg.76b46d316b61bcd880e40fb22f8fcc07.jpg

 

The other thing you want to do is remove as many lines/arrows/separators as possible as they all distract the eye from the actual values and if you need them don't put them as a bold colour they should be lighter shade of red/blue so your eyes don't go to them first. For yours I would get rid of blue borders, and make red a much lighter shade (remove a couple of lines and also make them a lot thinner. You will still subconsciously take them in, but they wont distract from the actual data.

 

 

 

  • Like 4
Link to comment
Share on other sites

Hey cheers. 

Yeah one problem I found was that even on the least bright screen setting, my screen was still too bright for night time. 

So darker colours needed for everything.

Also at a real life viewing distance, everything was just too small. 

I was thinking I had heaps of screen real estate and I'd struggle to fill two screens, but in real life I probably need half as much stuff on there.

I know what you mean about distracting elements/colors, will take a lot of trial and error to get the right balance of not looking too bland but also being easy to read. 

 

In other news. 

So far I've only been putting all of my code into a single Class, in the "loop" void. 

However it's become such a lumbering beast that I've now split it all out to seperate functions.

Now my main loop is just down to only a few lines of code again, and more represents the logic of the order of things rather than the nuts and bolts.

Part of the reason for this, Is that sending and receiving can values works insanely fast, so I will do say 20 read/writes of can data for every 1 write to the screen.

Link to comment
Share on other sites

  • 3 weeks later...

So I've been distracting myself with all of the screen related stuff, which is a sidetrack from what I wanted it to do initially which was adjust the ignition timing. So spent some more time on the code for this. Putting each segment of code into its own class makes things sooooooooo much easier to troubleshoot and write! You can so simply just turn off or on a whole chunk of code to isolate it.

I tested my ignition trim computer on the car, but not allowing it to make any changes to actual ignition timing. So this means that every result from the test should come back as "No change needed" if its working correctly.

So I found some conditions which were generating false positives so I added in some more conditional filters.

If the car was going too slowly and low rpm then its quite jerky in how it tries to change the vehicle speed. I could probably fine tune the PID settings in the Link a bit more, but its easier to just put a minimum speed filter on it instead.
I'm not currently outputting which gear the car is in, via CAN, so I'll do that so I can specify a minimum of 3rd or 4th gear as well.

If rpm or TPS delta deviates too far from the initial test conditions, or fuel cut comes on, it nukes the current test results and it starts again.
I am still getting a few false positives, maybe 1 in every 20.

So that's probably good enough that it will still allow the system to work correctly as intended but I'll add as many conditional filters as needed to make it as good as is practical.

Speaking of side tracking though. Nextion screen turned up, and I pulled it apart before even testing it haha. As it's a 7" screen with 800x480 res, I found a 50 pin ribbon cable 9" screen that's 800x480 as well so wanted to see if the guts of the Nextion could run it. Which it does! And it looks awesome.
Needs an external power supply to the LCD backlight though so its a bit of a bodge. But now I can use a PWM signal with a mosfet to vary the screen brightness directly from the Teensy.
It's definitely better in every conceivable way to the 4DSystems screen.
I'm toying with the idea of using a Photoresistor to adjust the screen brightness automatically rather than just having day/night settings based on whether headlights are turned on. Or maybe I could use a mix of both, so if lights are on but its still very bright outside it will keep a bright screen.

I also swapped with a friend, some 3mm knurled inserts for some buck converter power supplies and a bunch of opto isolators, so now I can get all of the 12v signals like lights on/off converted down to 3.3v easily without any risk of blowing it up.

It was also a ball buster trying to figure out why the screen wasnt receiving any commands from my Teensy, which was because they need a common ground point in order for the serial communications to work. blargh!

Getting there! 

  • Like 4
Link to comment
Share on other sites

hey roman, instead of fancy opto isolators, you can just use a couple resistors... or can go a bit fancier with a couple resistors, a diode and maybe a cap if you wanna be really sure its fine. Might save some space and cost in the end?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...