Show Posts
Pages: [1] 2
1  Products / Arduino Due / Re: Floating pins? (RESOLVED) on: March 18, 2013, 01:09:17 pm
Well, that's a good point.  A sketch that does 2 things; define pin 5 as INPUT_PULLUP and pin 13 as OUTPUT, and loop() just outputs state of pin 5.  Classic "Button" example.

... 3 hours later...

Okay, I found the issue.  I was reusing MYPIN_5 (and others) based on some overlooked pragmas which were setting those pins LOW again.  Totally my bad.  I also got a chance to rewrite my serial protocol, which is nice.

The answer for any one else coming through this thread is:

Yes, the Due supports pullup resistors using pinMode(pin, INPUT_PULLUP);

If it's not working, chances are somewhere else you've re-set the pin to LOW.  Thanks for your help.  I ended up using the example Button sketch to confirm that it was my code, and that uint8_t isn't the problem, and that an array of uint8_t constants as pin numbers works fine as well.  At that point it was just a matter of commenting out most of my sketch to only execute the switch handling section.

(there was a moment that I thought I was perhaps using a Serial-dedicated Pin (not 0, or 1*) and didn't know it.  My Max32 crowbars if you Serial.Read while using DSPI so it's not unheard of.  But no, I am able to use all 52 pins I have dedicated to INPUT_PULLUP [not 100% tested yet])

*As far as I know you can't use pin 0 and pin 1 if you're using Serial as well.

Thanks again Grumpy_Mike and Lefty
2  Products / Arduino Due / Re: Floating pins? on: March 18, 2013, 09:47:13 am
I don't think it's so much a matter of being deprecated, but rather the vast difference between AVR chips and ARM chips. I have no acquired knowledge of how one enables internal pullups for input pins of the Due board but I would be very surprised if the old way (setting pin to input mode and then writing a HIGH to the pin) used on AVR based boards would work for the Due?


Yeah.  I haven't tried this code on my Mega yet, but this might be a Due-only issue.  I would be surprised to find this to be true, since there's no record of it that I can see.  It's also why I posted it here in the Due forum instead of in a more circuitry related forum. 

Lefty, do you have a Due you can test this out on?
3  Products / Arduino Due / Re: Floating pins? on: March 18, 2013, 09:40:09 am
I've read the sticky.  There's really no sense in posting the entire application here: it's a hundred lines or so across 5 .INOs.  I'll pull out the relevant stuff:

