D21 faster or non-blocking IO access

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
ryanafleming
ryanafleming's picture
Level: Hangaround
Joined: Tue. Mar 12, 2013
Posts: 262 View posts
#1
Posted by ryanafleming: Thu. Nov 30, 2017 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi team,

 

I have been playing with the samd21j18 for a while now and can manage to get my IO's running at a maximum of 1MHz using CLR and SET, though this is really starting to slow me down. I am working with an LCD that has a 16 pin parallel connection that once all the bits are set, you clock a 17th pin. Running this and usb at the same time I start to get significant issues for slow data transfer rates and my LCD starting to slow down 10-100x on write cycles.

I am pretty sure the answer is no based on the searching I have done, but has anyone had any success or know anything about non-blocking IO writes, dma port transfers or simply a faster way to write to the IO's. the internal architecture means that a write using the internal i2c bus can be very slow and non-deterministic...which is a pain. Else I will probably end up trying to use an external parallel driver and double up on my sercom SPI module...though another run or two of prototypes is required :(

Currently using all 6 sercoms, bus doubling up is required...eghhhh

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs
Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 24975 View posts
Location: Melbourne,Australia
Posted by Kartman: Thu. Nov 30, 2017 - 11:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You’ve said a lot but not really described where the problem is. As far as i know, writing to the i/o is non blocking. How does your 16bit lcd interface relate to i2c?

If the 16bit interface is the problem, what have you done to quantify the issue? Have you looked at the assembler that is generated?

Last Edited: Thu. Nov 30, 2017 - 11:18 PM
Top
ryanafleming
ryanafleming's picture
Level: Hangaround
Joined: Tue. Mar 12, 2013
Posts: 262 View posts
Posted by ryanafleming: Wed. Dec 6, 2017 - 10:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry I have been away from this project for the last week :(

Goal: Run LCD at full speed with nothing slowing it down.

The problem is that if I issue a clear screen command to the lcd, it is a bit banged command that writes to each pixel at a time. The command takes 1.5s of iteratively going through each pixel to fully send the command. This command is blocking bit-banged, such that it doesn't service any other part of my app until it is completed, but it is not atomic, interrupts can still jump in.

When a usb device is not connected, everything works as describe above, 1.5s operation, however when a usb memory stick is plugged in, the lcd updates just as fast periodically, then at other times slows down significantly, such that the entire operation could take 10s.

The USB driver on the SAMD21 is operating as a host MSD. Naturally I would assume if to slow things down a little through interrupt operations, but not this much :(

 

The reason I ask if the operations were blocking was that if my chip was running at 48MHz, I would assume I could do roughly 48 ops between each bit bang, or potentially a lot more if required as USB does...

 

I guess I don't really know what is going on entirely when I do a PORTA.OUTSET or OUTCLR write. I have done the following test in the past that showed a maximum of 1MHz bit bang:

[code]

PORTA.OUTSET = (1<<2);

PORTA.OUTCLR = (1<<2);

[\code]

~code tagging is broken in my browser...adding/guessing them manually :(

I repeated this 1000 times manually and could see on my scope 1 MHz transitions. If it put them in a while(1) loop, this dropped down to ~700khz transitions...so I was a little confused as to how fast these commands actually do things. Perhaps I am supposed to do the set command and then have a "wait" trying to read back the state of the register until its done?

 

Have you played around with this at all?

 

Cheers,

Ryan.

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 24975 View posts
Location: Melbourne,Australia
Posted by Kartman: Thu. Dec 7, 2017 - 12:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There was a discussion here regarding how many clocks to do i/o.
http://www.avrfreaks.net/forum/sam-d10-pin-toggling-frequency?skey=port_iobus
http://community.atmel.com/forum/read-input-fast-atmel-cortex-m0-d11d10d09d21etc

If you look at the assembler generated by your code you should be able to get more insight into what is actually happening. The reality is that the i/o is not single cycle.

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 5197 View posts
Location: SF Bay area
Posted by westfw: Thu. Dec 7, 2017 - 04:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh.   My SAMD21 manual mentions that port indata and outdata (at least) on a fast single-cycle "IOBUS", and then essentially fails to ever mention IOBUS again.

The port pins are at a different location when accessed via IOBUS than when access via the normal peripheral bus.  0x60000000+offsets (which the address map in the datasheet says is "reserved."   The samd21xxxx.h files define PORT_IOBUS, but fail to actually use that to define any ports...

 

1Mhz sounds slow even for the normal bus access...  Are you sure you're running at 48MHz?  (I guess USB has to be running at that speed, but... the clock system is complicated!)

 

Top
ryanafleming
ryanafleming's picture
Level: Hangaround
Joined: Tue. Mar 12, 2013
Posts: 262 View posts
Posted by ryanafleming: Thu. Dec 7, 2017 - 04:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Standard PORTA.TGL runs only at that speed using the conventional 48mhz pll.

USB on the d21 runs at 96mhz from their dfll or the dpll...as you said. Complicated...

 

I'll have to check up the other bus though based on those links! This could be really promising!

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 5197 View posts
Location: SF Bay area
Posted by westfw: Thu. Dec 7, 2017 - 06:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Being the curious sort, I dug up my Sparkfun SAD21 breakout board (An Arduino M0 clone, runs at 48MHz), and put in approximately your pin-toggle code:

// PortGroup * p = &PORT->Group[0];    // Normal PORTA address
PortGroup *p= (PortGroup*)0x60000000;  // IOBUS High Speed access?
// the loop function runs over and over again forever
void loop() {
  while (1) {
    p->OUTSET.reg = (1 << 21);
    p->OUTCLR.reg = (1 << 21);
    p->OUTSET.reg = (1 << 21);
    p->OUTCLR.reg = (1 << 21);

       :

It gives me about 6Mhz using the standard Port address, and about 24MHz using the IOBUS address (!! Impressive !!)

 

I must conclude that either there is something wrong with your clock initialization (something running at 8MHz instead of 48MHz would give you 1MHz), or perhaps you forgot to turn on some optimization option and are getting really lousy code (the Arduino IDE uses "-Os")

 

On the plus side, that means if you figure out what is wrong, you have a lot of room for things to speed up for you!

 

 

Top
ryanafleming
ryanafleming's picture
Level: Hangaround
Joined: Tue. Mar 12, 2013
Posts: 262 View posts
Posted by ryanafleming: Sat. Dec 9, 2017 - 04:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of my other major concerns was the slew rate of my clock, but based on what that last forum post outputs were and your examinations, I would argue its more likely capacitance on my output than drive strength of the micro.

Top
aberle@achatesp...
aberle@achatespower.com's picture
Level: New Member
Joined: Tue. Mar 5, 2019
Posts: 12 View posts
Posted by aberle@achatesp...: Mon. Mar 18, 2019 - 06:08 PM (Reply to #7)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Question retracted 

Last Edited: Mon. Mar 18, 2019 - 09:16 PM
Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 24975 View posts
Location: Melbourne,Australia
Posted by Kartman: Mon. Mar 18, 2019 - 09:10 PM (Reply to #9)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stick to the one thread please!

Top