Arduino Airsoft Controller with Display

Have questions about a SparkFun product or board? This is the place to be.

Moderator: phalanx

Re: Arduino Airsoft Controller with Display

Postby Mee_n_Mac » Tue Feb 28, 2012 3:17 pm

StaticDet5 wrote: I'm eyeing a car battery in the corner, but I'm wondering if that will destroy things... Here's where that lack of electrical confidence comes in to play. At my heart, I know a volt is a volt is a volt (and an amp is an amp is an amp), but hooking that massive brick up to something like this... dunno. Somewhat intimidated.


The car battery will be something like 12.2 - 12.8 V and the LiPo was ... 11+ V ?? So the voltage is a little higher but I doubt that would make much of a difference to the motor, it's not that big a % increase. But the car battery will supply 100's of amps upon demand, the LiPo somewhat less. So IF the motor stalls and IF the LiPo not supplying enough amps to fry it was the motor's saviour (I doubt this to be the case), then the car battery would surely fry the motor under that condition. I'd not worry about it, there's a fuse for that ... isn't there ? :twisted:

While on the topic of a stalled motor ... I like the idea of controlling the motor speed via PWM. But you do have to be a little careful not to deprive the motor of enough "umpf" to be able to finish compressing the spring. If the spring takes more torque to compress than the PWM is giving to the motor, it'll stall (stop moving). A stalled motor sucks a lot more current down than a running motor and it's more common to burn out a stalled high-power motor than a stalled low power motor. My guess is your AEG motor would not survive. The kewl thing is that, given your current sensing, I think you could slow the low torque portion of the cycle down quite a bit and recognize when the sector gear engages the spring/piston and ramp up the PWM accordingly. There's something the Extreme guys can't do !

And on the topic of slowing down the motor ... what's the thinking re: a single shot vs burst vs full auto ? A selector switch makes it easy but in keeping with your original concept not to have that, even with a switch (vs a potentiometer), here's a thought off the top of my head (FWIW). Since the cyclic rate is probably too high to allow a person to easily squeeze off a single round at full speed, you could slow the 1'st shot down so that a person could squeeze and release the trigger before the 2'nd shot cycle happens. If the trigger is still depressed the logic switches to burst mode and checks to see if the trigger is still held after the 3'rd (or 5'th, whatever your burst length is) and then goes into full auto mode. I guess a delay after #1 shot would work as well. The question is then if the extra 100-200 msecs delay to get into full auto is annoying enough to warrant a separate selector switch and whether any switch bounce will complicate the scheme.
Mee_n_Mac
 
Posts: 4314
Joined: Thu Apr 28, 2011 4:10 pm

Re: Arduino Airsoft Controller with Display

Postby dkulinski » Tue Feb 28, 2012 4:01 pm

You may want to add some logic to learn the current ramps of a particular gun. Set it to learn mode, hold the trigger down for X seconds and your circuit now has some brains to drive the brawn!
dkulinski
 
Posts: 216
Joined: Tue Apr 05, 2011 12:36 pm

Re: Arduino Airsoft Controller with Display

Postby StaticDet5 » Tue Feb 28, 2012 4:53 pm

I'm going to try the car battery tomorrow. If I blow a fuse, I blow a fuse. Heck, I probably have a replacement motor...

When I first played with the PWM driving, I only dared to take it down to 220 (out of 255). At that point I was worried about stalling the motor (This was with the original P-90 gearbox, which was probably suspect). I'm hoping that dkulinski's code will give me enough insight into the motor amperage. I'd love to build in an adaptive system that recognizes when the motor is having problems, overriding the PWM settings to push the motor as hard as possible (or shut the motor completely off, user preference).

I'm not there yet. I'm going to need significant information about my motor characteristics to attempt to implement that.

However, it's a really worthy goal. Anyone that mucks around in their gun eventually blows a fuse or a motor. Killing either, in the field, is a major bummer (most folks don't carry a spare fuse, smart ones tape a spare in the gun).

