I considered that, but I'm afraid it would heat up my mini, and my mini doesn't like to get hot
Unless someone can confirm it won't harm the mini...?

It's all about the current - if you stay within 8mA (low-current LEDs, or just LEDs with not full brightness), it won't harm it - and your "transistor way" is also drawing the curent from the pins. There's actually LEDs that are like this internally (two LEDs antiparallel) and i've used lots of them with arduino, netduino, and other microcontrollers without releasing magic smoke

But the 'transistor-way', if the schematic is valid, could even use one PWM, and all 4 leds could use that one. I realized that after drawing out that schematic, that I just PWM ground, so it could contain all leds that need to have that brightness.

So I could use a shift register and have 8 outputs, and one PWM'ed Ground through a transistor, so all 8 leds will have the same brightness. Would that work?

I wouldn't call it a "PWM'ed Ground", but yes (you already mentioned that your schematic is incomplete though, needs some more resistors and wires )

Why don't you simply do it like this:

(Red and green LEDs antiparallel) - that way, if the GPIO is low, pulses on the PWM make the green LED light (higher duty cycle -> brighter), if the GPIO is high, it makes the red LED light (higher duty cycle -> darker).

Okay, a few wild shots to rule things out ... if you remove the 74hc595 and then connect the 3.3v rail to the places where its output legs are, do the LEDs light up? (just to rule out a problem with the wiring ...) Are you sure that you have a 74HC595 and not a 74HCT595 - can't read that on the images? (the latter needs a supply voltage >= 4.5V, you're providing 3.3V - nothing wrong when you use a 74HC595, but won't work with 74HCT595). If that's the case, you can try powering it via the 5V line - should work, but you're scratching the edge of the specs then (regarding signal voltage levels).

Can you take a picture of your setup, and post it along with the code you've used?

Now I understand that the Netduino firmware is not free, but it costs about US$3000. That's the half of the RVDS price...the other half is free because it can be compiled by GCC.

That is not a fair statement. The "free" as it's used in open source doesn't mean free as in "free beer", but as in "not in chains". It's unfortunate that there is no cost-free toolsuite to build it, but that is not because there are things that are "closed" or because you are tied to something, it's just because of not-(yet-)done effort in the cost-free compiler department, not something you can blame Secret Labs for, IMO.

Pardon my ignorance, but...what the h*ll does the RVDS that GCC is not able to do?
It looks about an half of the overall size, not a small percentage. How it can possible that RVDS is able to squeeze the code so far?
Thank you and good idea posting this kind of comparisons.
Cheers

What Cuno said, and in addition to that keep in mind that there is not as much "manpower" available for gcc for e.g. AVR or ARM targets as for x86.

