Pages: [1]   Go Down
Author Topic: Ethernet Shield on Due - is it possible to avoid using PWM pins?  (Read 931 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I am wanting to use the standard official ethernet shield with a Due. The shield appears to use pins 10-13 for its own purposes (part of the SPI link, I guess), which unfortunately means that it consumes 4 of the PWM outputs on the Due. Now, seeing as the shield was designed for the Uno, and on the Uno only two of pins 10-13 are PWM (10 and 11), clearly the SPI link does not require all four pins to be PWM enabled.

Ideally I'd like to use all 12 PWM outputs on the Due for my own purposes. Is there any way of avoiding using pins 10-13?

On the Ethernet Shield page, it says:

Quote
Arduino communicates with both the W5100 and SD card using the SPI bus (through the ICSP header). This is on digital pins 11, 12, and 13 on the Duemilanove and pins 50, 51, and 52 on the Mega. On both boards, pin 10 is used to select the W5100 and pin 4 for the SD card. These pins cannot be used for general i/o.
This is curious because the ethernet shield already uses the SPI pins via the 6-way header on the bottom of the board. Does it also need to use the extra four pins on the digital I/O rail?

Basically, I'd like to know: is it possible to create an ethernet connection with the Due and still use all 12 PWM outputs?

If there's a way I can use the two DACs for the ethernet shield instead of the PWM outputs, that would work too.

Thanks a lot!
Logged

Offline Offline
God Member
*****
Karma: 8
Posts: 550
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi, I'm not an expert about Due.
I've seen here http://arduino.cc/en/Hacking/PinMappingSAM3X that pins of ICSP header are not connected with other pins, so you shouldn't have problem if you try to use all PWM pins.(if the shield is designed correctly).

Probably you should modify your shield in order to remap pins 10 and 4 above other pins(on these connection there is a low frequency,so you won't have problem)..after you'll modify library and you'll change references to these pins.

are you sure what you won't have any trouble with voltages?
« Last Edit: August 09, 2013, 03:27:33 pm by m_ri » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks, I'll give that a go.

I believe the official Arduino ethernet shield is fully compatible with the Due, so I doubt there will be trouble with voltages. Besides, I've already managed to get it to work, so unless there is an issue over longer timescales, I believe it's fine.

Can you remap the SS (slave select) pins (10 and 4) onto other ones (e.g. one of the many digital I/O pins)? I read on the Due Extended SPI page:
Quote
The extended API can use pins 4, 10, and 52 for CS.
I guess CS means chip select, which is another name for slave select. If that's to be believed, then I can only use pin 52 if I want to avoid wasting a PWM pin. What do you think?
Logged

Offline Offline
God Member
*****
Karma: 8
Posts: 550
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

If you want to use the extended spi, you could have some problem.
I understood that you'll use normal features. In this case, maybe you should modify a bit around the library, but i don't think if you don't need high speed , bandwidth and accuracy. You should use the lowest speed between all connected SPI devices.
You'll write SPI.begin(52);  SPI.setClockDivider(52, YOUR_SPEED); in the setup, and you'll also initialise pins for Slave Select(e.g. 50 and 51)
you'll connect nothing to pin 52..you can use, for instance, pin 50 and 51 as slave select.

when you want read/write something on SPI bus, you must change status of BOTH pins(50-51) and after you write, for example, SPI.transfer(52, 0×00);
maybe you'll must modify libraries which use SPI,in order to set correctly SS pins before any transfer.

In this way, the SPI interface believe that there is only a device connected.

The code will be similar to SPI code written for arduino uno/mega
« Last Edit: August 11, 2013, 12:45:45 pm by m_ri » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Ok, this is really bizarre. I connected the ethernet shield via wires instead of plugging it in to the Due. I mapped the 6 SPI pins on the bottom of the board to the SPI header on the Due, and connected pin 10 on the shield to pin 10 on the Due (the slave select pin, SS). The Ethernet library worked, with the device successfully replying to HTTP codes etc. However, when I tried to output a PWM signal on pins 6-10, the web server stopped responding. Pins 2-5 and 11-13 worked fine.

Why is this happening? The ethernet library clearly doesn't need any of the PWM pins to work, as it does work without them (except the slave select pin, but on the Due this can be remapped to pin 52). Could it be that the ethernet library, which is designed for the Uno board, is still trying to send SPI signals in the same way as the Uno, via the digital outputs? If so, does anyone have any idea how to stop this from happening, as it's unnecessary and it's using five PWM outputs unnecessarily?

Even more bizarrely is that it's pins 6-10 that aren't working. I would have expected pins 10-13 to not work as this is what the Uno board uses for SPI.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 12
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've found out the issue. The PWM outputs on the Due are only 8-bit, but you can write 12-bit values to analogWrite() for the purposes of future-proofing the code. For some reason, you can use 12-bit values on pins 2-5 and 11-13, but not 6-9, when you're using the Ethernet shield. Very weird.

Anyway, if you want to avoid any issues with the PWM outputs when using the Ethernet shield, just make sure you use 8-bit values with analogWrite() and not 12-bit values.
Logged

Offline Offline
God Member
*****
Karma: 8
Posts: 550
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It's interesting..The best thing is to report this bug, because this is a really strange and unexpected behaviour.
Logged

Pages: [1]   Go Up
Jump to: