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.

Kristoffer's Content

There have been 37 items by Kristoffer (Search limited from 29-March 23)


By content type

See this member's


Sort by                Order  

#37422 SPI.configuration and L6470 Stepper Driver

Posted by Kristoffer on 19 October 2012 - 10:39 AM in Netduino 2 (and Netduino 1)

Thanks Mario, I think I get your point.

I just need to get something clarified

Handshaking the SPI using the managed code is *really* painful: maybe slower than a turtle.

do you refer to the togling of the SS pin (opSS.Write(false) and opSS.Write(true)) in the SendBytes method?
static void SendBytes(byte[] bWrite, byte[] bRead)
{
    opSS.Write(false);
    spi.WriteRead(bWrite, bRead);
    opSS.Write(true);
}
Actually that's and old implementation, my current SendByte method looks like this:
static void SendByte(byte bWrite)
{
    var bRead = new byte[1];
    spi.WriteRead(new byte[] {bWrite}, bRead);
}
But that should almost be the same since the spi.WriteRead(...) automatically toggles the SS pin.

The L6470 needs the SS pin to toggle (...After each byte transmission the CS input must be raised ....)

So the problem is the spi.WriteRead(...) is slow when it toggles the SS pin it's not slow writing bytes?

And what you say, is that this can be done much faster by implementing the hardware fix (just like nakchak suggests earlier in this thread)?

I haven't had any performance issues with my approach and setup so far, and it hasn't been a show stopper. But I can see that it's not "fast" when I send many bytes like in the Setup motor method.

So I will definitely look into your very thoroughly described hardware fix, thanks a lot for you input, it's very much appreciated :)

Regards
Kristoffer



#37376 SPI.configuration and L6470 Stepper Driver

Posted by Kristoffer on 18 October 2012 - 09:57 AM in Netduino 2 (and Netduino 1)

Hi Kristoffer,
Can you please give us some update about how the usage of this driver L6470 is going?
I am planning to use it in a new project with Netduino Classic and would like to know how was your experience.
Did you develop some kind of driver or library for it?
Thank you,
Igor.


Hi Igor

Certainly I will.

I'm using it and it works fine, it has been a little up-hill, mostly because of my lack of knowledge in electronics, but I managed to get it to work.

This guy, Kurtnelle, has developed a .NET L6470 driver which should be fine, and here's a link to a discussion about it.

If you use the the sparkfun L6470 Breakout board, I'd recommend you read the comments at the Sparkfun L6470 product page, and pay attention to 4 specific advices:

  • An user suggest downloading ST dSpin evaluation software (evaluation software is found at the bottom of tab page “Design support”), it will help you figure out how to set some essential and motor specific parameters.
  • Another user links to a ST presentation of the L6470, watch it, I didn't notice it until today and it makes a lot of things clear to me that I didn't understand earlier.
  • Read the important section in the Arduino example - dSPIN_example.ino, it suggest inserting a SOFTSTOP between motion commands, I found that usefull and saved me some time.
  • There's a known problem about VReg at the Sparkfun L6470 Breakout board

Based on the Arduino example sketch at the Sparkfun L6470 product page and the parameters from the dSpin evaluation software my motorspecific setup looks like this:

private void Setup_MAE_210_24V()
{
	//opReset = L6470 Reset Pin
	opReset.Write(true);
	Thread.Sleep(1);
	opReset.Write(false);
	Thread.Sleep(1);
	opReset.Write(true);
	Thread.Sleep(1);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_STEP_MODE);
	SendByte(Constants.dSPIN_STEP_SEL_1);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_MAX_SPEED);
	SendBytes(MaxSpdCalc(600), 2);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_MIN_SPEED);
	SendByte(0x10);
	SendByte(0x00);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_KVAL_HOLD);
	SendByte(0xC);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_KVAL_ACC);
	SendByte(0x21);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_KVAL_DEC);
	SendByte(0x21);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_KVAL_RUN);
	SendByte(0x21);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_ST_SLP);
	SendByte(0x18);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_INT_SPD);
	SendByte(0x1A);
	SendByte(0xFF);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_FN_SLP_ACC);
	SendByte(0x2D);

	SendByte(Constants.dSPIN_SET_PARAM | Constants.dSPIN_FN_SLP_DEC);
	SendByte(0x2D);

	//These three commands prevented a small but consistent steploss when I called MOVE the first time after initialization
	//I haven't found an explenation nor have I dug into why, actually I don't think you need all three commands, maybe a SOFTSTOP would do.
	SendByte(Constants.dSPIN_RESET_POS);
	SendByte(Constants.dSPIN_GO_HOME);
	SendByte(Constants.dSPIN_HARD_STOP);
}

