Stroudsburg, PA
This code has me repairing my original mpu from my machine!
Then I will start on the rest of the project! I love this!
(Topic ID: 269190)
Linked Games
Stars
Stern Electronics, 1978
Topic Gallery
Is there a reason I couldn't use an Uno for this? Talked about the project to a friend and he said I could have it. Would save me a few days of waiting on delivery!
I also think I misunderstood what the OP said about requiring CH340 drivers... it that to say the ones with the CH340 need additional drivers to work, not that the source is written for the arduino with CH340?
Quoted from Chalkey:Is there a reason I couldn't use an Uno for this? Talked about the project to a friend and he said I could have it. Would save me a few days of waiting on delivery!
I also think I misunderstood what the OP said about requiring CH340 drivers... it that to say the ones with the CH340 need additional drivers to work, not that the source is written for the arduino with CH340?
I haven't tested the Uno, but it should work.
There's no dependency on the version that uses the CH340 driver. It's just a common stumbling block for people new to Arduino, so I mentioned it in the documentation. People (myself included) buy the really cheap Nano knockoff and then have to do some gymnastics to get it talking to the computer to program it.
The only thing that might give the Uno trouble is that I've coded everything for direct port access on the Arduino because I needed the speed. The built-in functions for setting/reading pins work for any Arduino, but they're too slow for this application so I modify the ports directly. That said, I *believe* that the ports are the same between Nano & Uno, so I don't anticipate that causing any problems.
My first test circuit was no good, but I've updated it now to a working solution.
I should have realized that it would be unstable. The Arduino can be powered through the IO pins and occasionally get enough power to try to boot even without power to Vin. I'm able to run for quite a while and then I experience some bus collisions with the Arduino competing with the M6800.
So I've switched to a new strategy. The switch will simply control the Halt signal (and A9 & A12). To boot to the original code, inputs to those lines will be tri-stated. Then the M6800 will just boot as normal. Additionally, I've added a chunk of code to the beginning of the Arduino so it starts out with all its pins tri-stated and it watches the VMA line for three seconds. If it sees activity on the VMA line, then it assumes that the M6800 is awake so it halts until the machine is reset.
The new circuit diagram is not something I've tested with the 74126 (in the diagram). I tested with the 74LS240 and connected /G to ground with the switch (floating is tri-state). I'll have to get my hands on some 126s and try it to be sure.
Now that the boot mode relies on one connection (grounded = Arduino, float = M6800), I've mounted a switch in the front of the cabinet so I can get to it through the coin door.
My daughter card still uses an alligator clip to connect to the top of R134. I'm looking for a better solution for that.
2020 board (resized).jpgBoot control switch (resized).jpgWiring rev3 (resized).png
My breadboard situation is a little janky but I did not expect whatever this is to happen at boot. What's the boot process supposed to look like? I assume not a lot like this:
It will actually get into the diags when I press the test button. The display test works but goes about twice as fast as the normal one. The other tests I stepped through pretty quickly and had a lot of the same rapid firings of random coils. I verified the layout of all the wires. One thing I did wrong was I had the external power source connected when I booted it the first time so if I fried it, I fried it. I looked right at it but didn't process one of those pins was for 5v to the arduino.
@chalkey, the first version i made was a breakout board with individual jumpers that I had to manually put on the j5 one by one. I followed the instructions and it worked right the first time. I was amazed. I took it off and put it back on, and it did the same thing yours is doing. I must have taken it off and put it back on half a dozen times and it either did that or didn't boot at all. It's a real pain in the rear to keep track of all of those stupid pins standing next to the machine. I finally broke down and soldered a board together for a more permanent solution and never had a problem since. I thought I'd fried my machine the first time that happened to me. It's probably just a wire in the wrong spot. If you're concerned, put the processor back in and make sure the original code still works.
20200521_162321 (resized).jpgstarsduino (resized).jpgSkipped the breadboard and have all the pins going straight to the connector. Reflowed and cleaned the mpu pins. Same behavior. I can see the beginning of a beautiful attract mode before it shits. Seems like it's so close.
Chalkey This is exactly what my machine does. I even built another rig to make sure everything was wired up correctly. It's like it's almost there. I can go through the options and they run really fast. Like #14 the music level it will go 0,1,2 really fast, holding the credit button will make it stay on a number.
The only code that will play a game on my machine is the very first stars2020.ino file. The second update will start a game, but the displays are funky. Anything with SelfTestAndAduit hasthe crazy testing start and won't go into a game. I ran out of ideas and I'm stumped.
I am using an original Nano. Chinese copies didn't work for me as they wouldn't load a sketch even with the correct drivers, which seems can happen with those. Missing boot loader or something.
The M6800 chip is back in my machine and runs normal.
Chalkey - Man, that's painful to watch! Sorry about that!
Do you have the capability of plugging into a laptop or nearby computer so you can monitor the Arduino while it's running?
If so, I'll make a special file that just goes out, interrogates the hardware, and reports back on the status.
Maybe we can figure out what's going on with your machine and 8bitrobo .
I can do it Saturday, I'm on shift all day tomorrow. I wonder if it's some difference from the hardware being an Uno. I've messed with Pi's a tiny bit but don't know anything about Arduino stuff. I'll have some of the correct ones in at the end of next week to compare as well.
Quoted from Chalkey:I can do it Saturday, I'm on shift all day tomorrow. I wonder if it's some difference from the hardware being an Uno. I've messed with Pi's a tiny bit but don't know anything about Arduino stuff. I'll have some of the correct ones in at the end of next week to compare as well.
I was just wondering the same thing. They're supposed to be the same, but maybe a timing thing. The monkey wrench to that theory is that 8bitrobo can run old code fine. I'm working on a diagnostic package. I'll upload it and put a link here.
8bitrobo and anyone else using a chinese Arduino: You probably have to use the old bootloader. In the IDE go to Tools/Processor: ATmega328P (Old Bootloader). That had me stumped for days and was the biggest hindrance to me getting it done initially.
Also, are you going to Sketch/Add file and adding every file to the (sketch before uploading to the) Arduino?
I've created a new test file that I'm hoping Chalkey and 8bitrobo can run with their Arduino hooked up to a computer. It writes & reads the PIA control registers the same way that the original M6800 does in the 6th and 7th flash.
The code is at the same place (https://github.com/MrEkted/BallySternOS). This time, all you need is to download one file (MachineDiagnostics.ino).
Here are basic instructions to test the Arduino/MPU interface:
1) Download MachineDiagnostics.ino into a folder called MachineDiagnostics
2) Open this project in Arduino
3) Compile & Upload to board
4) Plug Arduino into a computer (115200 baud) to see messages as the board is exercised.
This program only writes to control registers. You might see a display flash if there are stray bits in a data register, but it should pass quickly.
Here's the expected output:
Start of program
Monitoring VMA signal, looking for presence of M6800 processor
Saw no sign of M6800 -- program will continue
Attempting to read & write from U10
Testing U10A Control Register
The U10A control register passed
Testing U10B Control Register
The U10B control register passed
Testing U11A Control Register
The U11A control register passed
Testing U11B Control Register
The U11B control register passed
Testing the clock cycle (if this hangs here, the conncection to clock is faulty)
It took 20984 microseconds for 10000 clock cycles
Clock frequency (very) approximately = 476 kHz
DIP Bank 0 = 0xE8
DIP Bank 1 = 0xC0
DIP Bank 2 = 0x9B
DIP Bank 3 = 0xA7
Starting interrupt tests - this is going to take 5 seconds to test
In 5 seconds, saw 600 U10B interrupts and 1634 U11A interrupts
Zero-crossing approx. 120.00 times a second
Display interrupt approx. 326.80 times a second
Interrupt tests done - if frequencies aren't approx 120 & 320, there's a problem with the interrupt line.
END OF TESTS
(waiting for reset)
(waiting for reset)
CousinPookie I did try the ATmega328P (Old Bootloader), but still didn't work. I guess you can get unlucky (I got it from Amazon) and got ones with no bootloader installed. Some people commented that you need another Arduino on hand with a bootloader installed to load it on to the Chinese one. Those were all I had so I thought screw it and got an original, and had no problems with the IDE software.
I did do the Sketch/Add and the latest sketch was at: Sketch uses 27174 bytes (88%) of program storage space. Maximum is 30720 bytes.
Global variables use 1333 bytes (65%) of dynamic memory, leaving 715 bytes for local variables. Maximum is 2048 bytes.
DickHamill I'll defiantly give the machine diagnostics a try this weekend. Funny if it was just a dip switch setting or something.
DickHamill Here are the results from MachineDiagnostics
Start of program
Monitoring VMA signal, looking for presence of M6800 processor
Saw no sign of M6800 -- program will continue
Attempting to read & write from U10
Testing U10A Control Register
The U10A control register passed
Testing U10B Control Register
The U10B control register passed
Testing U11A Control Register
The U11A control register passed
Testing U11B Control Register
The U11B control register passed
Testing the clock cycle (if this hangs here, the conncection to clock is faulty)
It took 19080 microseconds for 10000 clock cycles
Clock frequency (very) approximately = 524 kHz
DIP Bank 0 = 0xA2
DIP Bank 1 = 0xE2
DIP Bank 2 = 0xDF
DIP Bank 3 = 0x13
Starting interrupt tests - this is going to take 5 seconds to test
In 5 seconds, saw 602 U10B interrupts and 1490 U11A interrupts
Zero-crossing approx. 120.40 times a second
Display interrupt approx. 298.00 times a second
Interrupt tests done - if frequencies aren't approx 120 & 320, there's a problem with the interrupt line.
END OF TESTS
Quoted from 8bitrobo:dickhamill Here are the results from MachineDiagnostics
Start of program
Monitoring VMA signal, looking for presence of M6800 processor
Saw no sign of M6800 -- program will continue
Attempting to read & write from U10
Testing U10A Control Register
The U10A control register passed
Testing U10B Control Register
The U10B control register passed
Testing U11A Control Register
The U11A control register passed
Testing U11B Control Register
The U11B control register passed
Testing the clock cycle (if this hangs here, the conncection to clock is faulty)
It took 19080 microseconds for 10000 clock cycles
Clock frequency (very) approximately = 524 kHz
DIP Bank 0 = 0xA2
DIP Bank 1 = 0xE2
DIP Bank 2 = 0xDF
DIP Bank 3 = 0x13
Starting interrupt tests - this is going to take 5 seconds to test
In 5 seconds, saw 602 U10B interrupts and 1490 U11A interrupts
Zero-crossing approx. 120.40 times a second
Display interrupt approx. 298.00 times a second
Interrupt tests done - if frequencies aren't approx 120 & 320, there's a problem with the interrupt line.
END OF TESTS
8bitrobo
That is really unexpected. Your results show that the hardware is interfaced perfectly in terms of clock & interrupts.
Do the DIP switch values match what you have set on the physical switches?
I found a couple of variables that weren't initialized before the Interrupt was attached. There's a chance those could cause some random behavior.
I'm going to work on expanding MachineDiagnostics, but if you have a chance could you pull these files and verify whether my variable initialization update changes any of your symptoms?
BallySternOS.cpp
BallySternOS.h
SelfTestAndAudit.cpp
SelfTestAndAudit.h
Stars2020.ino
SternStarsDefinitions.h
Thank you!
Just tried the new code and it had the same final result, but it took longer to start the attract mode (or boot mode if that's what the fading lights up the playfield are) and it lasted about twice as long before starting the same behavior. Getting ready to try to run the diags, will update.
10:54:25.907 -> Start of program
10:54:25.907 -> Monitoring VMA signal, looking for presence of M6800 processor
10:54:28.920 -> Saw presence of M6800 processor -- program will halt
10:55:10.132 -> Start of program
10:55:10.132 -> Monitoring VMA signal, looking for presence of M6800 processor
10:55:13.114 -> Saw no sign of M6800 -- program will continue
10:55:13.114 -> Attempting to read & write from U10
10:55:13.114 -> Testing U10A Control Register
10:55:13.384 -> The U10A control register passed
10:55:13.384 -> Testing U10B Control Register
10:55:13.669 -> The U10B control register passed
10:55:13.669 -> Testing U11A Control Register
10:55:13.917 -> The U11A control register passed
10:55:13.917 -> Testing U11B Control Register
10:55:14.171 -> The U11B control register passed
10:55:14.171 -> Testing the clock cycle (if this hangs here, the conncection to clock is faulty)
10:55:14.218 -> It took 19308 microseconds for 10000 clock cycles
10:55:14.218 -> Clock frequency (very) approximately = 517 kHz
10:55:14.218 -> DIP Bank 0 = 0xAF
10:55:14.218 -> DIP Bank 1 = 0xFE
10:55:14.218 -> DIP Bank 2 = 0x1F
10:55:14.218 -> DIP Bank 3 = 0x1F
10:55:14.218 -> Starting interrupt tests - this is going to take 5 seconds to test
10:55:19.242 -> In 5 seconds, saw 602 U10B interrupts and 1706 U11A interrupts
10:55:19.242 -> Zero-crossing approx. 120.40 times a second
10:55:19.242 -> Display interrupt approx. 341.20 times a second
10:55:19.242 -> Interrupt tests done - if frequencies aren't approx 120 & 320, there's a problem with the interrupt line.
10:55:19.242 -> END OF TESTS
10:55:24.259 -> (waiting for reset)
10:55:29.245 -> (waiting for reset)
10:55:34.243 -> (waiting for reset)
I don't know why it said it saw a 6800 at the beginning but I hit the reset on the Arduino and it worked afterwards. Thanks so much for helping us to try to make this work!!
Quoted from CousinPookie:8bitrobo and anyone else using a chinese Arduino: You probably have to use the old bootloader. In the IDE go to Tools/Processor: ATmega328P (Old Bootloader). That had me stumped for days and was the biggest hindrance to me getting it done initially.
Also, are you going to Sketch/Add file and adding every file to the (sketch before uploading to the) Arduino?
Pookie I *think* mine is a legit Arduino, but it's an Uno. When I load the Stars2020.ino it has tabs that include the code for all the other files that are in the same folder so that should be it working, right? If they weren't in there it wouldn't compile due to missing references I don't think but you'd know better. I looked on my dropdown and there isn't an entry for the ATmega328P, but there is one for ATmega32U4. The Arduino seems to be taking the code the way it should from the perspective of the desktop program. Is it worth trying to run it with a different processor selected?
Chalkey I'm new to this as well. I was just passing along the things I figured out that tripped me up at first. The old bootloader thing is specifically for the Chinese Arduino Nano though. I hope you get yours figured out. I have a Mega that I haven't got working yet and it has the same pinouts as the Uno (and then some).
DickHamill I tried the lasted files. Powering on as about on second of nothing then the same of everything going off.
Something that is interesting. I just pulled the f4 rectifier board fuse that powers the coils and it is more "stable" I guess you could say. Powering on, the displays don't go crazy. Looks like the start of a game but pressing the credit button did nothing. The first time, credit display showed 01 00, now is 15 00 for some reason. Going trough the menu the numbers are stable and not changing fast. I cannot change any setting though. Putting the fuse back in goes back to crazy mode powering on
8bitrobo
Looking at the schematics, I'm seeing that pulling f4 also kills the zero-crossing input to the MPU, so everything done in that interrupt service routine will be ignored. That eliminates lamps, solenoids, and switches, just leaving displays. The self-test button is done through an interrupt, so it doesn't count as a switch.
But something that Chalkey said in another message also makes me suspect there is an issue with the zero-crossing interrupt being mis-detected, but both of you show perfect values in MachineDiagnostics.
This is a really weird issue. All the interrupt stuff is done in BallySternOS.cpp, and it has changed very little since the first time I published it. There has to be something in there though...
Is your zero crossing interrupt a 'fall through'? As in, test for display interrupt first, since it's the most often, then test for NMI (self test switch), then assume it was the zero cross, or are you specifically testing for the zero cross? What does your code do if it can't identify the correct interrupt? Original code reboots at that point.
I have a theory for 8bitrobo &
Chalkey about what's causing the instability. I'm not sure why the problem would occur, but this would give me a big clue.
In the Interrupt Service Routine, during the Zero-Crossing handler, the program looks for closed switches that require solenoid fires (e.g. sling shots and bumpers mostly, but also those 10 pt chime switches). The program uses an array of switches and their corresponding solenoids to be fired. If (somehow) the variable that describes the size of the array gets stomped, then the ISR would appear to go crazy, firing seemingly random solenoids for every perceived closed switch.
If the out-of-bounds array index was large enough, it would make the ISR take tons of time and even mess up the displays because they wouldn't be serviced fast enough.
To see if this theory holds water, could one of you make the following change:
In BallySternOS.cpp, right after the line:
void InterruptService2() {
Add these three lines:
NumGameSwitches = 0;
NumGamePrioritySwitches = 0;
GameSwitches = NULL;
Those lines will disable the automatic solenoid response. That will go a long way to helping me understand the behavior.
Thanks!
Quoted from DickHamill:Those lines will disable the automatic solenoid response.
FWIW, when I made a hybrid stern/wms OS a couple years ago I was worried about this exact issue regarding fast react solenoids being serviced in the interrupt - as in I dumped the code that does it in the zero cross and instead used the newly written switch handlers to fast react and fire directly instead. There aren't any issues with the reaction being slow since the switch code was modified to be faster reacting (actually modified to be able to accept individual switch timing, to allow you to tune what type of switch it is - for instance, troughs you don't want to react to right away as it rolls over the null positions)
Are you doing the timing for the solenoids in the interrupt and waiting around or just setting a timer and decrementing it until zero then turning off the solenoids or are you firing and waiting around in the interrupt?
slochar - At a high-level, my ISR does the following:
Test for self-test switch interrupt on U10AControl & 0x80 - if true, then push self-test switch to switch stack
Read U10A to reset interrupt
Read U11AControl and U10BControl
If U11AControl & 0x80, display next digit to 5 displays
Read U11A to reset interrupt
If U10BControl & 0x80,
Kill time reading the switches (also kill some time counting clock cycles while interrupts are enabled to allow displays to cut in if they want)
While the switches are read, if any demand immediate solenoid fires, push those to the solenoid stack
After the switches are read, fire the next solenoid on the stack. If solenoid stack is empty, turn off all solenoids.
Now that we've killed enough time for the SCRs to latch, send the lamp data
Read U10B to reset the interrupt
Quoted from DickHamill:While the switches are read, if any demand immediate solenoid fires, push those to the solenoid stack
After the switches are read, fire the next solenoid on the stack. If solenoid stack is empty, turn off all solenoids.
So you're hanging around in the interrupt while the solenoid stack clears? What are your timers for other parts of the code doing at this time, are they still advancing?
Quoted from slochar:So you're hanging around in the interrupt while the solenoid stack clears? What are your timers for other parts of the code doing at this time, are they still advancing?
No, not hanging around. One solenoid event is pulled from the stack for each pass through the Zero-Crossing interrupt. From my scope readings, I saw that a switch causes a solenoid to be energized and then that solenoid is held on for X zero-crossings, and then turned off as close to a zero crossing as possible. I think in Bally Theory of Pinball it says that this is done to reduce back EMF, and typically a solenoid is held for 3 crossings. In reality, when I measured, several solenoids (like drop target banks) are held for at least 5.
Back in my original post, I showed o-scope readings of the original code versus mine.
Anyway, this all works on a lot of machines, and even in the old version of the code. For some reason, when 8bitrobo and
Chalkey get the latest code, the solenoids seem to fire at random and it appears to me that the ISR is running far too long.
My suspicion (just a hunch) is that because of low resources (maybe?) the array of switches->solenoids is getting corrupted or the size of the array is getting stomped.
With the extra 3 lines mine had a few strong coil fires then pretty much stopped and it seemed to loop a 1/2 second or so of attract mode and would not start a game or anything. The previous versions kept firing coils so I got scared and shut it off so I don't know if it would have started any kind of game then.
This is frustrating -- I'm sorry for all the trouble you guys are going through, trying to get this working!
If either of you have the time, the only way I can think to narrow this down would be to pull a couple of different versions from May to see if we can pin down when everything went wrong.
The only files that work for me are from April 17. The changes on May 20 start the issues. I put the latest BallyStrenOS.h and .cpp in with the April 17
Stars2020.ino and had the usual issue. So it's definitely in the BallySternOS.
Quoted from 8bitrobo:The only files that work for me are from April 17. The changes on May 20 start the issues. I put the latest BallyStrenOS.h and .cpp in with the April 17
Stars2020.ino and had the usual issue. So it's definitely in the BallySternOS.
Thanks - that's good info!
8bitrobo - the significant change to BallySternOS.cpp on 5/20 was the addition of the float library to calculate the delays based on the clock speed.
If you still have your broken version of the 4/17 code (with the newer BallySternOS.cpp), would you mind running an experiment?
In BallySternOS.cpp, remove these lines:
int SwitchDelayNumLoops = 40;
int LampDelayNumLoops = 30;
And these lines:
// 80 us
SwitchDelayNumLoops = (int)(0.080f * (float)clockSpeedInKHz);
// 60 us
LampDelayNumLoops = (int)(0.060f * (float)clockSpeedInKHz);
And then find the 5 times that SwitchDelayNumLoops is used and replace it with 40.
Also the 1 time LampDelayNumLoops is used and replace it with 30.
DickHamill Good news, that was it! I just made those changes and using the latest code, and everything runs great. Now I can enjoy your hard work, thanks for the help.
Quoted from 8bitrobo:dickhamill Good news, that was it! I just made those changes and using the latest code, and everything runs great. Now I can enjoy your hard work, thanks for the help.
AWESOME!
I've been working with Chalkey all day over email and we got it all squared away. The latest code is on GitHub, and know I know never to trust the floating point library on an Arduino. It was unnecessary anyway--I should have just put the timing delays on a define in the first place.
Some issues. One is that sometimes it will ball-save even after the 16 seconds has expired. Also my game doesn't dim the Stars so its hard to tell Stars Goal 1 from 2. I run incandescent under the playfield as I have a stock lamp driver board.
Sherwood Park, AB
Has there been any experience with a Weebley or Altek board on the install are there any issues if we use these boards.
Quoted from pins4life33:Has there been any experience with a Weebley or Altek board on the install are there any issues if we use these boards.
As far as I know, nobody has tried it.
barakandl commented on it here:
https://pinside.com/pinball/forum/topic/stars-2020-new-code-for-stern-stars-1978/page/2#post-5661564
Quoted from 8bitrobo:Some issues. One is that sometimes it will ball-save even after the 16 seconds has expired. Also my game doesn't dim the Stars so its hard to tell Stars Goal 1 from 2. I run incandescent under the playfield as I have a stock lamp driver board.
If you could, a video of the ball save & non-dim lights would help greatly. Thanks!
Powering on the game the attract mod will be normal and the Stars Goals will be bright. After a game or two the attract mode will be dim and the phase 1 Stars Goal will not light. In phase 2 they will light normally, but sometimes randomly they will all turn off, then randomly come back on.
I let the ball save timer expire but it kicks the ball and stays on ball 1. I hit the pop bumper to trigger ball save, drain, and it finally moves on to ball 2. I feel like it does it on ball 1 more often but it has happened on ball 2.
I had music level at 0, 3 ball game, and skill shot only awards 25,000. Hope this helps.
Quoted from 8bitrobo:Powering on the game the attract mod will be normal and the Stars Goals will be bright. After a game or two the attract mode will be dim and the phase 1 Stars Goal will not light. In phase 2 they will light normally, but sometimes randomly they will all turn off, then randomly come back on.
I let the ball save timer expire but it kicks the ball and stays on ball 1. I hit the pop bumper to trigger ball save, drain, and it finally moves on to ball 2. I feel like it does it on ball 1 more often but it has happened on ball 2.
I had music level at 0, 3 ball game, and skill shot only awards 25,000. Hope this helps.
Cool - thanks for the video.
As far as the lights are concerned, I'm wondering if I undercut the lamp delay too much. Your board (according to MachineDiagnostics) is running 10% faster than mine and a couple of percent faster than Chalkey's, and my delay is done off the MPU clock. You remember that "LampDelayNumLoops" variable that you replaced with a "30" earlier? Could you try bumping that up to, say 35 just to see if that affects the lamps?
If you have the latest code, the line will be in BallySternOS.h:
#define BSOS_NUM_LAMP_LOOPS 30
(just change that to 35)
-or-
If you're still working with the BallySternOS.cpp that you modified, it would look like this (line 580):
for (waitCount=0; waitCount<30; waitCount++) WaitOneClockCycle();
(change the 30 to 35)
I'll have to rummage around about the ball save issue. Could be one of the settings you mentioned.
Quoted from DickHamill:The scrolling scores can be seen at this time:
Why not just divide the scores by 10? The rightmost score digit is always 0, isn't it? That way everything would always be on the screen and you would just know there's a 0 off to the right you can't see (or just deprecate all the scores by dividing by 10, that would work, too).
Quoted from mc8045:Keep getting this error when I go to verify the code for stars, any help would be appreciated.
Thanks[quoted image]
I found the problem I bought the Nano Every your parts link sent me to, The nano every isn't compatable with the code you wrote, need a standard nano or one of the nano knockoffs. 
Might want to check the amazon links just to make sure they are right?????
Spent a couple hours trying to figure out what was going wrong lol.
Promoted items from Pinside Marketplace and Pinside Shops!
Reply
Wanna join the discussion? Please sign in to reply to this topic.
Hey there! Welcome to Pinside!
Donate to PinsideGreat to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!
