Main Site Documentation

The release of SDK Package 2013 R2 with socket indirect


#1

Introducing Socket Indirect!

Socket indirect is here but what is socket indirect? This all new Gadgeteer feature allows for modules to consume sockets, just like before, but they now can supply sockets. Take the new Hub AP5 module for example. It consumes one I socket but then it provides eight indirect sockets, in which five sockets are PWM capable and two are Analog capable. What makes this extra useful is that the Gadgeteer core handles all the work for you. Direct or indirect, you will be using the modules the same way you always did.

This gets even better as you can chain sockets! Take the S-Plus module for example. It consumes two sockets, S and Y but then it provides and extra S socket. But what if you need four S sockets (SPI sockets). All you need are three S-Plus modules, where you connect two of them to the third one and now you have 4 S-type sockets using one S-type socket on the mainboard, plus the 'Y sockets needed for other IOs.

Improving the Cerb-family Graphics Library!

We have made changes on the firmware to allow it internally to flush directly to the display. This made a significant difference on these RAM-limited devices. We also reworked the non-Ethernet firmware to add another 24KB to the heap. This is about a 25% improvement of free memory. What does all this mean? You can now use WPF and Glide on N18 display using any of the Cerb-family devices, Cerberus, Cerbuino, Cerb40 and Cerbot. This change also significantly improves performance.

The FEZ Game-O Firmware!

FEZ Game-O inherits the Cerb-family firmware, meaning it also supports the same direct internal graphics we mentioned above. This allows you to draw on the display very easily in its default mode, 160x120. We also added a DLL that provides direct access to few internal methods to get the full 320x240 pixels.

Increased stability!

In this release, we covered some very difficult bugs, some for networking and some caused system crashes. While they may seem not so difficult, we spent long weeks working with the community on solving them. We thank the community for all the work they did to help us find and squish these bugs.

To be LCD or not to be!

We have decided to default the LCD pins on our System on Modules (SoM) to GPIO on power up. They only become LCD signals when setting the LCD configuration. This is a required change for those that use the pins as GPIOs. The down side is that you will not see anything on the display on first power up, until the display configurations are set, either through software or using the FEZ Config tool. This change has made it to G120 and EMX and will be incorporated in G400 in the next update.

G400 SD compatibility with ChipworkX

SD on G400 now works on the actual SD pins but also now supports SPI for backward compatibility with ChipworkX. Devices that run SD with ChipworkX module can now upgrade to G400-D and still be able to use SD without any changes. We recommend using the SD interface over SPI in all new designs.

The SDK versioning and previous releases!

We have a made few changes on the website to make it easier to find specific SDK versions and to make versioning easier. The SDK will be released in the form of 2013 R1 and when updated it will show 2013 R1 Update1. All versions will always be available at https://www.ghielectronics.com/support/.net-micro-framework/sdks

If you need to lock your setup to a specific SDK, you will only need the one link that points to the version you need, for example, this is a direct link to this release (add here) which also shows the release notes and known issues. Please note that your community-rank will limit your access to beta releases and updates. Major releases are open to everyone after logging in.

We hope all these free updates are satisfactory and we look forward to providing even more in the near future.


#2

Great improvements! Thank you.


#3

Great!!

One thing: the release notes say:

[quote].NET Gadgeteer

Built With

Microsoft .NET Micro Framework v4.3 (RTM)
GHI Electronics OSHW v4.2 NETMF SDK v1.0.6
GHI Electronics Premium v4.2 NETMF SDK v1.0.5
Microsoft Gadgeteer Core v2.42.800[/quote]

Shouldn’t the version number of the MS Gadgeteer Core be v2.43.800?


#4

Sorry if this has been asked before, but…

Do you recommend or is it necessary to un-install the previous release before installing the new release?

Perhaps a note regarding this should be added to the Support page.

Thanks.


#5

@ Patrick

Gadgeteer core version 2.43.800 would only be used if we offered 4.3 versions of the gadgeteer modules drivers. We’re still using 4.2, so we need the 2.42.800 core.


#6

OK, that’s clear. Thanks


#7

@ andre.m - Thanks!


#8

Great work GHI Team !!

The know issue for Premium Libraries states :
“Connect() and Accept() can sometimes hang forever. Use a wrapper class to check for this and act accordingly.”

Is the code written by @ DAT as mentioned here: https://www.ghielectronics.com/community/forum/topic?id=12496&page=5 the preferred work around?


#9

Does NETMF and Gadgeteer Package 2013 R1 Update-1 need to be installed first?


#10

No


#11

@ RobvanSchelven -
I thought not but wanted to be sure.

Thanks


#12

YW… don’t forget to update all references in your application :wink:


#13

The feature that allows cerb-family devices to directly drive a display seems amazing! How could we write a sample application driving, say, a N18 display module with a Cerbuino?

Did you add specific display controller (such asN18 one, that is SPI based) driver at hal level?

Thanks!


#14

I just loaded this SDK and tried to use FEZConfig to setup the LCD and set the MAC address on an EMX Dev System. Where would be the best place post regarding this issue? News does not seem to be the best place.


#15

@ Mike - please start a new thread but keep 2013 R2 in the title.


#16

@ GHI - Create a Gadgeteer project with CobraII and a CP7. This is extremely nasty.


#17

@ Skewworks - ?


#18

Takes 30sec to a min to go from a white screen at power up to the normal GHI build info…and that goes crazy (like the resolution isn’t set properly).

This is only corrected after boot finally completes and user flushes to screen.

Not sure what happened on this firmware but I’ve never seen a GHI device boot so poorly. :frowning:

Additional note: Its much worse off the debugger. Really all you should have to do to recreate is make any old Gadgeteer project w a CobraII and CP7


#19

This firmware has display disabled by default. It will not work till a project is completely loaded and them the device is reset. This will happen a single time only on the very first time you Lac the lcd settings.

So where is the problem? :slight_smile:


#20

Problem is it’s not a single time as far as I can see. Run outside of debugger after programming and your looking at nearly a full minute to start.