Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Pin 4 can't be used at a high speed?


  • Please log in to reply
19 replies to this topic

#1 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 14 May 2011 - 04:03 PM

I've been playing a bit with some stuff and wanted to use pin 4 as chip select pin for an SPI bus. It failed. All pins seems to operate as chip select pin, except for pin 4. Is there a reason for it?

If I look at the specs pin 4 is the only pin that doesn't have managed support for a protocol, but for a chip select pin that shouldn't be a problem I suppose?
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 May 2011 - 04:21 PM

Hi Stefan, Digital pin 4 is the "hardwired" chip select pin for the SPI bus. Microsoft included special handling for it in the SAM7X board support package, to special-case it. We're using digital pin 4 as CS in an internal application--but perhaps we're using it differently. Do you have a repro case we could test to help identify the issue you're having? Thank you, Chris

#3 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 14 May 2011 - 05:31 PM

namespace NetduinoApplication1
{
    public class Program
    {
        public static void Main()
        {
            SPI.Configuration Config = new SPI.Configuration(
                Pins.GPIO_PIN_D4,
                false,
                0,
                0,
                true,
                false,
                1000,
                SPI_Devices.SPI1
            );

            SPI Leds = new SPI(Config);

            byte[] WriteBuffer = new byte[1];
            while (true)
            {
                WriteBuffer[0] = 1; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
                WriteBuffer[0] = 2; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
                WriteBuffer[0] = 4; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
                WriteBuffer[0] = 8; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
                WriteBuffer[0] = 16; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
                WriteBuffer[0] = 32; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
                WriteBuffer[0] = 64; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
                WriteBuffer[0] = 128; Leds.Write(WriteBuffer);
                Thread.Sleep(100);
            }
        }

    }
}

I connected 8 leds with a 74HC595 to the Netduino like this:

Posted Image

If I change pin 4 to any other (both in code and in the schematic) it works, but on pin 4, nada.


By the way, the above code and schematic is only a simple thing to reproduce which I built in 5 minutes, the problem occured in a bigger project I am working on, but that code was too big and too much overhead ;)
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#4 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 14 May 2011 - 05:50 PM

Within this year, we might buy the brand new book of Stefan: "Netduino and 74HC595 Unleashed". Consider me for a copy. Cheers PS: Consider also 8 girls "available", then using SCK to shift from one to another...blaaah!...My wife would kill me!
Biggest fault of Netduino? It runs by electricity.

#5 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 14 May 2011 - 05:53 PM

Within this year, we might buy the brand new book of Stefan: "Netduino and 74HC595 Unleashed".

Hahaha it's just a versatile IC, I'm not using it to -really- multiplex in this project, but it's still a nice sample ;)
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 May 2011 - 09:51 PM

Thanks, Stefan. That's a great repro; thank you. We'll run the code with a logic analyzer and see what's being output. Hopefully it's an easy fix... Chris

#7 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 17 May 2011 - 01:49 PM

Hi Chris, Did you manage to reproduce it? I guess you're working hard and are quite busy :D
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 May 2011 - 01:57 PM

Hi Stefan,

Did you manage to reproduce it? I guess you're working hard and are quite busy :D

There are a few other issues we're working on for 4.1.1 beta 2 (and are also preparing for MakerFaire)--so this may take a few days to get to.

Chris

#9 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 17 May 2011 - 01:59 PM

There are a few other issues we're working on for 4.1.1 beta 2 (and are also preparing for MakerFaire)--so this may take a few days to get to.

No problemo, I'm using a different Latch pin at the moment and use Pin 4 for GPIO only. I'm just curious what causes this problem :)

MakerFaire; why are there so little of such events in Europe? :)
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#10 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 27 May 2011 - 08:13 PM

Did some more tests to please my curiousity;

Pin 4 won't work as latch on:
- Netduino (v4.1.1.0 b1) by Secret Labs LLC
- Netduino Plus (v4.1.1.0 b1 with extra RAM) by Secret La

Now comes the interesting part. I took the mini, and tried the only non-managed pin, Pins.GPIO_PIN_13. Same result, not working as latch pin! Tried:
- Netduino Mini by Secret Labs LLC (4.1.0.5)

Digital pin 4 is the "hardwired" chip select pin for the SPI bus. Microsoft included special handling for it in the SAM7X board support package, to special-case it.

Does that also count for pin 13 on the Mini? :)
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 27 May 2011 - 10:23 PM

Hi Stefan,

Does that also count for pin 13 on the Mini? :)

Yes, exactly same pin configuration and same issue. .NET MF includes a special case for the SPI_SS pin in the SAM7X firmware. We're looking at it, and there are some timing differences between cases that we need to account for. I'll post more as we test the solution.

Chris

#12 EvanLaske

EvanLaske

    New Member

  • Members
  • Pip
  • 6 posts

Posted 31 May 2011 - 02:02 PM

Any word on what causes this in the Firmware; or a fix for this? I am working on a project and we just so happened to already design a board to use this pin as a SSEL pin on the Netduino Mini... That was of course before we tried that same hardware-SPI pin on the Netduino and found it didn't work.

