Go Down

Topic: PORTD on Due?! (Read 9019 times) previous topic - next topic

westfw

Quote
The part that's missing (IMNSHO) is a TODR that would 'toggle/flip' the nominated bit(s) of the port.
the SAMD (Zero/etc) has a "Toggle" register.

On Due, there is also "bit banding", just to complicate the decision process.  In theory, digitalRead() could be sped up slightly using bit-banding.

One of the things that slows down digitalWrite() on the ARMs is maintaining the "digitalWrite(pin, 1) on a pin configured for input, enables the internal pullup" behavior from the AVR.  On AVR, that was essentially a side effect of the implementation, "free" WRT implementation cost.   On the ARM GPIO peripherals, the pullups are controlled via a separate register, so there has to be a check in the digitalWrite() code path.  :-(

westfw

Quote
You're putting a 32kHz crystal on a Due board?
It already has one, according to the schematic.  My board is actually an Iteaduino Due, and it definitely has two crystals.


Quote
I could not imagine using an RTC without setting it to the real time, but I have a poor imagination.
Ah.  On the SAMD chips (Zero, but NOT Due), the "RTC" peripheral has several modes.  In addition to the clock/calendar mode, used with a slow clock input or crystal, there are also 16 and 32bit "counter" modes with configurable prescalers and "top" values that operate up to the full system clock speed.  Sort of a SysTick on steroids.  It's pretty easy to set it up to count microseconds (48MHz/3 GCLK, /16 RTC prescaler) and interrupt every millisecond ("top" = 999)

 I had assumed that the Due SAM3X was the same peripheral, but looking more closely I see that I was wrong...

TheRevva

the SAMD (Zero/etc) has a "Toggle" register.

On Due, there is also "bit banding", just to complicate the decision process.  In theory, digitalRead() could be sped up slightly using bit-banding.

One of the things that slows down digitalWrite() on the ARMs is maintaining the "digitalWrite(pin, 1) on a pin configured for input, enables the internal pullup" behavior from the AVR.  On AVR, that was essentially a side effect of the implementation, "free" WRT implementation cost.   On the ARM GPIO peripherals, the pullups are controlled via a separate register, so there has to be a check in the digitalWrite() code path.  :-(

the SAMD (Zero/etc) has a "Toggle" register.

On Due, there is also "bit banding", just to complicate the decision process.  In theory, digitalRead() could be sped up slightly using bit-banding.

One of the things that slows down digitalWrite() on the ARMs is maintaining the "digitalWrite(pin, 1) on a pin configured for input, enables the internal pullup" behavior from the AVR.  On AVR, that was essentially a side effect of the implementation, "free" WRT implementation cost.   On the ARM GPIO peripherals, the pullups are controlled via a separate register, so there has to be a check in the digitalWrite() code path.  :-(

Well dang, you're quite right about the toggle on the ZERO CPU (ATSAMD21G18)...  It's refreshing to know that Atmel could also see a use for it!
The bit banding of the SAM3X8E (i.e. in the Due) is 'above and beyond' my immediate needs.  I completely understand how it works, but I just haven't had a pressing need to actually USE it (yet)...  As I previously mentioned, I completely bypassed using the Arduino IDE and its corresponding libraries - I'm a sucker for getting right down to to raw metal...  Therefore, I've never been directly confronted by the slow speed of digitalWrite() et al.
Perhaps the ONLY minor gripe I've had in using Atmel processors comes when I need to set the data direction of a pin... In my mind, I think setting a register to '1' (which LOOKS like the 'I' of the word INPUT) should make a pin an input, and setting it to '0' (which LOOKS like the 'O' of the word OUTPUT) should make the pin an output...
Since that's my ONLY gripe, I consider myself VERY lucky indeed.

On an entirely unrelated note... (and probably WAY off topic)...  Does anyone here actually KNOW why Atmel has never released the 217 pin SAM3X8H chip other than with their SAM3X-EK evaluation kit?  It might sound weird, but I have an upcoming project that could actually USE a decent chunk of that additional I/O capability above and beyond that available on the 144pin SAM3X8E...

MrAl

It already has one, according to the schematic.  My board is actually an Iteaduino Due, and it definitely has two crystals.

Ah.  On the SAMD chips (Zero, but NOT Due), the "RTC" peripheral has several modes.  In addition to the clock/calendar mode, used with a slow clock input or crystal, there are also 16 and 32bit "counter" modes with configurable prescalers and "top" values that operate up to the full system clock speed.  Sort of a SysTick on steroids.  It's pretty easy to set it up to count microseconds (48MHz/3 GCLK, /16 RTC prescaler) and interrupt every millisecond ("top" = 999)

 I had assumed that the Due SAM3X was the same peripheral, but looking more closely I see that I was wrong...

Hello again,

So your board is different than the more typical Due?

I dont think i see a crystal on mine at all, just an oscillator package stamped 12MHz.  I'll have to look for a schematic i guess.

But cant the RTC work off of the main clock anyway?  That's what the data sheet seems to say.  I am not sure how to set it up yet though, but i guess we use the RTC library (ie RTC.h or whatever) ?
Im in the dark with this right now, still trying to get used to the fact that not everything in the world will run with only 3.3 volts instead of the usual 5v.  I have to invest in some logic translators :-)

Go Up