I use all caps for constants.  The BUTTONS array is defined as such:
const uint8_t BUTTONS[] = {

PI_XXXX is another constant defined in the Pins.ino like so:

#if DUE
const uint8_t PI_OUTH     = MYPIN_48; // Outhole                     1.1
const uint8_t PI_TROR     = MYPIN_47; // Right Trough                1.2
const uint8_t PI_TROMR    = MYPIN_46; // Middle Right Trough         1.4
// and on and on...

MYPIN_XX is defined as a uint8_t as well with a specific number like
const uint8_t     MYPIN_48      =     48;

Let's be a little kinder about marking 'style' points, okay?

My conclusion about them floating is because they are floating.  Any static interference near the pin changes its value.  Floating.  Wiring the same firmware up to a physical, external pullup resistor fixes the problem.  Some pins float (5, 3, 2) and some don't (13, 8, 9, 10).
4  Products / Arduino Due / Re: Floating pins? on: March 18, 2013, 09:09:05 am
Yes, I meant INPUT.  But I didn't realize that the code I had was deprecated.  I swapped it out and it made no difference anyway.  I'm still stuck with floating pins.
5  Products / Arduino Due / Floating pins? on: March 17, 2013, 08:23:14 pm
I'm having an issue that I'm sure is just a problem with my understanding of Arduinos.  I have a Due and I need to use almost all of the pins.  I'm setting the pins as output and then calling digitalwrite(pin, high) on them like this:

//BUTTONS = an array of uint8_t
    for(uint8_t index = 0; index < NUMBUTTONS; index++)
        pinMode(BUTTONS[index], INPUT); //this sets the pin to input mode
        digitalWrite(BUTTONS[index], HIGH); //this turns on the resistor

What I'm finding is that pins 13, 12, 8, 9, and others work great as expected, but pins 5, 2, 17... are floating.

Am I missing something?
6  Products / Arduino Due / Re: Maximum Pin Usage on Due (any duplicate/dedicated pins?) on: January 25, 2013, 03:30:50 pm
I realize now that I might not be making a lot of sense.  reading the arduino reference it seems pretty clear (now) that there is only one SPI in the Due, and it is located on the dedicated SPI pins.

I _think_ that pins 13 and 11 are for older Arduinos or for Software SPI (SoftSPI?) that are really just bit-banging?  I might be wrong there, but I think, at least, that SPI is it's own set of pins (going to ignore the ICSP header and MOSI2 for now) and there is no conflict with the outer pins.

So how about those other weird pins?  CANRX/TX, DAC0/1, SCL1/SDA1?  Can those be used for Digital IO?
7  Products / Arduino Due / Re: Maximum Pin Usage on Due (any duplicate/dedicated pins?) on: January 25, 2013, 03:16:23 pm
Thanks, I'm not that hard up for pins.  And that looks a little outside of my comfort zone.  I'm having a hard time understanding the pins that ARE available, let alone creating new ones.

What I'm really confused about is that with the Mega, SPI is pins 11 and 13.  And as far as I know there's only one.

Now with the Due, I've got dedicated SPI pins.  But every sample code and library is using 11 and 13.  And there's also pins 4 and 52?  But is there still only one SPI?  My Max32 has 4 SPI definitions, so it's confusing me.

Then there's also MOSI2 in the Due pin diagram, which is on the ICSP header.  what is that?

I don't want to utilize weird pins.  I want to know if I can use physical pins 0~53, A0~A11, DAC0-1, CANRX, CANTX, SCL1 and SDA1 without overlap.

And additionally, if I use USB Serial (just defined as Serial.begin), and SPI (just defined as SPI.begin) will that consume any of these physical pins?
8  Products / Arduino Due / Re: Maximum Pin Usage on Due (any duplicate/dedicated pins?) on: January 25, 2013, 02:30:30 pm

That's interesting.  Do you have any sample code or documentation for that?  Google comes up blank.  Again, sorry if that's obvious but I can't find anything on it.
9  Products / Arduino Due / Re: Maximum Pin Usage on Due (any duplicate/dedicated pins?) on: January 25, 2013, 11:54:45 am
Awesome, thanks for the reply.  I hope you're right.

About the dedicated SPI pins... is that SPI0, SPI1?  All of the example code uses the typical SPI static class and refers to 13 and 11 as MOSI and SCLK.

If I use the middle MOSI and SCLK (all I need for my w2801s), can I use 13 and 11 (or 9 and 50 for that matter) for DIO?

Thanks again for trying to help.
10  Products / Arduino Due / Maximum Pin Usage on Due (any duplicate/dedicated pins?) on: January 24, 2013, 07:16:21 pm
I would like to use the most pins possible on my Due.  I have read in a few places that some pins are duplicates?

I cannot read a pin schematic and make heads or tales of it.  It says that D10 = D77 and D4 = D87... are those duplicates in the CODE, or on the physical board?

anyway, I'm using Serial over USB.  

My question in the most clear way I can put it:
Looking at the board, which physical pins can I use as Digital IO and which ones are duplicates or unavailable because of Serial.  I think 0 and 1 are used for serial?

Followup:  What about if I (additionally) use the dedicated SPI pins in the middle (for SPI)?  What pins are those duplicates of?

Thanks and sorry if this is obvious to some of you.  I honestly can't read that schematic and I've been looking at it since November, way before I got the Due.
11  Development / Other Hardware Development / Re: Chipkit Max32 DSPI and Serial fix? on: January 17, 2013, 10:45:36 am
Thanks, Jeremy.

For others out there, it says my account is not yet activated.  When I ask to activate it, it does nothing.

While that is an issue, if either you or Jacob have any knowledge on how to make DSPI and Serial work with the Max32, I'd love to hear it.

12  Development / Suggestions for the Arduino Project / SPI.transfer(int count, *byte); //instead of SPI_CONTINUE on: January 15, 2013, 04:00:37 pm
I really can't understand the logic behind the method signature of the new 'extended spi' functionality in the Due.

There are really 3 issues I can't get along with:

1) I don't think forcing the CS pin as a parameter is good practice for standardization and will make libraries from 3rd parties even harder and more fractured than they are today.  I understand why it is there, but it would be better to use an instance of SPI (like SPI0, SPI1, SPI2).
SPI.transfer(4, myByte); // 4, or 10, or 52???