Regarding the LED (stolen from http://nerduino.wordpress.com/)

public class Program
{
  private static Timer programLoop;
  private static Thread flasher;
  ...
  public static void Main()
  {
    ...
    programLoop = new Timer(timerDelegate, autoEvent, 1000, 60000);
    flasher = new Thread(delegate(){ doFlash(); });
    Thread.Sleep(Timeout.Infinite);
  }
  public static void doFlash()
 {
 OutputPort led = new OutputPort(Pins.GPIO_PIN_D13, false);

 while (true)
 {
 led.Write(true);
 Thread.Sleep(250);
 led.Write(false);
 Thread.Sleep(250);
 }
 }

}

With "stops running", you mean it stops sending requests, or it stops execution completely? Did you try pulsing the onboard LED in another thread to see if execution completely stops, or just the web part? Also, to check if it's connected to debugging, you could just "deploy" it from VS and then reset the board, without starting the debugger ...

Why do you want to use the tlc? IMO it does not make much sense to "step up" a constant current source ...

Just to make sure, your question is about a replacement IC for the tlc5940 that can drive your high-power LEDs?

No, that's not given. if you are between 0.2*VDD and 0.8*VDD (that is, 1V and 4V) it's neither "high" or "low", you're in unspecified territory - so it could be a 0 on a cold day, but a 1 on a warm day for example.

As a rule of thumb, you always want to connect the grounds of circuits you connect, unless you use something like optocouplers or relays. You also want to connect ground first, supply voltage second, and then the data lines.

So, I found out that I can't trust the VS output, because I just updated and the pulse went away, but it still says 4.1.0.0 Found out the proper way to find the version out now but it's too late ... and iukpo uses 4.1.0.6 as well so he shouldn't have the pulse.

Okay, something odd. To the left is my netduino+, to the right my regular netduino, same code, both 4.1.0.0 if I can trust the VS output ("Assembly: Secretlabs.NETMF.Hardware.Netduino (4.1.0.0) ...").
The regular netduino has the additional clock pulse before CS goes down ... I don't have a mini, so I can't check that.

When you send the contents of the file, you send the file HTTP is a protocol many clients speak, not just browsers (for example, http://gnuwin32.sour...ckages/wget.htm is a small commandline utility that can download files over http, . You can also tell a browser to "download" the file and not show it in its own window by sending a Content-Disposition header in the HTTP response. Now, if you wanted to serve multiple files, with a file-explorer-like interface, that'd be a different story, but if you just want so save one file, i'd leave the part on the netduino as-is and just use a tool on your computer to download it.

Go here and read "Introducing the .NET Micro Framework" and "Porting the .NET Micro Framework". Those must be quite still valid if they are on the main .NETMF site. Don't they?

Let's look on some of them:
[snip]

This still gives no guarantees. It describes the current implementation, as Corey says. It's like the code in http://en.wikipedia....iew_of_the_code - this works (on a specific subset of machines), but it is based on assumptions that are not guaranteed by the language, so a program containing it does not neccessarily work on other implementations.

That '.NET MF is "cooperative-ish-ly multitasked." So IL instructions are executed individually.' was already stated in the very first reply from Chris, but the follow-up question is if it's guaranteed, and I have seen no guarantee to that point.

FTP is far harder to implement than HTTP, for no real gain ... why do you think HTTP is clumsy?

I have not looked, does anyone know if the System.Threading.Interlocked class is supported in the MF?

It is, see
http://msdn.microsof...y/ee434385.aspx
and
http://blogs.msdn.co...ronization.aspx

There is nothing in your text (that is also outdated) that says anything about additional guarantees, georgejh.

The Vin pin on the shield goes to a voltage regulator, that outputs ~3.8V, while the 5V and 3.3V pins are not connected on the shield. So you *have* to power it via vin. It's a low-drop regulator, so it's normal that it works with 5V (as Vin would be 5V also when the (net/ar)duino are powered via usb. However, it should also work fine if you connect +9V to it ... http://www.sparkfun.... shield-v12.pdf shows you which pins are connected (top right of the schematics).

Yeah, there are no breaks long enough, but i definitely see the clock pulse that you don't see - not at home to check the firmware version though (also, was a regular netduino). The clock select, if used, goes low about 10µs after the pulse on the clock line if I recall correctly ... However, I have to disagree with you on one thing: "But there's no reason that 2MHz shouldn't work." - since the pullup on the HV side of the logic level converter is fairly weak, high rise times can become an issue (nothing one can't fix, but during debugging i'd keep to low clockrates and then increase the rate when it's working)

If you use the "Deploy" option, you have to reboot the netduino by pressing the button on it - I don't know why VS does not do that by default.

I just noticed something odd ...

I made a testcase and hooked up the MOSI and SPCK pins to my scope, and got this:

(yellow clock, cyan data)


There is a 40µs pulse on the clock line that serves no purpose as far as I can tell ...
Does someone have an idea why this happens?

This won't have an effect if one writes all data at once, but if you write in groups of 3 bytes, this pulse will mess your data up. (data sent is 170,0,255 - 10101010,00000000,11111111 as bit patterns)

Used configuration:

SPI(new SPI.Configuration(
                Pins.GPIO_NONE,
                false,                  // SS active-low (irrelevant)
                0,                      // No SS setup time(irrelevant)
                0,                      // No SS hold time(irrelevant)
                false,                  // Clock low on idle (so it will be low for 500µs after transmission, which triggers the output of the leds)
                true,                  // Data valid on rising edge
                100,                   // 2kHz clock rate (allows for 500µs between writes)
                SPI.SPI_module.SPI1     // SPI device 1
                )
            );/**/

You don't need the SS pin, why do you define it as pin 13?

Your postData is a mess ...

What is the point of this?

            for (int k = 0; k < 24; k++)
            {
                _data.Write(writeBuf);
            }

You're writing the same buffer 24 times?
As has been already stated, don't use multiple writes for each LED - use one buffer, write it, and be done with it ... this means a single Write call for updating the whole LED strip, no loops involved. The way you do it, there will be seemingly random delays between writes which will sometimes cross the 500us boundary and sometimes not, which will result in odd behaviour ...

I might be doing something wrong, so let me ask if I have this part at least right:

1) For the LV input, I have designated Pin 5 (AD0). For the GND for LV, I am using Pin 4.
2) I have an infinite thread that is just constantly writing true via OutputPort on Pin 5. This should generate a constant 3.3V signal.

There is no point in "constantly writing true". You set it high once and then leave it at that ...