Missing RAM Pins

Hey everyone,

As has been noted in sites around the web (and another forum post), this version of the Due is missing some pins for the onboard ethernet peripheral.

One thing it also seems to miss is a few external RAM pinouts.

So far, I can see the following:

  • PC2-PC9 (D0-D7) are fine; connected to pins 34-41
  • PC10-PC11 (D8-9) is NC
  • PC12-17 (D10-D15) are fine; connected to pins 51-46
  • PC21-26 (A0-A5) are connected to the arduino PWM lines 9-4 (which is fine, there are extra PWMS on other pins)
  • PC27 (A6) is NC
  • PC28 (A7) connected to PWM3
  • PC29 (A8) connected to PWM10
  • PC30 (A0) connected to RX-LED
  • PD0-3 (A10-13) connected to 25-28
  • PD4-5 (A14-15) connected to TX3,RX3
  • PD6 (A16) connected to pin 29
  • PD7 (A17) connected to pin 11
  • PD8 (A21) connected to pin 12
  • PD9 (A22) connected to pin 30

There are addressing pins up to 22, but A18, A19, and A20 seem to be multiplexed with the SPI0 signal lines. Nice one Atmel.

My questions on this are:

  1. Is my analysis wrong?
    and if no to 1), 2) Does the team intend to put out a new revision fixing these issues?
    and if yes to 2), 3) Is it possible to receive a time estimate on when?
  2. Has anyone encountered any other omissions regarding any other missing peripheral lines? Since the mega form factor provides ~80 pins and the SAM3X8E has 144 in its arduino package, I'm guessing that out of necessity a few other things were dropped.

I know nobody likes people asking when?! when!? but I am trying to decide if it is worth rolling our own arduino form factor board including these RAM pins (and the ethernet ones) wherever we can squeeze them into the existing eagle design.

Also, I have heard about and examined the SAM3X8E-EK board - this is also an alternative we are deciding whether or not to use. I'm not sure if this is the right place, but does anyone know if it would be compatible with the ADK?

Regards,

-B

I've just been looking at this and it seems the SMC interface is missing some critical pins.

You have correctly identified D8 and D9 as not having been connected, but actually this isn't too much of a problem as you can still use 8bit SRAM happily as it uses D0-D7 pins. But still, 16bit would have been nice.

Also NCS2 (PB24) is missing, meaning that we are limited to two banks of Ram, not 4 (well, you can get 3, but it means skipping a bank mid way through), though again, not a major problem, two is fine.

However...

A6 is missing, which is a critical omission.

A5 is there, however it is shorted with NRD, meaning that it is unusable as NRD is needed to read the SRAM.

Basically the omission and lack of foresight in shorting PA29 and PC26, mean that if we need contigious memory, the largest single block we can have is 64 BYTES of external RAM out of a possible 16MB. Bravo.
I suppose if you don't need contigious memory, you could design the program to organise its memory access into 65536 non-contigious blocks of 64 bytes, giving 4MB, but this would be a nightmare if you need large arrays.

I don't think this is the last revision of the due that we'll see. My guess is that something as tasty as in board Ethernet is too tasty to ignore, just like external memory banks. The critical issue here is backwards compatibility, ie the desire by the arduino team to maintain the mega form factor. IMO, it would have been better to start anew, with a square pcb format that better lends itself to lots of pin outs.

But I'm sure they have their reasons, it's their product, etc.

To be honest if they want to maintain the form factor, all they had to do is to do the same sort of thing as when they went from Uno to Mega... make the darn thing half an inch longer.

Hmm, who knows.

I wondered how long it would be before someone mentioned this.

I noticed A6 the other day but didn't look much further, mostly because without A6 you are screwed.

Not allowing external RAM is IMO a major omission.

I would also vote for a format that doesn't use 100% of the edge real estate for the backplane, there's hardly anywhere to put your own connectors.


Rob

I think the bigger problem is A5. With A6, its a pain, but you could always solder a thin wire to the chip and run that wire out to a pin header glued to the side of the communication header. It's not an ideal solution, but I have done this before only with the Mega1280 to get access to one of the Timer inputs.
With A5, there is no way around it. It is shorted out to the NRD pin which means, unless there is a way to disable the NRD pin, you can't actually use the SMC controller as two of its output signals would short out.