The issue with a "hesitative" approach to achieving F/A cycling is the "tactical need". When you need F/A, you need it immediately, not in 1/5th of a second. At that moment, I think that split second is going to be noticed.
That being said, I'd like that to be a option.

I think this project is going to require multiple software builds, in the end. I don't think I'm going to be able to accommodate all of the various trigger builds into one cohesive build, with run-time configurable options. I think I'm going to have to pick and choose what to include in the core package.

My package of protoboard arrived today. It looks like it's going to work great as an Arduino Nano backpack. If the car battery doesn't work, I'm going to start playing with "puzzle piece" parts to figure out how to lay-out this board If I can get the protoboard to accommodate the parts, I can actually integrate the project and make it pretty.
Static
StaticDet5
 
Posts: 205
Joined: Tue Oct 12, 2010 8:08 am

Re: Arduino Airsoft Controller with Display

Postby dkulinski » Wed Feb 29, 2012 11:44 am

Alright, I was talking with a friend who mentioned a thermal printer. Then it got me thinking, how cool would it be to be able to output diagnostics to a thermal printer? Hell you could have usage based billing for a rental shop.

Just had to rip that out of my brain.
dkulinski
 
Posts: 216
Joined: Tue Apr 05, 2011 12:36 pm

Re: Arduino Airsoft Controller with Display

Postby StaticDet5 » Thu Mar 01, 2012 9:13 am

Image
LOL
We're getting there.

I just borrowed some more money to get a new LiPo. It's on a slow boat from China or something, but it's on the way.

I went to charge another borrowed NiCd yesterday. Sixty seconds into it I got a nice flash and pop, and the residual sizzle. I hit the power switch on the power supply, and the sizzle stopped. Then I freaked a little bit and put on a gas mask while the damn thing cooled down. I have no idea how much cadmium is in these things. I know it was probably a bad solder joint or something (the arc happened between the cells, with a trail down one of the cell bodies), but it was a little nerve wracking.

The car battery isn't going to work. Not charged (I may have left my car charger at my ex-wife's house...)

So, new battery.

In the meantime, I'm working on the display and communications scheme. As a "side" project, I may look at the thermal printer idea as a separate item. I did a quick check this morning, and I don't have any thermal printers anymore (I used to do restaurant consulting). That's going to be a bit of a bar to working on that one.

I'm trying to consider a communications scheme between the Arduino Nano board and the 4D Systems uOLED. I'm going to use software serial ports (so that the default serial port on the Nano is not used). I also want to avoid updating the display during critical Nano functions (gearbox operations and chrony measurements), except possibly for a shot counter (I want to be able to watch the magazine capacity drop or the number of shots fired increase, because I'm a child and that looks cool). After I get the project "running", I'm going to mess with the software, and see if I can sneak information out to the display.

I'm going to try to offload as much of the process to the display. It's got a pretty capable processor, and I can pass tons of information to it over the serial line without taking up any additional I/O lines. I know the display communicates in Hex (I've already sent some sample messages to the display). I'm thinking about serial messages in a simple format Alpha-Alpha-Message-Terminator/EOL. Utilizing two alphabetic initiators will allow for an insane number of message types. Do I need to incorporate a "check" or "confirmation" system? I don't think that the system is going to be critical in operation of the gearbox. If a message or two gets missed, it won't be a big deal.

I'm also starting to jot notes about what kind of messages are going to need to be passed back and forth. I'm hoping to be able to handle the messages as functions between the two systems. That will allow maximum flexibility and expansion.
Static
StaticDet5
 
Posts: 205
Joined: Tue Oct 12, 2010 8:08 am

Re: Arduino Airsoft Controller with Display

Postby dkulinski » Thu Mar 01, 2012 9:42 am

Modularizing your code is a good idea. You should easily be able to separate out a message queue that doesn't interfere with the cycling of the gun. I don't know how much logic there is to the oLED module, but if it can contain a program, perhaps you can pulse a pin each shot and have it decrement a counter.

The thermal printer was just a crazy idea, but I thought it would be a neat addition. A paper trail for your AEG.

Good luck with a battery. I wish I could help you out but I only have a 7.2V NiMH for my RC car and probably no where close to you.
dkulinski
 
Posts: 216
Joined: Tue Apr 05, 2011 12:36 pm

Re: Arduino Airsoft Controller with Display

Postby Mee_n_Mac » Thu Mar 01, 2012 5:08 pm

I think you need to reconsider your choice of T.O.H.A. ! While the above looks functional enough, I think the one below would be even more betterer. Since it's electric, I'm sure there's some way to make an Arduino control it. Perhaps PWM it's motor in conjunction with the select fire switch. SA mode gets you a once around the teeth but FA gets you foaming-at-the-mouth cleaning action. F-A-T-M combined with FA fire has got to be more intimidating that FA fire alone !

Image
Mee_n_Mac
 
Posts: 4314
Joined: Thu Apr 28, 2011 4:10 pm

Re: Arduino Airsoft Controller with Display

Postby Mee_n_Mac » Thu Mar 01, 2012 6:19 pm

StaticDet5 wrote:Do I need to incorporate a "check" or "confirmation" system? I don't think that the system is going to be critical in operation of the gearbox. If a message or two gets missed, it won't be a big deal.


I agree, no big deal. Since you'll have to check the header/message_type in any case, you'll have some measure of error checking already. Verify that the trailer/EOM code is good as well and I'd think that's enough. Any message with a bad header or trailer gets tossed. I guess you could have the display request a re-transmission in those cases. You might also want to have some method for the user to request a resend/refresh of the last message, in case the display looks AFU to the user.

The bigger question is what can you display, usably, on the display. You wanted a shot counter (or shots remaining counter) and that's good but what about "warnings" you might want to see quickly in the heat of battle ? Like a "getting low" (on BBs) warning that's immediately informative or a "shooting dry" warning (via your chrony detectors) or a "blown fuse" warning (though that's probably obvious w/o any display) ? I'm sure there's other useful info you might want to know, though not in the heat of battle. So some way of conveying the immediate warnings (background color ? green, yellow, red levels ??) and some way of flipping through other informative screens might be needed.

The above implies to me there's some need for a direct user interface to the display processor and perhaps some way for the display to send messages to the Arduino to request info ? I believe your display can do the latter but I don't know what might be possible for a user input.
Mee_n_Mac
 
Posts: 4314
Joined: Thu Apr 28, 2011 4:10 pm

Re: Arduino Airsoft Controller with Display

Postby StaticDet5 » Fri Mar 02, 2012 9:03 am

This is the display. Again, so far I've loved this display. It's cheap (The 96 display that I started with was under $40), incorporates a processor, a uSD card slot, tons of options.
http://www.4dsystems.com.au/prod.php?id=85

The company now offers a direct programming language for the onboard processor. I picked it up and began coding with it after about an hour of study and another hour of trial and error. The end result of that trial and error was a program that sends a character on the serial line to a terminal display and waits for a reply, displaying the result.

I have a question about this line in the manual though, and I'm about to run out the door:
Master Reset signal. Internally pulled up to 3.3V via a 4.7K resistor. An
active Low pulse greater than 2 micro-seconds will reset the module. If
the module needs to be reset externally, only use open collector type
circuits. This pin is not driven low by any internal conditions. The host
should control this pin via one of its port pins using an open
collector/drain arrangement.


Right now, I have this pin on the Arduino Digital 4. I need to reset this display at the start of the program, so that the Arduino and the display are sync'd, and checking with each other.

Do I do a simple "digitalWrite(4, LOW)" for at least 2 microseconds? If so, what do I do after that? Is it the opposite, do I set the pinMode to "Read"?

I gotta run. If you folks know the answer off the top of your head, great. Otherwise I'll be back and plunging into research while I get on the phone with Verizon.
Static
StaticDet5
 
Posts: 205
Joined: Tue Oct 12, 2010 8:08 am

Re: Arduino Airsoft Controller with Display

Postby dkulinski » Fri Mar 02, 2012 10:48 am

I don't believe that the ATMega has open collector ports. You either have open drian or open collector. In this case you just need a transistor setup like the example in wikipedia. I suspect a simple 2N2222 would be great and hopefully you have some laying around.

Basically because they are pulling up the voltage with a resistor you must be able to source enough current to make that connection an active low. You could always disable the resistor on the ATMega and then set it to an active low but there may be enough current to hurt the ATMega.

Please feel free to correct me if my explanation is incorrect.
dkulinski
 
Posts: 216
Joined: Tue Apr 05, 2011 12:36 pm

Re: Arduino Airsoft Controller with Display

Postby Mee_n_Mac » Fri Mar 02, 2012 3:20 pm

StaticDet5 wrote:Right now, I have this pin on the Arduino Digital 4. I need to reset this display at the start of the program, so that the Arduino and the display are sync'd, and checking with each other.

Do I do a simple "digitalWrite(4, LOW)" for at least 2 microseconds? If so, what do I do after that? Is it the opposite, do I set the pinMode to "Read"?

I gotta run. If you folks know the answer off the top of your head, great. Otherwise I'll be back and plunging into research while I get on the phone with Verizon.


What voltage is your Arduino, 5V or 3.3V ? I believe all the DIO pins on the ATmega MCU (your Arduino's "brain") can source and sink something like 40 mA, so they are not an open collect/drain type of output. Ideally you shouldn't be tying one to the display reset line and instead be using something along the lines as suggested above ... a 2N2222 would be fine. Put an ~1 kohm resistor from pin4 to the base of the 2N2222 and then connect the emitter to ground and the collector to the reset line. Pulse pin4 high for >2 usec to reset the display. The 2N2222 provides a pull down to ground on the reset line for that time. This is no different in concept that your present use of a power FET to provide a connection to ground for the AEG motor.

SInce it's stated that the reset line/pin "is not driven low by any internal conditions", you might get away driving it directly from a DIO pin but only if you have a 3.3V Arduino. And then you'd be giving up the possibility of some other device (a button perhaps) resetting the display (only). And violating 4D's explicit instructions. BTW I'll opine that the serial output from the display (that might go to an Arduino serial in pin) is a 3.3V level. This may or may not work reliably with a 5V Arduino. You can buy or implement a level shifter if needed.

I don't know if you need to have the Arduino do a reset every time it starts up. Ideally the display should have some power on reset of it's own (??) and then just sit there, awaiting instructions. I could guess that it's possible that the Arduino bootup process might put some crap out on the Tx line to the display and thereby confuse it, so a post Arduino bootup reset might be a good idea, if not a necessary one. So far as I can tell there's no real sync'ing btw the Arduino and display, just as you haven't needed to sync your PC to talk to it.

There also appear to be 2 general purpose IO pins, so some direct user input (?to scroll screens, etc?) is possible.
Last edited by Mee_n_Mac on Fri Mar 02, 2012 8:07 pm, edited 1 time in total.
Mee_n_Mac
 
Posts: 4314
Joined: Thu Apr 28, 2011 4:10 pm

Re: Arduino Airsoft Controller with Display

Postby StaticDet5 » Fri Mar 02, 2012 5:47 pm

I'm really glad I didn't "just wing that mother", like I normally do. I'll check for 2N222's tomorrow. I've got to have one somewhere, I just didn't know how to use them before :)

The start-up sequence needs to incorporate a system check, including establishing communication with the screen (or establishing that there isn't a screen).

I think.

I definitely want the self-check at the start. I'm going to increase the complexity of this system, I want checks in place that I'm not going to introduce a hazard. Bare minimum, I want the system to hang and start announcing that there is a problem if the trigger is jammed closed. If that condition exists, I don't want the gearbox energized, and I don't want the software progressing forward to the "loop"

I would like to be able to reset the screen from the software, so I'm going to figure out the 2N222 issue.

I'm definitely going to use the I/O pins on the display. I'm probably going to use it to navigate modes and screens. I'm really thinking that the screen interaction will drive the firing modes of the Nano/Gearbox. This way I can simplify (keep small and fast) the program on the Arduino Nano, and make the most use of the MASSIVE amount of storage on the display processor.
Static
StaticDet5
 
Posts: 205
Joined: Tue Oct 12, 2010 8:08 am

Re: Arduino Airsoft Controller with Display

Postby Mee_n_Mac » Fri Mar 02, 2012 11:18 pm

StaticDet5 wrote:The start-up sequence needs to incorporate a system check, including establishing communication with the screen (or establishing that there isn't a screen).

I think.

I definitely want the self-check at the start.


So let me give you some semi-random thoughts. Upon power up the Arduino (or whatver MCU) boots and all the I/O gets turned into proper inputs and outputs. Then you want to do a BIT (built-in-test), aka your pre-fire system check. So what should be in this BIT ?
- Check of the battery voltage. Depending on where you do this, it could also check for a blown fuse and/or blown motor
- Your trigger not pressed check
- Communications to & from the display
- Magazine inserted (and perhaps not empty)
- Trigger works (requires user to "fire" to finish BIT, but motor does not run during BIT)
- ???

Now some of these could be no-go, show stoppers and others might be just a caution/warning variety. For example the battery check might come back as good (>X volts), OK/caution (<X, >Y volts) or bad (<Y volts). When BIT is complete the display shows a GO screen or a BAD screen or a Caution screen ... of some type. Again you might want to communicate the go and caution via background colors, allowing the display to display whatever info it was you wanted when you dreamed this all up. The user could scroll through various status screens to get the details you might not want to clutter the "fire" screen with.

And during operation, you could continue to run some BIT in the background. Battery voltage (perhaps under load too) would be good to monitor as well as fuse/motor continuity. Mag fullness might be nice. And any deviant condition such as excessive current or motor stalled or dry firing or ??? Again some faults might warrant shutdown of the gun, others just a caution to the user.

FWIW when I was thinking about how to power down my electric AEP hybrid, I settled on using the magazine as an on/off switch. Inserted mag applied power, mag dropped is power off. A big enough capacitor supplied enough power to keep just the MCU running between any reasonably quick mag changes. The safety switch was to be used to sleep or wake the MCU (since I wasn't sure the bootup time would be quick enough to use it as a parallel on/off switch) and break the fire circuit. I didn't want a separate on/off switch ... that I'd surely forget to turn off. Long periods w/o any activity would also sleep the gun.

Now in my case the mag holds the BB until it's fired and so an optical detector in the mag would let me know if I was out of ammo or not (needed as the NBB doesn't have a slide that locks back on empty). In your case it might be advantageous to make the mag "smart" as well. Perhaps have some way to know, if only approximately, how full/empty it is. And not wait until the last BB to let the user know. Might be useful to know you have <5 to go before you pop out to engage 6 targets. :shock:
Mee_n_Mac
 
Posts: 4314
Joined: Thu Apr 28, 2011 4:10 pm

Re: Arduino Airsoft Controller with Display

Postby fistlo » Sat Mar 03, 2012 11:12 pm

This is going to be my first post here. I came across this problem recently and I think there is a much easier and more interesting solution.

You want the "state" per say of the motor right? I believe motor controls are developed using hall effect sensors. I'd recommend one.

Digikey

or

http://www.gmw.com/magnetic_sensors/sen ... 1_Acc.html
fistlo
 
Posts: 1
Joined: Sat Mar 03, 2012 11:09 pm

Re: Arduino Airsoft Controller with Display

Postby StaticDet5 » Sun Mar 04, 2012 10:00 am

My plan, right now, is to make use of the display's capabilities and "backdrop" the primary data with colors, warning of an issue.
Black = no detected issue
Yellow = Caution
Red/Flashing = Critical

The "combat" display would only have a couple of key pieces of information. Shots (user selectable shots fired versus mag count), battery condition, firing mode, Feet Per Second (FPS).
If the gun detects that the shots caution threshold has been crossed, it now displays the number of shots in a black text on yellow backdrop. If the system detects that the critical threshold has been crossed, it changes the color to red. If the system detects a dry fire (gearbox cycling, but with no rounds coming out), then the WHOLE screen will strobe red.
This way, tactically relevant information is pushed as hard as it needs to be pushed (if that makes sense). In your example of popping out to engage 6 targets, a glance at my screen will immediately tell me if this is OK. I don't need to know the number (It takes some time to actually process that information). Instead, I just need to know "Black, Yellow, Red". If I see any red on the display, I definitely don't need to jump out.

Magazines... I've given a ton of thought to the magazines. Any solution for the magazines needs to be cheap and easy to implement. I've gone into games with over a dozen mags. I've also gone into games with 4 different "forms" of magazines.
If I enable a "smart mag", I'm going to first look at the P-90. The P-90 has a semi-enclosed magazine mounted on top of the AEG. There are several places that I could place Hall Sensors to "check" the magazine type. If I just use three Hall Sensors, I can detect 7 different types of magazines (3 bits, two states, MINUS one state as a "mag check"). If I use an analog pin and some resistors, I should be able to scan all the Hall Sensors off of one pin.
I'm leaning towards this method for a couple of reasons:
The maximum cost to modify the magazine is equal to the cost of three miniature neodymium magnets.
There are two primary types of magazines. A linear spring "Low Cap", which typically holds less than 100 rounds. A box spring or clockwork "High Cap", which can hold 200+ rounds. Their mechanisms are different and messing with them can really impact reliability. Detecting the exact number of rounds in a Low-Cap is probably feasible. Detecting the exact number of rounds in a High-Cap is a nightmare (unless you want to count them yourself).
Most AEG's do not feed the complete magazine to the gearbox. When they're "Empty", there are still a few rounds left. This means that an "empty mag" still has some wiggle room.
On the P-90, there are plenty of locations to mount the magnets and detecting Hall Sensors.
The computer is going to track when the gearbox cycles, and if a shot is fired with that cycle. We'll know when a round leaves the AEG, and we can decrement the counter then.

I can't have the AEG go into a low-power mode upon dropping the magazine. One of our big safety procedures at the end of a game, is to drop the mag, fire 2-3 shots on single shot, to relax the spring and make sure the system is clear. Simply dropping the mag doesn't clear the mechanism.

You folks were absolutely right about the 2N2222 transistor. I've got a bunch of 2N4401's lying around, that seem to be working. The display is resetting when I ask it nicely.

However, now I'm at the icky portion of the programming. I need to get two different processors to talk using a common language.

Code: Select all
/* AirsoftComputerDisplay3-1-12

SS denotes Software Serial

Arduino            Display  (uOLED 160)
Pin 2 (SS RX)      Pin 3 (TX)
Pin 4 (SS TX)      Pin 5 (RX)
Pin 4              Pin 9 (Reset)
5v                 Pin 1 (Vcc)
GND                Pin 7 (GND)

Arduino
* LED on board at pin 13
 * Motor control on pin 10 (PWM pin)
 * pushbutton attached to pin 7 from +5V
 * 10K resistor attached to pin 7 from ground
 * ADC on analog pin 0
 * ---------------Important-------------------
 * Hall Effect Sensor not used in this sketch!
 * Hall Effect Sensor on pin 8 (Honeywell SS451A)
   Hall Effect Vin (5v) has a 1k resistor to Hall Effect Output
 
 * Note: on most Arduinos there is already an LED on the board
 attached to pin 13.
 * 30amp Current Sensor between battery plug and MOSFET board.
 * Current sensor output wired to Analog 3


*/

#include <SoftwareSerial.h>

const int buttonPin = 7;  //Trigger switch attached to digital pin 7
const int ledPin = 13;  //onboard LED on pin 13
const int MotorPin = 10; //Motor drive pin (on MOSFET) connected to PWM pin at pin 3
const int VoltageMain = 3;  //Voltage Divider connected to Analog 3
const int Hall = 8;
const int CurrentSensor = 0;  //Current flow sensor attached to Analog 0
const int MotorSpeed = 255;  //PWM value for motor, max 255
const int LowAmpTrigger = 770;  //Amp level direct from ADC, signaling end of cycle ~680 for G36
const int DisplayReset = 4;   //Display Reset Pin
int VMain = 0; 
float ADCRead =0;
int buttonState = 0;
int HallState = 0;
int IMain = 0;
float IRead = 0;
int DebounceDelay = 50;  //Button debounce delay in milliseconds
int SensorDelay = 1;  //Sensor Read Delay in MICROSECONDS
byte DisplayIncoming; //The incoming message from the display
byte Test = 'Y';      //The reply to the display

SoftwareSerial mySerial(2,3);  //Software Serial is going to be used to
                               //communicate with the display, leaving the
                               //basic serial port unencumbered

void setup(){
 
  digitalWrite(DisplayReset, HIGH);    //
  delay(10);                           //
  digitalWrite(DisplayReset, LOW);     //  This is the code to reset the uOLED display
  mySerial.begin(115200);
  Serial.begin(115200);
  delay(500);                          // Startup both serial ports, so the computer's termnial window can be used for checking
 
  DisplayIncoming = mySerial.read();
  Serial.print("From Display  ");
  Serial.println(DisplayIncoming);
  if (DisplayIncoming != 5){           //  This is arbitrary right now, I just want the display to think everything is AOK
    mySerial.print(Test, HEX);
    Serial.print("Sending ");
    Serial.println(Test, HEX);
  }
 
 
 
 
}

void loop(){
}


I have the display set up to look for a hex 'Y' over the serial line.
Here's the display code. It's very simple, BUT THIS IS NOT ARDUINO CODE!!!! Please don't try to load this into your Arduino.
Code: Select all
#platform "GOLDELOX-GFX2"

/*DET5 Labs Visual Display Module for the P-90 Smartgun Mod 0

*/

#inherit "4DGL_16bitColours.fnc"

var combuf[1];     //24 variables = 48 bytes
var Test := 0x54;  //Hex for T

func main()


    gfx_Cls();
    txt_Set(FONT_ID, 0);
    txt_MoveCursor(0,1);
    print("DET5 Labs \nP90 Smartgun Mod 0\n");
    print("\n");
    print("Comms Check\n");
    setbaud(BAUD_115200);
    com_Init(combuf, 2, 0);  //Serial Buffer

    serout(Test);  //Send the contents of "Test" out over the serial line
    pause(5000);  //Wait 5 seconds
    Test := serin(); //Put the contents of the Serial Line into Test
    //print(Test);
    if (Test == 0x59)  //Hex for Y
        print("Successful\n");
    else
        print("Error\n");
        print(Test);
    endif
    pause(5000);

endfunc


Right now, I think it's a timing issue that I need to resolve. I spent the morning playing with the transistor issue, making sure that I had that correct (I was making it too complicated again).

The code is just to make sure I have the concept of communications between the Arduino and the uOLED down. I can get the uOLED to behave correctly by manually sending communications over the terminal display. I can't get it to work when the Arduino sends those same commands. I'm trying different formatting (Hex, Dec, etc), but not getting anywhere. I'm a little fried right now, so I'm taking a break for the day.
Static
StaticDet5
 
Posts: 205
Joined: Tue Oct 12, 2010 8:08 am

PreviousNext

Return to SparkFun Product Questions

Who is online

Users browsing this forum: Bing [Bot] and 5 guests