Notice a significant difference from the Sparkfun Arduino example, I do not set the config register, the default values worked for my setup, so I haven't really dug into the Config parameters (maybe the steploss issue metioned in code is found here :mellow: ).

My success criteria was a precise movement including:
  • no step loss
  • control of acc and dec
  • control of speed
  • control of holding torque

And that's what the L6470 fullfilled. I can see there's a bunch of other possibilities with the chip like attaching a switch, use more complex movement commands based on the position knowledge in the chip and so on.

Let me know if you run into problems or if you have further questions, I might be able to help you.

Regards
Kristoffer



#36373 ShieldBase Mini?

Posted by Kristoffer on 01 October 2012 - 03:30 PM in Netduino Go

Can you share more about the type of size and feature set you'd like to see. How small? 3V3/5V switching? Open drain capabilities? GPIO-only, or including other features like PWM and ADC as on the shield base?


My initial thought was simply a ShieldBase that was small and compact, I know that it wouldn't be a ShieldBase then.

I could use an I/O expander module with as many GPIO's as possible (I could use +100 or 2x50 etc.) simple 3V3/5V switching. I'd prefer that over an "all-in-one" solution like the ShieldBase. What would matter to me was physical size and no. of GPIOS, so if additional features like PWM and ADC wouldn't take up significant space and cost, those features would be relevant as well.

I haven't really checked if any Gadgeteer modules might do the job, but after the Gadgeteer Adapter module revelation :rolleyes: , I'll check them out.

Kristoffer



#36126 ShieldBase Mini?

Posted by Kristoffer on 28 September 2012 - 07:14 AM in Netduino Go

Are you thinking of a small IO expander module?

Yes



#36079 ShieldBase Mini?

Posted by Kristoffer on 27 September 2012 - 08:57 PM in Netduino Go

Any plans to make a ShieldBase Mini similar to the Netduino Mini? Kristoffer



#36078 Netduino Go in a professional automation setup

Posted by Kristoffer on 27 September 2012 - 08:51 PM in Netduino Go

Hi

I hope you guys can give me some input on this one.

Why would one hesitate to use Netduino Go/Go Modules in a professional industrial automation setup?

- Reliability
- Operating environment: dust, temperature, noise, humidity
- Durability
- Safety

I've read this Arduino reliability discussion and some of the argumentation is about

- Input & output protection, ESD
- IEC standards

Another concern I got is the state of the Netduino Go and modules, everything is in version 1.0 or Beta - I would never use any beta version for production - but is version 1 reliable?

Any software needs good structure and maintainability and in my domain the NETMF is up for that, so that's the primary reason I ended up with Netduino.

Actually I got a well-working project, doing as expected and any changes are easily implemented, however I have a feeling I've missed something and everything crashes at the presentation.

Any experiences and inputs are appreciated.

Thanks
Kristoffer



#32536 Inductive sensor input problem

Posted by Kristoffer on 23 July 2012 - 02:07 PM in Netduino 2 (and Netduino 1)

Hi Mario I didn't see your great explanation until now, but thank you for making it clear :) Kristoffer



#32534 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 23 July 2012 - 12:45 PM in Netduino Go

As a follow up on the problems I initially had with the ShieldBase and Mainboard firmware, I'm now having some problems writing to an OutputPort.

ShieldBase.dll throws an exception on these two programs on the op.Write\(b\) call

It writes the value to the port (I can see it changes from low to high) and 3-4 seconds later it throws the exception.

