Integrating in our design

[Eric Girard]

Hi,

This looks like a great board!

If I use your board on my own PCBs, how do I send the firmware to it ?  Reading your manual, I found that you can enable and configure tinyBooter by pressing the up / down buttons on the dev board but what about custom boards where these inputs are used for something else? (I'm planning to use the 2nd CAN channel, which use the down button).  What about initial setup; I'd like to debug configure thru ethernet, how do I set the networks parameters on the first boot w/o any buttons, do I need to reserve  COM1 for this purpose ?

Thanks,

Eric G.

[SupportAdmin]

Yes you would have to keep COM1 available for loading tinybooter and for loading the network settings. You may never need it but it is always good to get some debug messages. You will not always need it so your product doesn't have to include RS232 for COM1 (or VirtualCOM - USB) then you could use TTL-232R (or similar) for flashing/updating...etc.
http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm

Also, you need to keep the IOs for up, down, center handy. Maybe connect them to jumpers. The pins will still be used normally, like for CAN. You will only need them if you need to update the firmware, which should very rarely happen after your product is released.

We are going to add another "GHI only" feature that lets you update the firmware right from inside C# so you wouldn't need to use the jumpers but you should always keep a backdoor in case of a failure while flashing.

[Eric Girard]

Thanks,

Fast reply

Eric G

[bncastle]

Interesting. When approximately can we expect this firmware update capability from 'inside c#' and how will it work?  What I need is to be able to write some custom app that will talk to the board and update it via TCP/IP.  That is of course after the board's first config via COM1 to setup network parameters.

[SupportAdmin]

Will work very simple!

1. Allocate a buffer
2. load the standard firmware file in the buffer
3. call a special GHI method with the buffer
4. The method will re-flash and reset the system in few seconds

We are doing many other features so this is not priority for now. It should be done once you really need it

[SkierHiker]

I am also very interested in this feature, to flash firmware from within my application. Can you provide an estimated availablility date, hopefully in 3.0?

[SupportAdmin]

All new features will be for 3.0. The current 2.5 is final unless there is a strong reason on why to change it

Our feature timing is directly related to when Microsoft will have 3.0 beta3. Supposedly this is the release that will have the configuration for the build tools (we are doing everything manually and it is pain)

[mcopioli]

1. Is it absolutly necessary to have com1 exposed? 
2. Can the firmware be updated using only a thumb drive?
3. All buttons will be used for our application.  Is this an issue?
4. Our end hardware will have a usb hub integrated into the design.  Will this be a problem for updating GHI firmware?

Thanks,

-Mike

[SupportAdmin]

This is an old post and things has changed a bit

1. Is it absolutely necessary to have com1 exposed? 

Next release (1 week) will expose TinyBooter on firmware over USB and so you do not need to expose COM1. But in case something went wrong and you want to update TinyBooter (using GHI loader) then you will need COM1
So, I would not expose COM1 out to users but I will keep a header or pads available just-in-case!

2. Can the firmware be updated using only a thumb drive?

You now can not update firmware from thumb drive. The only way is to connect the device to the PC and load the firmware using MFDeploy tool
Next release (1 week) will add features that lets you upload firmware from anything, SD, USB memory or even from the Internet! Details come with the release

3. All buttons will be used for our application.  Is this an issue?

You can almost use any of the available pin to connect to a buttons, just keep in mind that some buttons have special functions on power up (like hold up and down to force TinyBooter)

4. Our end hardware will have a usb hub integrated into the design.  Will this be a problem for updating GHI firmware?

See 2 above

[mcopioli]

The only way is to connect the device to the PC and load the firmware using MFDeploy tool?

Connect how? As USB device?

[SupportAdmin]

Yes, driver is included with SDK

[mcopioli]

Yes, driver is included with SDK

So this means I have to provide a USB-B connector on my hardware.  Correct?

[mcopioli]

Well?

Is a USB-B con a requirement?

[GHI_Support]

There is in-field update in next release, you can update it any way you like. You just need to get the firmware files somehow...
But in case it fails (ex: power loss), you need to expose a way to update it, maybe hidden from the end user.
USB device will update the TinyCLR files and your managed application.
In extreme cases, if you need to update TinyBooter (which loads TinyCLR), you need COM1 (UART0) also.

[mcopioli]

Got it Thanks.  I will expose everything to play it safe.

up,down and enter along with USB-B and com1(usart0) will all be exposed.

[dcreel]

Answer for #2 is an excellent feature that I have been anticipating for a long time 

[mcopioli]

Would it be possible to get the eagle footprint for CON2.  The data sheet for the B2B-PH-SM4-TB connector does not have a detailed footprint and I am tired of guessing.

Thanks

[SupportAdmin]

GHI doesn't provide any design packages for customers, sorry. We have added design files in EAGLE format for the breakout board (as you requested)to help customers out with the Embedded Master module layout but any other connectors/packages need to be made/tested by the designer.

[mcopioli]

Why?  I would think that you would be willing to offer incentives to your customers to integrate their designs with yours.  This could cost us an entire run of prototype boards thus increasing our time to release and wasting money.  All because of a silly 2mm con that has poor documentation.  I am sure that you have encountered this issue since the embedded master dev board uses this part.  It can only help GHI to post this lib.  If not I suppose I will just have to guess where the board mounts are supposed to go.

Thanks   

[SupportAdmin]

All because of a silly 2mm con that has poor documentation

This is not a GHI part. Sorry I couldn't help further. You can contact the connector manufacture for layout info if you like or order teh connector and measure it yourself.

Please let us know if there is anything else we can help with on GHI products