Not sure if anyone will be interested in this or not.
But a little while ago, I finally got my hands on an Arduino Due. And I thought I would now use it as an interruption to my other interruptions…
Awhile ago, I did some modifications of my Arduino Mega shield and had a few boards fabricated. The main differences from my other versions is that I now use the IOREF pin of the mega board. For earlier versions of the Mega boards I also provided myself with a jumper to it with +5v. I then routed this voltage to the IO pins instead of +5v. This was all because the Arduino runs at 3.3v and is not 5v tolerant. So yesterday I soldered up one of these boards with the parts I have. (I am missing a 3.3v regulator and a couple of switches) and I am starting to test this board out. Probably won’t try XBee until I have the regulator, although I might be able to get away with jumpering from 3.3 from the main board…
So far the LEDS and speaker work. Not sure about the button yet. There have been a few issues with things not implemented yet, that I am working around.
Edit: Current thing I am running into is differences on how things like digitalRead work, especially if for example an IO pin is configured for output. Example: This code works on Arduinos like Botboarduino but does not appear to work on Arduino UNO.
digitalWrite(13, !digitalRead(13));
Back to figure out what does…
Soon I may try one of these to run the Phoenix code. I already know that I will need to make changes to PS2_X library. If I connect to SSC-32, may need to do something to handle the signal coming back from SSC-32.
Thanks. It is challenge at times to my soldering skills But as a shield, it is a bit easier than trying to solder real small things like processors.
Me too!
Right now just trying to get simple things working, like: digitalWrite(13, !digitalRead(13));
Works great on Arduinos to toggle an IO port, in this case the standard LED. This also works on Pic32s(chipkit UNO or Max32). But does not work on DUE. Actually my simple reading the button does not work yet… I have verified with Logic Analyzer, that when I press the button, the signal is pulled low (there is a PU on button). But my code (digitalRead) is not detecting this…
Yesterday I hacked up the PS2 library, to make it compile on the DUE, but so far my receivers are not working. I tried hooking up one of the newer receivers that Jim sent me, when they first discovered issues with 5Vs, but the LEDs don’t light up when I send through the 3.x voltage that is coming from the DUE IOREF line. Does light up if I give it 5V, but don’t want to have it give me back 5V… May need to get a level shifter…
As for running servos. Yes will try that. Note: I do have a version of the code that runs on Arduino Megas that the Mega can driver the servos. Again the code is up on:
(github.com/KurtE/Arduino_Phoenix_Parts). This is using my ServoEx library, where I put in the SSC-32 timed move capabilities into the Servo library. It does work, but is susceptible to jitters, if any code does something like Use interrupts, disable interrupts… So far I don’t think there is a released Servo library for the DUE, but looks like there is a test version you can download from the forums… So we will see.
Once in awhile I think it would be great if there was a shield for megas that had more hardware support for Servos, like the SSC-32 has, but I would still want an IO pin backing each Servo to allow for feedback.
But did a bit more yesterday… Found a bug in my shield
I properly split out the stuff that needed to be run off of the IOREF voltage. I also put a Jumper in that could connect +5v to the IOREF input pin for those boards that don’t have this pin. The problem was I forgot to rename that circuit to what I wanted, so it was not connected up with the first part. Which implied that the pins that were to get IOREF were sort-of floating. So I put in a manual jumper and now my PS2 code appears to be working with the 3.3v version of the PS2 without an IO shifter. So I uploaded my changes to the PS2 code to make it work on DUE up to my github branch…
Still trying to figure out why the buttons are not working… I have verified that without the button pressed, I am getting 3.3v to the IO line (back to the header going to the main board). When I press the button the voltage goes down to 0, but this is not detected on the DUE? I thought maybe the Arduino Header was not making contact, so I had an output test where I set this IO pin to output and was able to change the IO pin from high to low… Also without shield was able to use the basic example DigitalReadSerial (change the IO pin in this simple example) and jumper the IO pin to +5v or 0v and it properly read 1 or 0… So I am confused. Will work more on this on Arduino DUE forum. Wondering if maybe leds on other IO pins of the same IO port is confusing it?
Hi Kurt, I’m also interested in your work on the DUE (I’ve one on my desk too). I’ve read that some people has critized the board design since there are no buffer/drivers on the I/O lines. You can’t draw much current from them. Not sure if that affect your findings?
I figure I am probably missing something obvious. I was at first wondering if maybe there is an issue with the same IO port being used for input and output as the LEDS and buttons are on the same one. But pretty sure that is not it, as the PS2 is working on IO pins 46-49, with DAT line on same IO port as the buttons and that works… Maybe I should try using an unpopulated version of my board and connect up the buttons and see if they work, then try adding other stuff…
Yep, Thanks! Have not used all of the capabilities yet, but it is nice to be able to see lots of IO pins…
Got email yesterday, that my new shields were shipped yesterday So hopefully soon, I can start soldering a new version for the Due…
This version has the level shifter chip hooked up to all 4 of my USART 3 pin connectors, so it will now be safe to connect it to an SSC-32 and now worry about 5v’s coming back… Also using this shield on the Arduino Mega, the same chip takes care of the voltage conversion for the XBee…
Been playing around with new shield. I HATE trying to solder those tssop-20 components. I know I screwed it up some, and my Connection to USB would not work, so used sledge hammer approach and cut off my extended header pins for d0/1, now that works. The more expensive headers work good. Once I got them properly aligned and soldered in, the pins do not move and makes easy to plug the shield in. And this time it looks like all of the pins are making contact. Today also verified that the xbee connection appears to be working.
I just found this thread and started following along, since I also plan to work with the Arduino Due, in preparation for moving from there to an UDOO at some point. Other than aquiring two teensy3.1 boards for work with micropython, I have much I can do with my existing set of platforms. I will replace my BeagleBone Black at some point though (leaning towards replacement versus troubleshooting).
Truth be told, I am finding it quite a lot of fun to do “bare bones” programming again. I have my Raspberry Pi boards when I want to do something with embedded Linux, test a port of an Arduino library, etc. I have the Arduino Mega ADK on W.A.L.T.E.R. right now, and am enjoying working with that also, although I wouldn’t be enjoying it as much without the DFRobots Sensor Shield. I also love working with my Arduino Decimila (must get an Uno and Leonardo at some point) and BotBoarduino.
It has been awhile since I played with these shields. I went through a couple of generations of it, and if I was serious would probably go through another… The main difference between the last version and the one I was using, was to try to do some stuff to handle the 3.3v and 5v differences.
I have tried out versions of the shield on the Arduino Mega (1st generation, don’t have any of the 2560 or ADK), Chipkit Max32 and the Due.
I still have the schematics and the like for it. Also have some unpopuplated boards. If I remember correctly I was playing with some level shifters on the board and I was having difficulties soldering those little pins.
Yep it is fun at times to play with different levels of boards. The linux boards are great, but takes a lot of time and unless you are a linux kernel guru you are never fully understanding what all it is doing. I recently also worked with the Sparkfun Atmega32u4 breakout board as well as XevelLabs USB2AX (Atmega32u2), that is setup to specifically plug into USB port of PC or Linux box and handle Dynamixel Servos. In my version, I extended the code base by Xevel and added the code to do some of the Servo Interpolation work instead of having the main processor do it. It is a lot of fun.
So far I have not been doing anything recently with the Due. My main issues back then were with trying to do 3.3v to 5v conversion on some of the pins… Lately been off on other tangents, like Linux boxes and currently having fun with the Teensy.
Can always post up here a zip file, with gerbers and the like also with the diptrace design documents. Then anyone can send them off to their favorite fabricators and start soldering all of the parts.
But as a shield, it is a bit easier than trying to solder real small things like processors.
I didn’t know about that one. Looks great, congrats! 100 MHz sample rate for 2 channels sounds interesting, also all 16 channel reading can be useful.