Illishar's Content

#11271 coding style discussion

Posted by Illishar on 25 March 2011 - 07:53 AM in General Discussion

As a experienced pro programmer, I'd like to join the group that despises the "var" keyword. It might be compile time typesafe, but it's still an abomination. (Among others it makes the code less readable I think)

#10550 Netduino Plus / AT91SAM7X-EK compatibility

Posted by Illishar on 04 March 2011 - 03:31 PM in Netduino Plus 2 (and Netduino Plus 1)

The NutOS works perfectly, without any tweaks. (Has a full ethernet stack.)

#10549 Compiling netmf with GCC4.2

Posted by Illishar on 04 March 2011 - 03:20 PM in Beta Firmware and Drivers

For building SPI stuff, I'd recommend not messing with custom firmware. (If you can avoid it.) The best compiler you can get is the RVDS compiler. The newer GNU (gcc 4.5) is not bad either though. The issue with netmf is that it's only officially supported by gcc 4.2. Which isn't that impressive. (You'll get too big images.) This issue is enhanced by the fact that neither Microsoft nor Secret Labs are putting much efforts into supporting GNU. The question about image sizes is only really important on very small boards (like the Netduino). The rest of the world has plenty of storage space. (No one has ever complained about the GNU image size on eg. *nix.) A block btw, is often used for defining the minimum write size on a flash. In this case it's 8k. (I think the Atmel blocks are really 256b though. Meh, who cares.) Btw, Secret Labs are planning an upgrade to ease custom firmware. So that we won't have to buy RVDS or recompile the whole netmf.

#10548 Reset

Posted by Illishar on 04 March 2011 - 02:59 PM in Project Showcase

Oh, sry for not answering. Yes, the Register class is custom firmware that gives direct access to the memory: http://forums.netdui...afe-port-access And this reset method is just a proof of concept. It doesn't call the builtin .NET MF reboot. It makes the processor reboot by calling the builtin registers directly. (It's an actual low level reset.)

#9541 Runtime Native Code Interop

Posted by Illishar on 14 February 2011 - 06:18 PM in General Discussion

Can you provide more detail about what you're referring to or post a URL to what you were reading?

The following is not one of my 'readings' but it does hint at the issue: http://infocenter.ar...aqs/ka3698.html

It also states however that it *is* possible to create pic. Both with THUMB and ARM. And it gives away that the RVDS compiler has solved the issue.
We however, have to make it work with GNU. I'll see if I can dig up my other source.

#9511 Additional UARTs

Posted by Illishar on 14 February 2011 - 08:23 AM in Netduino 2 (and Netduino 1)

The Netduino might a 3rd uart somewhere. The Netduino COM1 is actually the dbgu. Uart0 is the COM2. The uart1 is at PA4 and PA5 I think.

#9510 Software reset

Posted by Illishar on 14 February 2011 - 08:19 AM in Netduino 2 (and Netduino 1)

And the watchdog is really easy to create with "runtime interop" btw. (And rather well suited.) Just tell me and I'll throw it up for you!

#9508 Netduino firmware roadmap

Posted by Illishar on 14 February 2011 - 08:15 AM in General Discussion

The v4.1.1 seems somewhat deja-vu? Meh. Great stuff! Netduino Updater? Like the Tahoe? What's wrong with the MFDeploy? Btw, Jan Kučera from microframwork.eu has made a universal config tool: http://informatix.mi...rationTool.aspx The 'Runtime interop' will really enable us to create great stuff. Like eg. Option 3 (for saving custom config).

#9507 Runtime Native Code Interop

Posted by Illishar on 14 February 2011 - 08:07 AM in General Discussion

This is a great thread! I've been working with this subject for some time now

Btw in regards to the ARM/THUMB issue. From what I've read, ARM codes can be compiled as PIC/PIE. THUMB cannot. (Might be worth considering.) If you cannot compile the code as position independent, you'd have to preallocate a fixed size flash area for the potiential native code. (Would still be worth it.)

#9506 SoftwareSerial library needed/equivalent in Netduino

Posted by Illishar on 14 February 2011 - 07:48 AM in General Discussion

There might be a 3rd uart as well, on the Netduino. (Since the COM1 is actually the dbgu.) Might not be exposed though.

#9338 Generics in NETMF

Posted by Illishar on 12 February 2011 - 08:21 AM in General Discussion

It might be safe to state that, it's rather unlikely ever to implemented on small devices like the Netduino. Sadly.

#9321 FreeRTOS

Posted by Illishar on 11 February 2011 - 12:06 PM in Netduino Plus 2 (and Netduino Plus 1)

Cool

#9264 Reset

Posted by Illishar on 10 February 2011 - 04:29 PM in Project Showcase