Output:
A first chance exception of type 'System.Exception' occurred in NetduinoGo.ShieldBase.dll

Stack Trace:
NetduinoGo.ShieldBase.dll!NetduinoGo.ShieldBase.WriteOutputPort(Microsoft.SPOT.Hardware.Cpu.Pin portId = 1004, bool state = true) Line 282 + 0x44 bytes C#

It makes no difference whether I use an Analog (sb.Pins.GPIO_PIN_A1) or a Digital (sb.Pins.GPIO_PIN_D4) pin
public class Program
{
    private static OutputPort op;
    private static bool b;
    
    public static void Main()
    {
        var sb = new ShieldBase(GoSockets.Socket5);
        op = new OutputPort(sb.Pins.GPIO_PIN_D4, false);
     
        NetduinoGo.Button btn = new Button(GoSockets.Socket1);
        b.ButtonPressed += btn_ButtonPressed;

        Thread.Sleep(Timeout.Infinite);
    }

    static void btn_ButtonPressed(object sender, bool buttonState)
    {
        b = !b;
        op.Write(B);
    }
}
public class Program
{
    private static OutputPort op;
    private static bool b;
    
    public static void Main()
    {
        var sb = new ShieldBase(GoSockets.Socket5);
        op = new OutputPort(sb.Pins.GPIO_PIN_D4, false);

        var ip = new InterruptPort(Pins.Button, false, Port.ResistorMode.Disabled,
                                              Port.InterruptMode.InterruptEdgeHigh);

        ip.OnInterrupt += new NativeEventHandler(switchPort_OnInterrupt);
        Thread.Sleep(Timeout.Infinite);
    }

    static DateTime portLimitSwitchInterruptionTime;
    private static void switchPort_OnInterrupt(uint port, uint data, DateTime time)
    {
        if (portLimitSwitchInterruptionTime.AddMilliseconds(50) > time)
            return;

        portLimitSwitchInterruptionTime = time;

        b = !b;
        op.Write(B);
    }
}

I know the InterruptPort is not enabled on the Shieldbase, but is it the same with the Mainboard?

The following two programs runs fine

public class Program
{
    private static OutputPort op;
    private static bool b;
    
    public static void Main()
    {
        var sb = new ShieldBase(GoSockets.Socket5);
        op = new OutputPort(sb.Pins.GPIO_PIN_D4, false);

        op.Write(true);
        Thread.Sleep(1000);
        op.Write(false);
        
        Thread.Sleep(Timeout.Infinite);
    }
}
public class Program
{
    private static OutputPort op;
    private static InputPort ip;
    private static bool b;
    
    public static void Main()
    {
        var sb = new ShieldBase(GoSockets.Socket5);
        op = new OutputPort(sb.Pins.GPIO_PIN_D4, false);

        ip = new InputPort(Pins.Button, false, Port.ResistorMode.Disabled);

        var t = new Thread(EventListener);
        t.Start();

        Thread.Sleep(Timeout.Infinite);
    }

    private static void EventListener()
    {
        bool currentRead = false;
        
        while (true)
        {
            if (currentRead != ip.Read())
            {
                currentRead = !currentRead;
                
                if(currentRead)
                    TogglePort();
            }
        }
    }

    private static void TogglePort()
    {
        b = !b;
        op.Write(B);
    }
}



#32353 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 20 July 2012 - 12:50 PM in Netduino Go

Just to clarify what you are trying to do is run 2 netmf apps at once, i.e. if it was a console app solution when you hit f5 you would expect 2 console windows to open? If thats the case why would you do that instead of running one of the apps as a separate thread off of the main app?


Oh yeah I understand this issue might be a little confusing and by now off topic. It was just some observations I accidentally did when I tried to reproduce the issues I had originally (see top topic). So it's definitely not essential to me and nothing I can see any need for.

When I select a project as Startup project in Visual Studio, I would expect that projects Program.Main method to be executed as first method and any other code must be started from there, so it does when I have a solution with only Console application projects, in that I can add as many Console applications as I like and switch between them as Startup projects without any problems. I can't tell whether this not consistent NETMF behavior is intended or it's a bug or whatever, it just confused me. :mellow:



