We are having problems when trying to use the G400 on existing hardware that before ran fine with ChipworkX. One of our specific problems is that we can’t get the SD to work over SPI. We can get past:
_pse = new PersistentStorage("SD_SPI");
_pse.MountFileSystem();
without any exceptions, but as soon as we do something like (right after the mounting):
if (!Directory.Exists(@ "SD_SPI\System"))
Directory.CreateDirectory(@ "SD_SPI\System");
We are running firmware 4.2.11.0 on the G400 and used the ChipworkX development board and our custom hardware when testing - it throws the same exception on all hardware setups.
Any thoughts on why we would be getting this exception?
Basically we are just setting up our lcd configuration before instantiating the PersistentStorage object. I’ll try to create a new clean project with only the lines of code I showed in my first post to see if that makes a difference.
But _pse is a static member (class) variable - it’s made static to ensure the GC doesn’t collect it.
@ Architect -
Alright, the problem persists in a new clean .NET Micro Framework (4.2) console project containing the following:
using System;
using Microsoft.SPOT;
using GHI.Premium.IO;
using System.IO;
namespace MFConsoleApplication3
{
public class Program
{
public static PersistentStorage _pse;
public static void Main()
{
_pse = new PersistentStorage("SD_SPI");
_pse.MountFileSystem();
try
{
if (!Directory.Exists(@ "SD_SPI\System"))
Directory.CreateDirectory(@ "SD_SPI\System");
}
catch (Exception e)
{
Debug.Print(e.Message);
}
}
}
}
The exception is thrown when if(!Directory.Exists(…)) is called. If i remove the SD card from the hardware and run the program again, _pse = new PersistentStarage(“SD_SPI”) of course throws an exception (which shows that it does find the SD card, when it is inserted).
@ Architect -
We have tried that previously (and again now) but no difference unfortunately (we also left the 10 seconds sleep in there after the mount to make sure).
I also can’t get the G400 to work with SD_SPI either so I would also be interested to hear what the issue is and if there is a fix.
Having no ChipworkX in the catalog now means the G400 is the only option and it is far from being ready for mainstream use. This is not good when you have a working design based on the older module and the replacement is not ready or working stable enough.
In fairness being in beta means exactly that it isn’t ready to be a replacement yet.
I remember when Hydra first came out. I got in early on that one too. I had nothing but problems for months, and dealt with it because it was a beta, now Hydra is my go to device with Cobra II running in a close second (of 1st if I need premium).
Then you should give the option of the original until such time as the new one is ready for prime time. I don’t mind the Beta as I enjoy tech but when you can no longer get the original and the only option is a beta that still has issues it is not ideal.
I like what GHI offers and the support is first class but I am sitting with a half working design with a future order for more units just around the corner. It’s worrying. I loved the original ChipworkX as it was solid at the time I had to find a replacement for the dropped Sytech designs board. The switch to GHI was perfect. It was great as I could rework the board and get it out to the customer on time and they are happy with it. With the G400 I am getting nowhere fast.
This discontinuance of the ChipWorkX module may not have been within GHI’s control. I believe the module was actually manufactured by Embest, and is not longer available at low volumes.
G400 will be around fro very long years to come. Plus it is manufactured locally by us. We can remake it anytime in the future as we wish. We just ran a batch of Embedded Master! Anyone remember these?