I've implemented a small sample that shows how to reset the processor through direct register access. And it works ... only problem is that the usb/debug driver doesn't boot up after reset. Hmmmm ...

Attached Files

NetduinoSoftReset.zip 8.37KB 44 downloads

#9261 Direct (unsafe) port access

Posted by Illishar on 10 February 2011 - 03:29 PM in Project Showcase

Well, I still can't get the managed version to work. But I've implemented the native Register class suggested by CW2. I've attached a sample that will toggle the LED through the Register class. (I found several errors in my previous code as you pointed out.) I've also attached a patch for the netmf containing the Register class. And I've attached the netmf binary. And I've attached the Register source. As CW2's implementation this doesn't contain any address validation. Full Control! CRASH AND BURN!

Attached Files

NetduinoNativeRegisterTest.zip 16.72KB 26 downloads
RegisterPatch.zip 16.32KB 27 downloads
Netduino4.1.0.a5_modded.zip 352.44KB 28 downloads
Netduino_Contrib_Register.zip 27.56KB 24 downloads

#9258 Compiling netmf with GCC4.2

Posted by Illishar on 10 February 2011 - 09:32 AM in Beta Firmware and Drivers

Hello there,

Just a small info (yet another) to those who wants to compile the Netduino source.

- Start compiling with the CodeSourcery (GCC 4.2) compiler, which is supported by Microsoft.
- To make it compile, you most likely need to edit the memory layout. This is due to changing and different compiler outputs.
- The files are:
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\scatterfile_tinyclr_gcc.xml
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\DeviceCode\Blockstorage\Sam7X_blockstorage\Sam7x_Bl_Config.cpp

In the sam7x file you'll find this:

const BlockRange g_SAM7X_BS_BlockRange[] =
{
    { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 },		
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_BOOTSTRAP,  6, 14 },		
    { BlockRange::BLOCKTYPE_CODE            , 15, 44 },		
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_CODE     , 45, 46 },		
    { BlockRange::BLOCKTYPE_DEPLOYMENT      , 47, 60 },		
    { BlockRange::BLOCKTYPE_STORAGE_A       , 61, 61 },	
    { BlockRange::BLOCKTYPE_STORAGE_B       , 62, 62 },	
    { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }
};

Which doesn't fit when using GCC4.2. If you look at it it will tell you, that the BootLoader will take up either 6 blocks (RVDS) or 15 blocks (GCC). This is mostly correct. However depending on what you're trying to do, the BootLoader might not be of interest to you. The TinyCLR is. Which means that you can keep your SecretLabs compiled RVDS BootLoader (much smaller) and combine it with your own TinyCLR.

I've therefor changed my setup to this:

const BlockRange g_SAM7X_BS_BlockRange[] =
{
    //
    { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 },		//  ~50k (RVDS BootLoader)
    { BlockRange::BLOCKTYPE_CODE            ,  6, 49 },		//  ~360k = 0x0C000
    { BlockRange::BLOCKTYPE_DEPLOYMENT      , 50, 62 },		//  ~106k = 0x64000
    { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }
};

Depending on the size on your TinyCLR you might have to alter the CODE and DEPLOYMENT addresses.
Yes, I've removed the STORAGE_A and B. They're official areas in the netmf, but they're not currently in use by the Netduino.

When you've made this change, you also need to adjust the scatterfile. This is what I use:

    <Set Name="Heap_Begin"      Value="0x00010000"/>
    <Set Name="Heap_End"        Value="0x00017FF8"/>
    <Set Name="Stack_Bottom"    Value="0x00018000"/>
    <Set Name="Stack_Top"       Value="0x0001FFF8"/>

    <If Name="TARGETLOCATION" In="FLASH">
        <Set Name="Code_BaseAddress"    Value="0x0010C000"/> <!-- This is start TinyCLR -->
        <Set Name="Deploy_BaseAddress"  Value="0x00164000"/> <!-- This is start app code -->
        <Set Name="Code_Size"           Value="%Deploy_BaseAddress - Code_BaseAddress%"/>
        <Set Name="Config_BaseAddress"  Value="0x0017E000"/>    
        <Set Name="Config_Size"         Value="0x00002000"/>
        <Set Name="Valid"               Value="true"/>
    </If>

Notice that the Heap and Stack is only using half of the ram? Yeah ... fancy that.

If you make it compile then just open up your MFDeploy and flash your own ER_FLASH and ER_CONFIG. They're placed in:
C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.hex\

#9222 Trouble when compiling with Code Contracts

Posted by Illishar on 09 February 2011 - 01:43 PM in Beta Firmware and Drivers

Hello, Just a small observation: If you have Microsoft Code Contracts installed on your computer, it might give you trouble when compiling the netmf PK. Odd, but there you have it.

#9220 Netduino Plus Firmware v4.1.0 (update 6) RC 1

Posted by Illishar on 09 February 2011 - 12:34 PM in Netduino Plus 2 (and Netduino Plus 1)

Hello Chris, I've tested out the Build1, Build2 and Build3. Only the Build3 seems to work. I haven't tested Build4 and Build5 since they seem to be variations of Build3. I have another small observation though. When I disconnect the debugger the application seems to stop. Maybe that's intended though, I'm not sure.

#9109 Direct (unsafe) port access

Posted by Illishar on 07 February 2011 - 11:16 AM in Project Showcase

My first attempt with a managed version doesn't seem to work:


    public unsafe class Processor
    {
        /// <summary>
        /// Write directly to memory. (Meant for port access)
        /// </summary>
        /// <param name="reg"></param>
        /// <param name="val"></param>
        public static void Write(uint reg, uint val)
        {
            *(uint*)reg = val;
        }

        /// <summary>
        /// Read directly from memory. (Meant for port access)
        /// </summary>
        /// <param name="reg"></param>
        /// <returns></returns>
        public static uint Read(uint reg)
        {
            return *(uint*)reg;
        }
    }

It's a pity. It would have been an easy fix. Maybe the .NET assemblies have their own memory space or something. I'll give it a try with your unmanaged version, I think.

#9107 Netduino Plus Firmware v4.1.0 (update 6) RC 1

Posted by Illishar on 07 February 2011 - 10:12 AM in Netduino Plus 2 (and Netduino Plus 1)

The 4.1.0a5 still seems to work. Phew! I was starting to panic.

#9106 Netduino Plus Firmware v4.1.0 (update 6) RC 1

Posted by Illishar on 07 February 2011 - 10:03 AM in Netduino Plus 2 (and Netduino Plus 1)

Wait, I'm not the only one that has it, it seems: http://forums.netdui...firmware-to-411 You sent some other fw to him. I need it as well!!!! OMG!

#9105 Netduino Plus Firmware v4.1.0 (update 6) RC 1

Posted by Illishar on 07 February 2011 - 09:44 AM in Netduino Plus 2 (and Netduino Plus 1)

Something is wrong here. I'm unable to get the Netduino Netmf working. I've tried both the 4.1.1a6 and the 4.1.0a6. My board has lost its ability to reboot or something. Whenever I want to debug an application from within VS it just hangs. VS says something like "Board not in a initialized state. Rebooting". After that the Debug-channel also says "Rebooting...". And nothing happens. If I pull the plug (and reinserts it) the debugger will catch it (if lucky) and the debuggin will start. When I stop the debugging, the uploaded program will also stop. (It ought to continue though) Any ideas? I've attached my test program. Edit: Btw nothing is attached to the board besides the usb. Edit: Here's also a thing: If I connect to the board with MFDeploy and uses the "Reboot CLR" the board will also hang.

Attached Files

NetduinoTest.zip 76.61KB 3 downloads

#9104 Netduino Plus Firmware v4.1.0 (update 6) RC 1

Posted by Illishar on 07 February 2011 - 09:15 AM in Netduino Plus 2 (and Netduino Plus 1)

A small observation: Whenever I flash the fw, the process never finish. - I flash the TinyBooter with SAM-BA. Works fine. - I flash the ER_CONFIG & ER_FLASH with MFDeploy. Both works fine. But after the upload a dialog appears saying "Deployment Status", "Executing Application". And it never gets on from there. It just hangs. It has always been like that, from day 0.

#9103 Fluent Interop 1.6

Posted by Illishar on 07 February 2011 - 08:16 AM in Project Showcase

It's getting almost readable now. Very nice.

#9070 Direct (unsafe) port access

Posted by Illishar on 06 February 2011 - 04:50 PM in Project Showcase

I'm doing some brainstorming with direct port access, from within the Netmf. I don't yet know if it's possible. The theory is sound though. If we can access the native ports (mem access), we'll be able to create 'native' drivers, without messing with the native fw. This ofc will not be performance friendly, but then again, many functions/drivers don't need performance. And these 'Managed native' drivers won't take up space in the fw, when not in use. (Cool) The attached project has not yet been testet. (My board is currently out of reach.) This is just work in progress. (Using the forum as a mid way storage

Attached Files

NetduinoUnsafe.zip 6.13KB 37 downloads

#8992 12-Bit ADC Measurement using MCP320X chips and SPI

Posted by Illishar on 04 February 2011 - 01:01 PM in Project Showcase

The samplerate will be 20Kz in the project i'm doing. Is that a problem for the Netduino?

20k Hz might be a bit much for netmf. You'd most likely have to implement a native driver at least. (I'm sampling at 25k Hz in native code though.)