#32339 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 20 July 2012 - 09:16 AM in Netduino Go

Hi kristoffer_o,

One of our community members (KodeDaemon) pinged me and mentioned that changing the Startup Project to "Current selection" in your solution properties may force Visual Studio to deploy a specific project in a multi-project solution.

Can you try this in your multi-project solution?

1. Open up your Solution's Property Pages.
2. Under Common Properties, select the "Startup Project" category.
3. Change the option to "Current selection" (if "Single startup project" is currently selected)

Chris


Tried it, but same issue :(



#32337 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 20 July 2012 - 08:36 AM in Netduino Go

Dumb question but both projects are targetting the right framework version?

That would be my first question if it was someone else who had these issues :)
The answer is yes, I've checked the project files and solution files line by line just to see if that would reveal anything.

I ask as i have had similar issues when one was set to 4.1 and the other was 4.2, but other than that I have never encountered any issues with multiple projects of multiple types such as in the attached image where i have 2 netmf projects, 1 MVC app and 7 class libs.


Which project is your Startup project?

The only thing that seems consistent is a solution with 1 NGO app project runs fine, adding another NGO app project makes the first unrunnable as startup, adding a third project makes the first and second unrunnable and so on, so it's only the last added project that's runnable in a only NGO app project solution. But in another solution with a Class lib and two NGO app projects it's only the first NGO app project I can run, so I can't really conclude anything.

But it's interesting if both NGO app projects in your solution can be set as Startup projects, it might be my NETMF SDK 4.2 installation, it's just the one from the Netduino.com download page, see attachment

Kristoffer

Attached Thumbnails

  • NETMF SDK.png



#32334 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 20 July 2012 - 07:48 AM in Netduino Go

Okay, I think that's actually a bug in Visual Studio or the .NET Micro Framework SDK. I'm not sure that it was ever designed with the scenario of having two app projects to deploy within a single solution (and having one selected as the startup project).

No, that makes perfect sense. But these two projects doesn't know of each other, there's no reference between them and still it looks as though Visual Studio tries to deploy a project that's not used nor referenced by the startup project.

I tried the same with two Console applications and it behaves as I would expect, I can switch between startup projects without any problems. So I don't know what Microsofts intentions are with NETMF projects in Visual Studio, I'm absolutely new to NETMF, but my first impulse was to refer to "normal" Visual Studio behavior.

If you remove the unused project, does it deploy properly?

Yes.

BTW, we can ping Microsoft on the multiple-project issue. It may be possible for them to support that scenario, or at least provide an error to the user when compiling projects with multiple 'applications'.

Ok, I've never done that, but if you tell me what to do, I'll gladly, describe, report or whatever I can do.

I believe it must be a bug since Visual Studios behavior is not consistent, under some circumstances it supports multiple MF app projects and under others it doesn't.

Thanks again :)



#32287 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 19 July 2012 - 11:28 AM in Netduino Go

Hi I did a little investigation this morning.

I created a new NetduinoGo application project in an empty solution in Visual Studio 2010 Ultimate

using System.Threading;

namespace GoTesting
{
    public class Program
    {
        public static void Main()
        {   
            Thread.Sleep(Timeout.Infinite);
        }
    }
}

I can run this project several (at least 10) times without having to unplug/replug the NetduinoGo USB cable to the computer, I put a breakpoint in the main method and it gets hit.
I can also put in and initialse a ShieldBase and OutputPort without any problems.

Then I add a second NetduinoGo application project to the solution, and add exactly the same code as first project.
using System.Threading;

namespace GoTesting2
{
    public class Program
    {
        public static void Main()
        {   
            Thread.Sleep(Timeout.Infinite);
        }
    }
}

I don't change the startup project and I don't unplug/replug USB cable

When I press F5 no breakpoint gets hit and it looks as it's trying to deploy GoTesting2 see 2_Projects_Debug_Output_1_run.txt. The dubug session is running and I have to stop it myself.

