gadgeteer Issue Tracker Rss Feed

Closed Issue: Can't create project from templates [356]

jamesscott — Thu, 16 May 2013 11:26:39 GMT

When trying to create a project from the .NET Gadgeteer Builder Templates, I get an error stating that "The project file "C:\users\<user>\AppData\Local\Temp\grow0usuxs.vqi\Temp\GadgeteerApp1.csproj' cannot be opened. The project type is not supported by this installation."

Is there another way to create a Gadgeteer application?

Thanks, Ronald.

Closed Feature: Proposed change to LCD part of Mainboard API [472]

jamesscott — Thu, 16 May 2013 11:26:38 GMT

Hi,

This is an open discussion on proposed API changes in GadgeteerCore's Mainboard API. This discussion is targeted at mainboard and LCD display vendors since it affects the mainboard and LCD display drivers. The proposed change would happen on transition to NETMF 4.2. GadgeteerCore for NETMF 4.1 will continue to use the existing API to ensure compatibility.

Status quo:
GadgeteerCore DisplayModule.cs currently takes care of rebooting the device when a display change occurs, such reboots are necessary to ensure that the LCD controller is properly configured. The reboots are done whenever the LCD controller enabled/disabled status changes, or whenever the SystemMetrics height/width does not match the LCD configuration height/width desired (and either and LCD or WPF is used).

Problems:
1) LCD rotation is not supported
2) Checking height/width alone is not good enough - the whole set of Mainboard.LCDConfiguration values should be checked
3) The current code is too conservative and reboots when reboots are not required, e.g. when the LCD controller is not used by a program, but the LCD sockets (R,G,B) are not reused for any other purpose - disabling the LCD controller is not necessary (it does not affect the user program if it is left enabled, and is just annoying)
4) GadgeteerCore does not necessarily know when a reboot is required as this is mainboard specific. E.g. on Fez Spider, LCD rotation does not need a reboot but on Nano, it does.
5) The Mainboard.LCDConfiguration class is oriented towards supporting the LCD controller on the first available mainboard, the Fez Spider, but it may be missing one or more settings necessary for other LCD controllers.

Solutions proposed:
a)
In each Mainboard's driver class, the implementation of
public abstract void SetLCD(LCDConfiguration lcdConfig);
should reboot the mainboard IF NECESSARY (i.e. if any of the settings change in a way that requires a reboot to take effect).
Also this will be renamed to
public abstract void SetLCDConfiguration(LCDConfiguration lcdConfig);
to disambiguate with SetLCDRotation (below).

b)
In the Gadgeteer.Mainboard API, to add a call
abstract bool SetLCDRotation(GTM.Module.DisplayModule.LCDRotation rotation)
(where the LCDRotation enumeration specifies the four possible rotations, Normal, Clockwise90Degrees, UpsideDown, Counterclockwise90Degrees):
return value: true if the rotation is supported, false otherwise.

Note that this call will NOT be at constructor time (which is when SetLCDConfiguration is called) - it will be later. This is because we cannot pass parameters (other than the socket number(s)) to constructors using the designer. We will add a method in DisplayModule.cs that end users can use, e.g. in ProgramStarted, which will pass the setting down to the mainboard driver and debug print an error message if the rotation is not supported. This will also check if WPFWindow has been used already, and debug print an error message if so (rotation must be called first before WPF is used since otherwise the systemmetrics width/height and hence the window size are wrong).
public virtual void SetRotation(LCDRotation rotation)

The mainboard driver is also responsible for rebooting if necessary during this call (as for the above call).

c)
DisplayModule.cs in GadgeteerCore will be modified to ONLY call Mainboard.SetLCDConfiguration if the new display configuration is absolutely needed. E.g. if the user program instantiates an LCD-based display module, or uses WPF on any display, or reuses an LCD controller pin as a GPIO (which requires the LCD controller to be disabled). However, if the user does not use an LCD, WPF or use the LCD controller sockets, then Mainboard.SetLCD will NOT BE CALLED - this means that the LCD controller will remain configured in its old state, but since the user is not using it, that's fine.