A6 is nc on PC27, so yes you could run a wire.

NRD is available on PA29 which they seem to be using for a CS for an SD card.

A5 is on PC26, which is a PWM or another SPI slave select, but as you say it's shorted to PA29(NRD). What possible reason could there be for that?

But these two pins aren't used for any other SMC function so as long as you disable both PC26 and PA29 from being used by other things it should be OK wouldn't it?

Either way it's obvious that external memory was not a priority in the design.


Rob

I thought the SMC uses both at once to access an SRAM chip. The NRD pin is connected to the SRAMs read enable pin, and A5 is an address pin. What if you need to read from address 16 for example. Read enable would be low (n meaning it is reversed logic), and A5 would be high. This would mean the SMC controller has essentially just shorted the chip out.
It isn't a simple case of always having A5 low either. What happens when you try and write to the SRAM. Read enable goes high, and again you will have just shorted the chip out.

Unless of course it is possible to set PC26 as an input when you are using the SMC. If that is the case then it won't be a problem. I haven't studied the datasheet in detail yet - I am waiting until I have a Due (which the arduino store hasn't shipped yet! :().

You're right, when using the SMC you need both PC26 and PA29 as they both have functions with the SMC.

As they are shorted together you are screwed.

set PC26 as an input when you are using the SMC.

Doesn't help I think, you'll lose A5 if you do that.

No I think the Due cannot use external memory, if so that's a major shortcoming IMO.

The connection of those two pins make no sense as far as I can see, it's just possible that the PCB doesn't actually do that and the schematic is wrong. I think Massimo said the other day that the MACB connector is not on the PCB, not just DNP but not even allowed for, and yet it's on the schematic. So one has to wonder about the accuracy of the schematic.

It's 2AM here but tomorrow I may grab the Eagle files and have a look at PC26 and PA29.


Rob

Unfortunately they are connected in the eagle file.

It would be possible to disconnect them as the trace joining the two is accessible on the bottom of the board, however you would still be left having to run a wire to bring the NRD pin out.

So really, unless you can set the A5 pin to be an input, and then use the external memory with structs which contain a maximum of 32bytes, and store those structs in the memory aligned at 128byte boundaries, then sadly the external memory capability is not possible.
That right there severely cripples the Due's capability and the number of possible uses for it.

Graynomad:
I would also vote for a format that doesn't use 100% of the edge real estate for the backplane, there's hardly anywhere to put your own connectors.

@Graynomad:
What do you mean by "100% of the edge for the backplane" -- the double-row header socket at the right edge? But if so, isn't that part of the standard Mega format -- and thus all corresponding shields, for those who want to use them?

What I'm saying is that there's no room left for connectors on my shield should I want to make one. For example maybe I want to make a shield with 4 or 8 serial ports all using DB(DE)-9 sockets. Where do I put them?

Granted that's hypothetical and nobody else is complaining :slight_smile:


Rob

With the Due you can put them at the USB connector end now that they have switched to uUSB :stuck_out_tongue:

now that they have switched to uUSB

At last. Yes you now have about 15% of the edge to use.


Rob

Use SMD pin headers on the side of the shield facing the Arduino board and use SMD DB9 sockets on the other side. E.g. Harting makes SMD DB9 headers.

True, if you use SMD connectors you have all the edge to work with as long as you're happy to have the board at the top of a stack.


Rob

I hate to bump a thread, but does the team have any comments on this? I do understand that mega compatibility > RAM/ethernet support, but for Arduino users who need the extra memory, is the only solution for the foreseeable future (6+ months) to either a) roll your own board or b) use the Atmel evaluation kit?

is the only solution

I think so. Officially, none of the Arduino platforms has ever supported add-on RAM (the add-on boards for the MEGA are all from third parties...)

Officially, none of the Arduino platforms has ever supported add-on RAM (the add-on boards for the MEGA are all from third parties...)

At least it was possible with the Mega, the Due doesn't bring out one of the address lines (A6?) so you're screwed.


Rob

So I've been looking into the SMC as well for an LCD and for what I can gather, since I don't use the ADDRESS pins for address, it seems I could still use the SMC to write to my LCD. It's using 8-bits. I do need ONE address line to tell it which memory internally to work with. Although I am not 100% sure. Still porting code from a Mega2560 project.