I try to unplug/replug USB cable, but still no breakpoint is hit, see 2_Projects_Debug_Output_2_run.txt

When I change the startup project to GoTesting2, all seems fine, GoTesting2 breakpoint gets hit and there's no problem when stopping and starting debugging several times.

When I change startup project back to GoTesting: same issue as first time GoTesting was startup project. When I remove GoTesting2, GoTesting is running fine again.

Hmmm! I actually tried this because I became insecure if I had upgraded the NetduinoGo firmware correctly, I believe that I had misunderstood the Upload/Upgrade groupboxes in the DfuSe demo app (thanks Stefan for explaining that you actually upload to your computer :) ), so I did a new NetduinoGo firmware upgrade just to be 100% certain. After that I wanted to reproduce Issue #1 "Cannot find any entrypoint!", but I couldn't, instead the above happened.

so I went back to one of my orginal projects containing a NetduinoGo Class library project and two NetduinoGo application projects, and the same pattern repeated: one of the application projects
couldn't run and the other could, actually it was the one that referenced the class library that could run.

So where does it bring now: I'm able to port my original Netduino project to the NetduinoGo at the current status, so I can move on.

However, I'm still very uncertain that my firmware upgrades are correct, I can't figure out if it's a Visual Studio, a Netduino SDK or a NETMF issue about the startup projects.

If I get some time I'll try to investigate this further.

So what I'm saying is I'll try to move on, with my fingers crossed. I'll report back later how it goes.

Thanks a lot for all your help

Kristoffer

Attached Files




#32282 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 19 July 2012 - 10:07 AM in Netduino Go

I've got the same issue when creating either an OutputPort or InputPort targeted at the ShieldBase. I haven't tried Analog yet....


Hi rcflyair

It looks as you have the same problems as I experience/experienced, I believe your post in this topic is also part of the problem.

One of the pitfalls for me in the update firmware process, was that I had to unplug and plug in again the NetduinoGo every time I had to deploy something new (because of the "cannot find entry point" issue). So after the ShieldBase firmware update, by routine, I just unplugged/plugged in the NetduinoGo, but that made the ShieldBase firmware update start all over and I didn't pay attention to that. So while the ShieldBase firmware update was in progress I uploaded a new program to the NetduinoGo trying to connect to a ShieldBase with incomplete firmware.

So after the ShieldBase firmware update I unplugged the NetduinoGo, unplugged the ShieldBase from the NetduinoGo, replugged the NetduinoGo and deployed a dummy program to the NetduinoGo. After that I could reattach the ShieldBase and I didn't have any problems initialising a new OutputPort.

I don't know if that's your problem, but it's worth a try.



#32241 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 18 July 2012 - 11:33 PM in Netduino Go

Sample app to reproduce issue #1

using System.Threading;

namespace GoTester
{
    public class Program
    {
        public static void Main()
        {   
            Thread.Sleep(Timeout.Infinite);
        }
    }
}

And flash image attached

Attached Files




#32231 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 18 July 2012 - 09:37 PM in Netduino Go

Unfortunately I'm not at my computer at the moment, I'll do it as fast as I can within a couple of hours. Appreciate all your help, thanks a lot :-)



#32226 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 18 July 2012 - 08:23 PM in Netduino Go

....If that is correct, please try to reflash the Shield Base again. If the update wasn't completely written (or accidentally restarted aftering being completed...and then got interrupted), your Shield Base firmware could be corrupt...which would cause this issue.


I believe that was part of the problem, did a reflash and now it works if I use shieldBase.Pins.GPIO_D2, but still same exception if I use D0 or D1, so problem 2 is partly solved:)

Problem 1 persists.



#32195 ShieldBase unhandled exception on new OutputPort()

Posted by Kristoffer on 18 July 2012 - 12:55 PM in Netduino Go

I have reflashed my Netduino Go following the description in this thread:
http://forums.netdui...ployment-issue/

I have used the unofficial firmware chris links to at the bottom of this topic page 1
MainboardFlashUpdates.zip