d)
In the Mainboard.LCDConfiguration class, we might want to add new settings to cope with features available on other LCD controllers. Note that each settings should have a good "default" in case an LCD controller is not capable of using it. Please propose settings if you see a need to support current/future LCD controllers.

It is important that we get this (and any other GadgeteerCore API changes) right before a GadgeteerCore release for NETMF 4.2 is finalised, since we are very averse to API changes (other than additions if really necessary) since they would break compatibility with any programs/module/mainboard drivers.

Ta
James

Closed Issue: SerialPort.ReadLineProcess Exception Issue [530]

jamesscott — Thu, 16 May 2013 11:26:38 GMT

hello

i use socket type u on a ghi gadgeteer board to communicate through rs232 with a synapse wireless module (pin 4 and 5)
pin 3 is used to have the possibility to reset the synapse module (active low) if the module hangs

what i would expect is no exception when the serial port is closed

the important code part and the result is attached

gadgeteer core version 2.41.500.0
framework version 4.1.2821.0

br
Andre

Closed Issue: Visual designer will only auto connect modules to a mainboard [707]

JanKuceraMSFT — Thu, 09 May 2013 05:37:24 GMT

This applies to both daisylink modules and modules that provide other standard connectors.
Comments: Fixed in the upcoming version.

Closed Issue: Impossible change the Default Web Event [1416]

JanKuceraMSFT — Thu, 09 May 2013 03:57:00 GMT

WebServerManager DefaultEvent property is not accessible from the application code.
Comments: Fixed in the upcoming version.

Closed Issue: Can't create installer for Gadgeteer Module [1424]

JanKuceraMSFT — Tue, 30 Apr 2013 23:52:34 GMT

I'm trying to create a module and have gone through all the steps and debug testing as outlined on the Module Builder's guide, but when I try to create a release no installer files are generated. I've using the following:
Microsoft .NET Micro Framework v4.2
Microsoft Visual C# 2010
Wix Toolset 3.5 has been installed

After build, the bin\Release folder contains the following:

be folder
le folder
.dll file
.pdb file
.XML file

but no installer files. Any suggestions?
-Cam
Comments: No follow-up, and we had new release since then, try it. If you need troubleshooting use the Discussions tab. If you still experience the problem with the latest release, post a comment and we can re-open the issue.

Closed Issue: GHI Music Module producing index out of range error [758]

JanKuceraMSFT — Tue, 30 Apr 2013 23:45:50 GMT

I have been producing a simple piano application that allows users to tap the screen and for a recorded MP3 file representing the appropriate note to be played via the Music Module. These files are loaded from the SD card into separate byte arrays at runtime. However, when I try to play them I occasionally get the following error, especially if they one sound had not finished playing:

#### Exception System.ArgumentOutOfRangeException - CLR_E_OUT_OF_RANGE (6) ####
#### Message:
#### System.Array::Copy [IP: 0000] ####
#### Gadgeteer.Modules.GHIElectronics.Music::PlayBackThreadFunction [IP: 002d] ####
#### Exception System.ArgumentOutOfRangeException - CLR_E_OUT_OF_RANGE (7) ####
#### Message:
#### System.Array::Copy [IP: 0000] ####
#### Gadgeteer.Modules.GHIElectronics.Music::PlayBackThreadFunction [IP: 002d] ####
#### Exception System.ArgumentOutOfRangeException - CLR_E_OUT_OF_RANGE (8) ####
#### Message:
#### System.Array::Copy [IP: 0000] ####
#### Gadgeteer.Modules.GHIElectronics.Music::PlayBackThreadFunction [IP: 002d] ####
#### Exception System.ArgumentOutOfRangeException - CLR_E_OUT_OF_RANGE (9) ####
#### Message:
#### System.Array::Copy [IP: 0000] ####
#### Gadgeteer.Modules.GHIElectronics.Music::PlayBackThreadFunction [IP: 002d] ####
A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
An unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll

An unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll

Commented Issue: GHI Music Module producing index out of range error [758]

JanKuceraMSFT — Tue, 30 Apr 2013 23:45:45 GMT

I believe this belongs here... if it gets here. :-)

