Strange pauses!

NETMF & Gadgeteer
1

Hi Guys,

Just got my Cobra, first test as always was to see it cycling a digital out.

Very simple:

  OutputPort LED = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.LED,true);

  while (true)
  {
    LED.Write(true);
    LED.Write(false);
  }

First thing I noticed is that the LED lighting was not static, there where pauses of either off or on every so often.

I attached a scope and you can see this in the image I have attached.

I have tried different pins and also a release build, same problem!

I don’t mind .NET being slow but I need it to be consistent, is this just how it is or is something wrong here?

Thanks fro any help

Andy

2

May this have something to do with the underlying threading model or garbage collector kicking inn?

3

see [url]http://informatix.miloush.net/microframework/Articles/MeepMeep.aspx[/url] at page bottom

4

[quote]I don’t mind .NET being slow but I need it to be consistent, is this just how it is or is something wrong here?
[/quote]

You just need to change your way of thinking. If you just want to create a very stable square wave output use a PWM channel; that will always be more accurate than a software driven pulse generator. If your just toggling pins to toggle pins I’m not sure what such a test proves.

5

This is a VERY bad test! This is a manged system and there is so much going on even if you are just toggling an pin.

No you can’t get real time out of non-real time system. If you need constant pin toggle then you have to use one of the built in services like PWM or OutputCompare.

6

Hi Guys,

Thanks for the replies.

Yes I was thinking maybe the garbage collector, but I am not sure.

I was not after a nice square wave I was just checking to see the speed of writing to the pin and the general c# performance, so I do not think it is a very bad test I am just starting you know!

The pause is around .2ms which to me seems a very long time, maybe I need to adjust my head a bit!

I tested PWM output and that doesn’t suffer from the same issue.

Cheers

Andy

7

It’s probably a combination of a couple things - the garbage collector, debugging routines, etc. You’re dealing with a complete “system” allowing multi-threading, garbage collection and a bunch of stuff you don’t have to manage, so unlink AVR or other things, your process may be suspended temporarily.

I think it’s still good to have knowledge of smaller controllers like the AVR’s, my particular projects I plan on having a combination of FEZ and AVRs connected via I2C, for handling any signals/loops/etc you cannot handle on the FEZ with PWM, OutputCompare, etc.

.2ms seems like an eternity for hardware developers, but in reality it’s 1/5000th of a second - not going to cause trouble for 99.999% of applications :slight_smile:

8

Actually, it is a bad test.

Everyone says this is not a real-time application platform. it’s close, and you can optimise, but doing what you’re doing is not something you can expect to achieve. You will always see some “external” things going on that you can’t avoid nor control.

get back to telling us why you think that’s important and we will see how we can help :slight_smile:

9

I don’t wish to be pedantic here but the test was for me to:

  1. Get an app built in VS.
  2. Get it onto the device.
  3. See it running.
  4. Attach a scope to see I had pins correct.
  5. See how .NET perfumed in a simple test with GPIO using OutputPort.

I think it was valid as it made me realise:

  1. GPIO access is very slow (using OutputPort)
  2. The cobra cannot be used for RT stuff.

I did not realise these things before, now for people that know these things the test would be a bad test as there is no need to reinforce something you already know, for an ignoramus like me though I think a good test!

Cheers

Andy

10

I would only add for your #2 point below concerning RT. While you can not do deterministic hard real time things there are many ways you can ‘fake’ real time. For example: interrupts are time stamped which allows you do do things lice decode IR remote signals, you have access to hardware SPI, UART, PWM etc which can do many things in hardware while your program is merrily working on other things.

11

Yep I Agree, its the slightly non-deterministic behaviour that may get in the way of some things, all I need to do is hook up some cheapo PICs to handle that side though.

The main reason I wanted the cobra/LCD is for a central control unit anyway, for that it is perfect.

Cheers

Andy

12

Oh! I forgot about RLP on the Cobra. With RLP you can compile and run your own native code on the processor as well! So you may be able to have your cake and eat it too!

13

I had a look at RLP, I am not sure it would not suffer form the same issue though as you would be back in managed code between your RLP calls.

Unless you ran everything in it maybe :slight_smile:

14

What is exactly are you trying to develop. I can save you some work and tell you if NETMF will work for your application or not.

15

I just wanted to mention that you may have pauses when you are debugging because Visual Studio is trying to communicate with your board.

16

Hi Mike and Gus,

I tried with a release build deployed as well, same issue.

The project is to build a audio/control voltage processing module for eurorack modular synths, an example is Doepfer : Doepfer Homepage English

The unit will have :

8 x 24 bit audio inputs at 192Khz

8 x Analog audio outputs from 24bit 192Khz internal audio

8 x CV Inputs (-10V to 10V)

8 x CV Outputs (-10V to 10V)

16 x Endless rotary encoders

GUI with touchscreen

Support for Open Sound Control : http://opensoundcontrol.org/

The audio side is implemented using 2 DSPB56371 freescale DSPs and 4 AK4556 ADC/DAC devices.

The audio side provides functionality like filters, delay, oscillators etc

The CV input side is used for control of the audio side, this includes things like clocking, setting pitch, gateing etc.

The CV output side is used for generating clocks, pitch, gates, envelopes, LFOs etc. Also the CV inputs can be processed, for example to quantise a pitch CV input to a particular scale.

Open Sound Control is also used for providing CV in and out functionality over a network and also for control from more complex user interfaces such as offered by devices like the Lemur: jazz Mutant

The idea is to have the whole system working in a very modular way, the inputs and outputs are not set in what they can do or their routings within the device. The user can set up various ‘setups’ of how the hardware will work, these can be created/stored/loaded from a touchscreen interface.

For example a simple ‘setup’ may be to have the following:

CVIn1 - Clock
CVIn2 - Reset

CVOut 1 - Clock
CVOut 2 - Clock / 2
CVOut 3 - Clock / 8
CVOut 4 - Clock / 16
CVOut 5 - Clock / 32
CVOut 6 - Clock / 64
CVOut 7 - Clock / 128
CVOut 8 - Clock / 256

So the above setup would give you a basic clock divider for driving sequencers.

Or an audio example maybe for 8 sets of 3 VCOs:

CVIn1 - 8 Pitch

DSP Running 8 sets of 3 oscillators

AudioOut 1 -8 Oscillator output fo each set

Or maybe a setup for filtering:

CVIn1 - Filter Freq offset
CVIn2 - Filter Q/Res offset
CVIn3 - FM 1
CVIn4 - FM 2

AudioIn 1-8 - 8 Different audio signals, each to be filtered by one chain

each chain having different filter, with two encoders for freq and res.

AudioOut 1-8 - 8 filtered inputs.

So really the Cobra is meant to do the following:

  1. Basic glue of the system
  2. Gui and input
  3. Control of DSP functionality
  4. Control of CV functionality
  5. Storage of setups
  6. Udp functionality for Open Sound Control
  7. CV Functionality (this is the bit I think the cobra may not be up to, I need to see how it is going to be able to handle serial DACS/ADC at a fairly high sample rate. OtherwiseI will just use some PIC24s to handle this controlled by the cobra).

Hope that makes some sense :slight_smile:

Cheers

Andy

17

Yes, it is perfectly good design to have a NETMF system with high end user interface. This will take all the hard high level work off your shoulders. Then a DSP is used to handle real time processing. FEZ Cobra has a lot of RAM so do not be afraid to use that RAM