2) SPI_CONTINUE makes sense when you have exactly 3 items to send.  Any less and you don't need it, any more and it looks ridiculous to write out.  However, when you have n items to send, like an array of led values you'll have to loop with an extra funny line like this:

for (i=0; i < numLeds -1 ; i++) //less than AND -1???
    SPI.transfer(4, pixel[i], SPI_CONTINUE);
SPI.transfer(4,pixel[i]); //this extra line looks out of place because it is.

3) Why isn't there a single call to SPI to send an array?
SPI.transfer(int count, *byte); //instead of SPI_CONTINUE

I know the answer to all of this: write a helper library and shut up.  But I am still a very beginner with microprocessor coding and all of this is very hard for even me to understand... Which pin is CS, SK, MISO, MOSI, SPI, DSPI, etc.  I am imagining the others that are/will be left behind with this trying to figure out why this simple adafruit code doesn't work for their awesome Due.

The only thing (so far) I like about the Max32 is this DSPI interface.  It is very straight forward:

*) DSPI is broken up into 4 objects for each of the DSPI pins: DSPI0, DSPI1, DSPI2, DSPI3 (not static)
*) you set the actual speed you want in Hz, not some arbitrary clock scaler
*) send an entire array with spi.transfer(count, pointer);
*) send spi data asynchronously without having to figure out interrupts (which by themselves are a total nightmare, completely undocumented in almost every board I know of and even if it is, it's written so only master ECEs can understand it)

Anyway, I know this might put a few people off.  My concerns are simple and I think can be unilaterally understood:  Beginners will have some issues with this SPI usage AND advanced users who write libraries for beginners will have some issues utilizing this api cleanly.

unless I'm missing something.
13  Development / Other Hardware Development / Re: Chipkit Max32 DSPI and Serial fix? on: January 14, 2013, 12:47:04 pm
Yes!  Absolutely!  (excitement at someone helping, not anger).  Thank you!

I tried another approach siting a few other posts that said if you use DSPI0 (instead of DSPI1) it should work, but that is not true.  It took me a while to locate the right pins (anyone have a pin-layout diagram nearly half as good as the Due?) but once I did I received the same error.

It's really quite simple to reproduce.  Just use DSPI and  I figured I might try switching to regular SPI, but I don't know if that would actually solve anything.  Just something to try.

I was also pretty close to giving up and try using my Due.  They can't both be messed up.

Oh, and I tried again to log in to Chipkit's forum with no success.  My email stating the issue to Digilent has gone unanswered for over a week now.

Thanks again for trying to help.
14  Development / Other Hardware Development / Re: Chipkit Max32 DSPI and Serial fix? on: January 08, 2013, 11:25:51 am
hrm.  thats weird.  I was expecting you to have fewer stars.

This is the "Other Hardware Development" section of the forum.  Specifically:
"Shields you are designing or that you think would be nice to have, Arduino compatible platforms, board comparisons, etc. "

Chipkit Max32 is an Arduino compatible platform.

Hey, but thanks for helping the conversation move forward.
15  Development / Other Hardware Development / Chipkit Max32 DSPI and Serial fix? on: January 08, 2013, 09:26:35 am
The Chipkit forum is broken (I can't get the confirmation email for registration) and I haven't had any luck emailing digilent directly so here I am.

There is a known issue posted all over their forum about how if you enable DSPI and try to read a single byte in Serial the board crashes because of some interrupt pin sharing issue.  The issue has been known since at least June of 2011.  Here is the latest post I can find about the error:

There are all sorts of hacks people tried without saying what specifically worked for them with regards to their setup (DSPI0, 1, Serial1, 2, etc).  I've tried doing a few things but have gotten nowhere.

Does anyone out there have a work around for this that I can follow?  I would like DSPI0 (default J13 pins) and USB serial to work together.  I am not using interrupt driven SPI, btw, just spi.transfer();


Pages: [1] 2