gus_ghielec wrote Apr 20 at 1:25 AM

Have you tried this with latest SDK from GHI? IF you still have any issues please post on our forum so we can help you quickly http://ghielectronics.com/community/forum/board?id=21

Closed Issue: Using multiple displays [1455]

JanKuceraMSFT — Tue, 30 Apr 2013 23:44:37 GMT

A display module today sets the internal config (x and y size for example) even on basic displays to allow for WPF to be used. This will be a problem if the displays are of different sizes. It will simply not work.

An option would be for simple displays to not support WPF but then this breaks the compatibility between displays.

A solution would be to drop support to WPF but keep simple graphics maybe?

In reality, there will never be more than one RGB socket type display as the processor only has one display controller. But there will be more than one S socket display...or a RGB and S together. So it is possible to support WPF on RGB but not on S sockets. Teh only problem is the possible confusions

Thanks

Gus - GHI Electronics
Comments: Fixed in the upcoming version.

Commented Issue: optimize for low memory graphics [1456]

JanKuceraMSFT — Tue, 30 Apr 2013 23:40:20 GMT

The smallest gadgeteer mainboards today, like Mountaineer and Cerberus can support every single gadgeteer feature, including graphics. The only part that requires attention is graphics. To flush a 128x128 display, NETMF uses 4byte per pixel (we requested this to change in NETMF core) and then this need to be changd to 2byte to send to the display.

The required memory is
128x128x4 + 128x128x2 = 96KBytes! This is nothing to devices with megabytes of RAM but the smaller devices have very limited memory, not even enough to display that one image! What we do now is display the image in parts, 32x32 pixels at once for example.

What can be done to shrink the used memory?
1. Only include the needed assemblies. Like do not add touch when the display does not support touch.
2. Drop WPF support
3. add native code to convert bitmaps and change bitmaps to 2bytes. This needs to be done on NETMF side.

Thanks

Gus - GHI Electronics
Comments: ** Comment from web user: JanKuceraMSFT **

Sorry Gus, now I got how you misposted that reply, it really does not want to be posted there! :-)

For this issue:

1. Removed with #748.
2. Not going to do that, sorry. It will not help either, as the Dispatcher that is in TinyCore is needed to run pretty much of the Gadgeteer.
3. They are already there. As a manufacturer, you can take advantage of them. I will try to discuss with .NET Micro Framework team whether we could make it available to the managed code.
4. If nothing else, reuse your buffer and save 32K!

Reopened Issue: optimize for low memory graphics [1456]

JanKuceraMSFT — Tue, 30 Apr 2013 23:37:29 GMT

Closed Issue: optimize for low memory graphics [1456]

JanKuceraMSFT — Tue, 30 Apr 2013 23:37:15 GMT

Closed Issue: LCD config [1457]

JanKuceraMSFT — Tue, 30 Apr 2013 23:34:21 GMT

The LCD config works great for any display but the problem is that the config has one field fro clock divider. This field is dependent on the mainboard plus the module does not know the source clock to set the divider. It is impossible today to write a display driver that will work on any mainboard.

Please replace this field with clock frequency. We have done the same change on our libraries and it has been working great for any display.

Thanks

Gus - GHI Electronics
Comments: Fixed in the upcoming version.

Commented Issue: Switch source repository to Git [1544]

dcazzulino — Mon, 29 Apr 2013 17:53:16 GMT

This would make it much easier to contribute! Now that Codeplex supports Git, why not? ;)
Comments: ** Comment from web user: dcazzulino **

You can explore how the fork+pull request model works by seeing just how much activity Arduino has: https://github.com/arduino/Arduino/pulls

Again, not saying it's magically going to bring in more people, but svn and patch files are not the "brave new way" of contributing ;).

Here you can see how another Microsoft project is seeing more engagement from the community by using Git on Codeplex: https://rx.codeplex.com/SourceControl/BrowseLatest

They have 28 forks and 12 pull requests so far, many of which have been applied to the code base.

I firmly believe the fork+pull model of git makes a lot more sense than svn+patch files. I for one have stopped installing TortoiseSVN years ago...