#13 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 31 May 2011 - 02:05 PM

It's up to Chris to reply for a permanent fix, but! If you need it quickly I can try to write a software work-around for it, I think it's possible. Only requirement would be that you use a modified version of my MultiSPI class. I have an idea about how to work around the problem. It will slow down the SPI bus a bit though, if I get it to work.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#14 EvanLaske

EvanLaske

    New Member

  • Members
  • Pip
  • 6 posts

Posted 31 May 2011 - 03:02 PM

It's up to Chris to reply for a permanent fix, but!

If you need it quickly I can try to write a software work-around for it, I think it's possible. Only requirement would be that you use a modified version of my MultiSPI class. I have an idea about how to work around the problem. It will slow down the SPI bus a bit though, if I get it to work.


I'd be curious to see what is causing this problem in the firmware. I haven't delved into it to even know what's going on in there yet, but I'm sure I will sometime. I just was hoping it'd be on my own terms, lol.

Also, I've heard you talk about the MultiSPI class, but haven't seen it. I'd like to see if we can use it.

#15 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 31 May 2011 - 03:09 PM

So far my MultiSPI-class is only used in https://stefan.co/ne...h-bitshift-ics/ As far as my understanding of the bug goes is that the pin actually has a CPU-managed functionality (SPI Slave CS) which makes the timing of the pin a bit off. I got this news at around 01.00am today so haven't worked out a work-around but I made one up in my mind. Tonight I'm going to type it out and check if the NETMF compiler in my head works the same as on my PC :P For more details on the bug/feature itself I have to direct you to Chris, he's the man when it's about bugs/features.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#16 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 31 May 2011 - 04:25 PM

Could you try if the attached project "fixes" your problem?

Attached Files


"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#17 EvanLaske

EvanLaske

    New Member

  • Members
  • Pip
  • 6 posts

Posted 31 May 2011 - 05:30 PM

Could you try if the attached project "fixes" your problem?


I looked at the code, and it looks like the things I was going to try. I just had no idea (I didn't try) that the SPI port would function properly if configured with GPIO_NONE as the SSEL pin. I'll have to go ahead and try just using the pin externally until there is a firmware fix.

Maybe in my free-time I'll look into the firmware myself and figure out if there's a quick fix... Until then, this patch should work.

Thanks for your help! I'll have to look into the amount of time lost in the managed code fix. I am sure it's relatively hefty.

#18 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 May 2011 - 06:12 PM

Hi Evan,

Any word on what causes this in the Firmware; or a fix for this? I am working on a project and we just so happened to already design a board to use this pin as a SSEL pin on the Netduino Mini... That was of course before we tried that same hardware-SPI pin on the Netduino and found it didn't work.

Normally, you'd be limited to a certain subset of pins that you could use for SPI chip select (4 in the case of the SAM7X microcontroller used on Netduino), but .NET MF does a "software SPI select" which lets you use any pin.

The side effect is that there is a "special case" in the .NET MF firmware for the main hardware SPI chip select pin. There are some slight timing/selection issues between hardware and software SPI select. We looked at these once during the development of .NET MF 4.1 beta, and are running through them again to get a permanent fix in place. The fix should be posted in the next week or two (although it may basically be the same thing that Stefan is proposing here--a software select override).

Chris

#19 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 13 September 2011 - 04:38 PM

The work around I posted earlier has been implemented in the MultiSPI class in this codeplex project: http://netmftoolbox.codeplex.com/ It automatically detects if the bug occures by checking which pin is used for the SPI connection. If it validates with (int)12 it will activate software chip-select.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#20 Mike P

Mike P

    Advanced Member

  • Members
  • PipPipPip
  • 41 posts
  • LocationAuckland, New Zealand

Posted 15 September 2011 - 09:48 AM

Hi Stefan, since you've brought this back to the top again I'll add my 2cents. If you are interested I think I can explain why pin4 does not work as a chip select. The SPI driver is part of NETMF code. SecretLabs have a few lines of code they have added but by and large it is untouched from the NETMF distributed version. The AT91 core SPI peripheral supports 4 pins as hardware chip select pins CS0-CS3. CS0 is also used as a slave select (NSS) in slave mode. Pin4 is the pin that connects to this CS0/NSS peripheral output. Within the driver code there is a block of code that would convert pin 4 from its GPIO function to its SPI peripheral function if you pass pin4 as the chip select. This line of code is commented out. There is also a code block that sets the CS pin to the appropriate state before and after the transfer. This block of code doesn't get executed if you use GPIO_PIN4 or GPIO_PIN_NONE. It appears as though the programmer intended to support use of pin 4 as a peripheral hardware chip select and any other pin as a software chip select. But when they couldn't get CS0 working they commented it out in one place but not the other. I think I can see why it wouldn't have worked too. As written the CS line would have pulsed inactive between each character which would have messed things up in most applications. So until someone fixes the SPI class properly you will just have to accept that pin4 can't be used for Chip select. If you are interested to look yourself the driver code is in the porting kit here: C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_SPI\AT91__SPI.cpp




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.