After that I updated the ShieldBase with the beta 1 firmware found here: Shield Base Firmware v4.2.0.1 (beta 1) Includes PWM bugfixes

All went fine.

I can run the most simple NetduinoGo application without any problems

using System.Threading;

namespace GoTester
{
    public class Program
    {
        public static void Main()
        {
            Thread.Sleep(Timeout.Infinite);
        }
    }
}

See attachment debug_output_1_run.txt for debug ouput of this run

After that the problems start:

1. problem
When I try to rerun the program (stop debugging and run again or ctrl-shift-F5) I get this message: "Cannot find any entrypoint!" in the debug output window, see attachment debug_output_2_run.txt

I can get by this by unplugging the NetduinoGo USB cable from the computer and plug it in again and then run again. But that means I have to unplug and replug the USB cable each time I've made a new build.

2. problem
I reference the ShieldBase.dll and tries to instantiate an OutputPort but I get an exception (see also debug_output_shieldbase_run.txt)
A first chance exception of type 'System.Exception' occurred in NetduinoGo.ShieldBase.dll
An unhandled exception of type 'System.Exception' occurred in NetduinoGo.ShieldBase.dll

using System.Threading;
using Microsoft.SPOT.Hardware;
using NetduinoGo;
using SecretLabs.NETMF.Hardware.NetduinoGo;

namespace GoTester
{
    public class Program
    {
        public static void Main()
        {   
            ShieldBase sb = new ShieldBase(GoSockets.Socket5);

            OutputPort op = new OutputPort(sb.Pins.GPIO_PIN_D0, false);
            
            Thread.Sleep(Timeout.Infinite);
        }
    }
}

The StackTrace reveals it's in the ShieldBase.CreateOutport function it crashes (see StackTrace.png)

Have I missed something?

Attached Thumbnails

  • StackTrace.png

Attached Files




#32158 Shield Base Firmware v4.2.0.1 (beta 1)

Posted by Kristoffer on 17 July 2012 - 08:55 PM in Netduino Go

.....
Could you try flashing your Netduino Go with the attached (unofficial) firmware? Just flash all three files using ST's "DfuSe demonstrator" program.
....


Doing this solved my problem:

Running the ShieldBase firmware update stalled at line 180 in STM32Bootloader.cs

_bootloaderPort.Write(true);
And nothing happened until I forced the execution to stop.

I flashed the Netduino Go with the unoffical software and ran the ShieldBase firmware update again without any problems



#31807 [nwazet Go! modules - update announcements

Posted by Kristoffer on 10 July 2012 - 10:30 AM in Netduino Go

Does anyone know if this is delivered or on it's way?

Thanks


I guess this is it:
http://forums.netdui...-based-modules/



#31805 [nwazet Go! modules - update announcements

Posted by Kristoffer on 10 July 2012 - 08:59 AM in Netduino Go

...... Secret Labs needs to deliver the module flashing application that the Go! community needs.



Does anyone know if this is delivered or on it's way?

Thanks



#30723 SPI.configuration and L6470 Stepper Driver

Posted by Kristoffer on 15 June 2012 - 08:44 AM in Netduino 2 (and Netduino 1)

Hi Nak

Thanks for all your help.

My first problem was that I couldn't send understandable commands to the L6470 driver via SPI, I solved this by changing the initial SPI.Configuration (see first post) to this:
var device1 = new SPI.Configuration(Pins.GPIO_PIN_D10, // SS-pin
                                    false,             // SS-pin active state
                                    0,                 // The setup time for the SS port
                                    0,                 // The hold time for the SS port
                                    false,             // The idle state of the clock
                                    true,              // The sampling clock edge
                                    5000,              // The SPI clock rate in KHz
                                    SPI_Devices.SPI1   // The used SPI bus (refers to a MOSI MISO and SCLK pinset)
                );
The problem was the Idle state of the clock and the sampling clock edge parameters, and it didn't make any difference if I toggled the SS-pin in code or it was automatically toggled when calling WriteRead(...).

This still doesn't give me the expected responses in the read buffer when I execute a spi.WriteRead(...);, but I've chosen not to be concerned about that at the moment. When the NetduinoGo ShieldBase is out of Beta all my code is going to be ported to the NetduinoGo, so I'll wait and see what new challenges lies ahead.

Im currently in the process of designing a 3 axis stepper motor driver module for the GO which uses the same dspin chip as your driver, does look like a very capable bit of kit

Indeed :), can I sign up for a newsletter or something? Please let me know when you expect to have something ready, I'm very eager to use the NeduinoGo.

I've been using the BigEasyDriver, which is very easy to get started with, but for my needs, I found it very difficult to configure and make proper acceleration/deceleration and the motors had this bzzz sound all the time.

Kristoffer



#30619 SPI.configuration and L6470 Stepper Driver

Posted by Kristoffer on 13 June 2012 - 05:15 AM in Netduino 2 (and Netduino 1)

You can just send a single byte at a time as that will toggle the CS line, however its not half as fast as it can be if you can get the CS line to toggle

Isn't that what I'm doing if I do like this:
{
var writebuffer = new byte[]{0x38};
var readbuffer = new byte[1];

SendBytes(writebuffer, readbuffer);
}



#30604 SPI.configuration and L6470 Stepper Driver

Posted by Kristoffer on 12 June 2012 - 09:13 PM in Netduino 2 (and Netduino 1)

Hi

I'm trying to connect to one of these: L6470 Stepper Motor Driver, a stepper motor driver controlled over an SPI link.

It comes with an Arduino example sketch, which runs fine. So I'm trying to port it to my Netduino using the SPI.Configuration and SPI types described in the wiki, so far no luck.

Below is an excerpt of the L6470 datasheet:

Maximum SPI clock frequency: 5 MHz
Chip select setup time: min. 350 ns
Chip select hold time: min. 10 ns
Deselect time: min. 800 ns
Data input setup time: min. 25 ns
Data input hold time: min. 20 ns

"When CS is high the device is unselected and the SDO line is inactive
(high-impedance).

The communication starts when CS is forced low. The CK line is used for synchronization of
data communication.
.....
After each byte transmission the CS input must be raised and be kept high for at least tdisCS
in order to allow the device to decode the received command and put into the shift register
the return value."


So I'm setting the SPI configuration like this:
opSS = new OutputPort(Pins.GPIO_PIN_D10, true);

var device1 = new SPI.Configuration(Pins.GPIO_NONE, // SS-pin
     				    false,          // SS-pin active state
                                    350,            // The setup time for the SS port.[b] What resolution is this?[/b]
                                    10,             // The hold time for the SS port. [b]What resolution is this?[/b]
                                    true,           // The idle state of the clock
                                    false,          // The sampling clock edge
                                    5000,           // The SPI clock rate in KHz
                                    SPI_Devices.SPI1// The used SPI bus (refers to a MOSI MISO and SCLK pinset)
                );

spi = new SPI(device1);
And the write routine:
static void SendBytes(byte[] bWrite, byte[] bRead)
{
    opSS.Write(false);
    spi.WriteRead(bWrite, bRead);
    opSS.Write(true);
}

But I'm not getting the same reponses as the Arduino example, far from.

If I i.e. send a0x38 byte via Arduino example, then I get a single byte back value 1. Doing the same from Netduino gives also 1, however, no matter how large I make the read buffer (i.e var bRead = new byte[40]; ) the first byte is 1 and the rest is 121 (decimal). And after that responses are not comparable.

Unfortunately I don't have an oscilloscope, so I can't measure what actually happens. Would that actually be possible to measure a byte with an oscilloscope?

I have tried to set SS port setup time and hold time in the SPI.Configuration constructor to 0 and it gives the same result.

If anybody can see anything that might cause trouble in my SPI setup, please let me know.

Thank you
Kristoffer



#30271 Inductive sensor input problem

Posted by Kristoffer on 05 June 2012 - 09:46 PM in Netduino 2 (and Netduino 1)

Ok, that makes sense, I've done this in other setups I've made out of examples, but this time I decided only to do something if I could explain it to myself. I learned something today :) , thanks again.




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.