Arduino Due Obsolete?

[pjrc]

Star Otto may actually be coming soon.  At least this guy got one to make this video:

https://www.youtube.com/watch?v=68HeH4-xTMI

[mistergreen]

I knew Arduino would take advantage to the ESP8266.

[nitrof]

is the internet configuration on otto will be the same as it was for DUE, that the chip has ethernet bus but will nerver be enable.. ?

[ard_newbie]

There is a solution for ethernet availability :




and associated Library :

https://github.com/freetronics/EtherDue


Edit : And TAJUINO board, with ethernet pins broken out

[nitrof]

this version of DUE still use wiznet 5100... not using ethernet bus capability of the sam3x...

[ghlawrence2000]

So OTTO's exist, and they can run Blink, yippee!!!

G

[pjrc]

is the internet configuration on otto will be the same as it was for DUE, that the chip has ethernet bus but will nerver be enable.. ?

Good question.  I'm curious too.  I looked at the ST datasheet and the Star Otto schematic briefly.

Not sure if this is 100% correct, but here's what I see so far...

Code: [Select]


Signal  Possible Pins & Net Names
------  -------------------------
RXD0    PC4=AD9=Analog9
RXD1    PC5=AD3=Analog3
RXDV    PA7=AD7=Analog7
RXER    (looks like ST does not use this RMII signal?)
TX0     PB12=CAN2_TX=Digital54    PG13=USART6_CTS=Digital53
TX1     PB13=CAN2_RX=Digital52    PG14=USART6_TX=Digital51
TXEN    PB11=USART3_RX=Digital19  PG11=PIN24=Digital24
CLK     ?????? (I can't tell which pin the chip uses)


The important RMII signals all appear to go to shield-accessible pins.

But it's not clear to me which pin this chip uses for the 50 MHz RMII clock.  A quick search turned up this conversation which talks of using PA1 for the clock.  That is connected to digital pin 1, so at least it's available, but using the same pin as the very commonly used Serial pin would be a little unfortunate.

I couldn't find any mention of RXER.  Looks like ST might not use this RMII signal at all.  Maybe they just let in corrupted data and depend on the ethernet frame crc checks or TCP packet checksums reject it?

I didn't trace out where the MII signal go, with the assumption a shield would opt for fewer 50 Mbit/sec signals rather than more 25 Mbit/sec signals.

Also didn't bother looking for the MDIO signals.  The Arduino Ethernet library doesn't offer any APIs for PHY management (eg, is a cable actually attached, what speed is it using, etc) so it seems unlikely they'll get used.

[pjrc]

Another interesting question would be whether the USB is 480 Mbit/sec like Due, or only 12 Mbit/sec?  And if it really is 480, how much of that speed will really be usable from SerialUSB.read() and SerialUSB.write()?

ST's datasheet says:

USB 2.0 high-speed/full-speed device/host/OTG controller with dedicated DMA, on-chip full-speed PHY and ULPI

My guess is "and ULPI" means you need to add one of these chips to actually use more than 12 Mbit/sec.

The Star Otto schematic shows PA11 & PA12 assigned net names USB_OTG_FS_DM & USB_OTG_FS_DP on page 4, and they seem to go to the USB connector through zero ohm resistors on page 8.

[pjrc]

Wow, reading a bit more about this amazing chip.  So many features.  Looks like it actually has 2 USB ports, one capable of 12 Mbit and other other 480 Mbit.

Seems Arduino.org decided to use the 12 Mbit/sec port to the USB connector.

Looks like these 13 signals (and a ULPI chip) are needed to make use of the 480 Mbit/sec port.

Code: [Select]


OTG_HS_ULPI_DIR   PI11=PIN29
OTG_HS_ULPI_STP   PC0=SDNWE
OTG_HS_ULPI_DIR   PC2=AD8
OTG_HS_ULPI_NXT   PC3=SPI2_MOSI   PH4=I2C2_SCL
OTG_HS_ULPI_CK    PA5=DAC1
OTG_HS_ULPI_D0    PA3=AD4
OTG_HS_ULPI_D1    PB0=AD0
OTG_HS_ULPI_D2    PB1=AD1
OTG_HS_ULPI_D3    PB10=USART3_TX
OTG_HS_ULPI_D4    PB11=USART3_RX
OTG_HS_ULPI_D5    PB12=CAN2_TX
OTG_HS_ULPI_D6    PB13=CAN2_RX
OTG_HS_ULPI_D7    PB5=PWM11/SPI1_MOSI


The PC0 pin looks like a conflict.  They connected this to the SDRAM chip.  It's a shame they didn't use PH5 for the SDRAM and make PC0 available to shields.

[nitrof]

Hum. yes that's a shame.

I always found it curious when designer put deliberate hardware conflict when other pin are actually available.
I wish the data sheet still not be completely updated, or revised design...

[pjrc]

Maybe they were focusing on making all the CAN bus and serial signals available?

It's also quite possible I'm mistaken about these pin assignments.  This chip has a ton of features and I've really only spent about an hour looking through it's massive datasheet.