Commented Issue: Switch source repository to Git [1544]

dcazzulino — Mon, 29 Apr 2013 16:16:46 GMT

This would make it much easier to contribute! Now that Codeplex supports Git, why not? ;)
Comments: ** Comment from web user: dcazzulino **

Fork & send pull requests is way more effective and proven.

And you don't even have to leave Codeplex! The support TFS, subversion, mercurial AND git for source control.

I've migrated a couple of projects of mine and they even preserve the commit history...

A lot of successful open source projects are migrating away from "old style" svn/cvs to git (note, git != github, just like cvs != sourceforge)

Commented Issue: Switch source repository to Git [1544]

JanKuceraMSFT — Mon, 29 Apr 2013 15:58:41 GMT

This would make it much easier to contribute! Now that Codeplex supports Git, why not? ;)
Comments: ** Comment from web user: JanKuceraMSFT **

Why should we? You know, start with a -100 score. In which way Git would enable to contribute you that is now more difficult on CodePlex?

Created Issue: Switch source repository to Git [1544]

dcazzulino — Mon, 29 Apr 2013 15:26:27 GMT

This would make it much easier to contribute! Now that Codeplex supports Git, why not? ;)

Commented Task: Remove pin reservations [1539]

gus_ghielec — Sat, 27 Apr 2013 13:55:51 GMT

When addressing the issue [526](https://gadgeteer.codeplex.com/workitem/526) (pin reservations should be undoable), we revised the rationale behind pin reservations and benefits it gives to the users and concluded that this functionality is no longer necessary.

The pin reservation is intended to prevent users connecting modules in a way that some of them needed to use the same CPU pins. When this happens, an exception is thrown at runtime telling the user that another module is already using the pin requested. This functionality was introduced before the designer was written - nowadays, the designer does the checking at design time and makes it impossible to connect modules so that the pin reservation process would kick in.

Moreover, the underlying .NET Micro Framework itself is doing pin reservations, so we are just duplicating this functionality for an error message with module name in it, for scenarios that we already consider advanced (building .NET Gadgeteer applications without the templates and the designer).

So, we can either add another code to the core (and each interface) to make the unresevations work as expected and support the pin sharing that the designer already handles, or we can just remove the functionality completely.

Given that every improvement in the footprint, memory and performance counts, __I propose to drop pin reservations from the Gadgeteer core__.
That would be for .NET Micro Framework 4.3 projects only. Existing projects using the designer would work just fine, hardware manufacturers would need to update constructors of their module drivers for 4.3.

I encourage anyone that would be unhappy with this change to comment below.
Comments: ** Comment from web user: gus_ghielec **

This is okay with us, especially that our mainboards very rarely share pins.

Gus - GHI electronics

Closed Issue: Unnecessary references included in templates [748]

JanKuceraMSFT — Thu, 25 Apr 2013 18:18:21 GMT

The templates for a Gadgeteer 4.2(and prossibly 4.1) application includes references that should not be included by default. These references should be added by modules that will actually use the references.

Examples include:
Microsoft.SPOT.Touch(useless without touch capable display)
Microsoft.SPOT.Graphics(useless without network or display)
Microsoft.SPOT.Hardware.Serial(useless without a "U" capable module)
System.HTTP(useless without network)

On bigger boards including unnecessary references isn't much of a problem, but on smaller boards, like the Cerberus or Mountaneer boards, ram becomes a problem and loading unnecessary references wastes ram.

Thus only the bare references should be included in the templates, and modules that require references should declare that requirement, and add the references to the project.
Comments: Fixed in the upcoming release. Removed:
Microsoft.SPOT.Hardware.SerialPort
Microsoft.SPOT.IO
Microsoft.SPOT.Net.Security
Microsoft.SPOT.Touch
System
System.Http

There is no point in removing Microsoft.SPOT.Graphics as the core is already using that one, so it gets deployed to the device anyway. Removing it from the template would just lose the smart tag user experience for classes in it.

Commented Task: Remove pin reservations [1539]

Cuno — Thu, 25 Apr 2013 11:06:56 GMT

Good idea. Not unhappy at all.