Go ahead don’t be shy. Ask questions!
OK, here you go.
What’s the freq of the top end option? I know freq is not a direct relationship as it depends on the cores optimisation etc.
How much memory do we have with each option? Talking RAM and FLASH here.
What is the max speed for the graphics display? The 1024x600 IPS I plan to use is 60Mhz.
What is planned for any graphical interface? Do we have a more up to date version of something like Glide that we had on .NETMF? I loved that old drag and drop interface that the late Blackdog Spark created for Glide. He saved me and probably other, many man/woman hours in getting a working GUI in G120 and G400 (My G120 based oven controller is still going strong after 5+ years of operation)
I’ll think of more later after I’ve finished my morning coffee.
The clock does not mean anything like you said but it is 480Mhz. It is twice as fast as 400Mhz G400 so do not take the clock a speed measure!
The interesting thing here is that all options are “top end option” because they all run the same clock and all same internal memory.
Same as before, this is not a good measure. There is enough flash and ram internally to do anything you want securely, in internal secure memories. This is the case on SC20100, the 100 pin LQFP. User flash is about 600KB and free user RAM is also about 600KB.
Now for graphics, we give you the option of using the 32MB SDRAM for graphics only.Meaning the non secure external memory has image buffers only. So still enough to do whatever you need with 1024x600 display. For Flash, there is 16MB external non secure flash.
If you plan on play MP4 video and 3D games then you are looking at the wrong tool. But you are designing a product and need a user interface then we have the perfect tool, especially if security is a concern.
This is where things get interesting. We have never pushed for WPF because it was very slow. This is not longer the case. You can build very nice dynamic graphical interfaces with WPF today and they work very smoothly. Glide is very memory hungry but runs faster. WPF manages memory better but slower. You now get the speed you need with WPF and still not need tons of RAM.
And that is one right example for SITCore, oven controller. You actually for this just need the 100pin LQFP chip with SPI display! You you can have it internet connected very easily and very securely.
Sure you can use Arduino/mbed on the low end and use Android on the high end. But SITCore with TinyCLR is the perfect sweet spot in the middle.
Gus. Can you explain about WPF? I have never used Glide (actually this is the first time I hear of it). Will the TinyCLR SDK include WPF/XAML that compiles and runs in the SITCore micro? Or are you taking about applications that run on a Windows system that communicates to a GHI micro?
A couple more questions:
Q1) Any idea of the power consumption running full up? Or even better the power consumption vs. clock frequency like in uA/MHz ?
Q2) Is the 480 MHz part a variant on an existing ST Micro, or NXP, or Atmel, or ??? part? If so, can you share which one?
Q3) How many UARTs are available and functional after all the other peripherals are assigned to pins on the 100 pin part and on the 265 pin part? (Unfortunately, the vast majority of instruments in the oceanographic research world are still RS232).
Q4) What power down modes are currently in or planned for TinyCLR?
Plenty more questions but that’s enough until I get my grubby hands on the shiny new hardware.
Happy Thanksgiving to all who celebrate it.
It is a subset of windows WPF. No XAML, no window designer but this can be added in the future. Glide was an alternative we had years ago to solve how slow WPF was on G120. WPF is not slow anymore on SITCore so there is no need for Glide.
Too early to share this but I am sure it will be lower than G400 so you are getting a lot more speed for lower power. Anyway, we have sleep/hibernate implemented and we are considering adding more low power modes in the future.
Answer above already!
It is but better if we do not share this as this will only throw everyone off. To you, this is SITCore chip from GHI Electronics, nothing else. Any additional info will simply confuse everyone.
Do you think you can handle an amazing answer? I am now counting…
(All are the same on small and big chips except when noted)
8x UARTs, 4 of them with handshaking
4x SPI channels
3x I2C (2x on small chip)
almost 30x PWM
over 20x analog in
2x analog out
camera (large chip only)
LCD parallel (use SPI on small chip)
4bit SD card
480mhz ULPI USB (future plan)
I2S (future plan)
Excellent!! Looking forward to start using your WPF libraries.
My GUI working for a small greenhouse will be reborn. Hello WPF. Goodbye Glide. https://www.youtube.com/watch?v=23mdKf9qPys
Philippe. Was that on TinyCLR1.0?
Gus - Very impressive. But it leads to one more question: do you know all 8 UARTS will actually be available on either chip when all the other functions are mapped to pins? I know on every ST Micro part I’ve looked at you always lose at least one UART when you use the 4 bit SD pins and sometimes another UART when you add external SRAM. I’m guessing this would happen for sure with the 100 pin part but maybe not on the 265 pin part? It’s kind of an all or nothing thing in my specific case. If I can use all 8 UARTs, I don’t have to add any I2C/SPI UARTs which are just kind of a pain. But once I add one, it doesn’t really matter how many more I have to add.
Another question is if TinyCLR will support UART functionality over USB? I’m not very familiar with this approach but you do mention CDC and at some point I’ll check out FTDI chips.
You will have to wait to get exact point details and yes we support CDC already and even support winusb
On .netmf v4.3
And your GUI will be a LOT faster now
Regarding WPF, we have invested much time in TinyCLR 1.0 screens. Overall things are working. Are there major changes in screen development methods from 1.0 to 2.0?
Nothing major. Only minor improvements
Looking back through the various posts I saw something that I wanted to find out more about. Somewhere you said “Note here that external SDRAM is only used for graphics. All code runs securely in the internal SRAM.” Does that mean I can’t use external RAM for arrays defined in my application code? One of the big pluses for me of .NET Micro and the G400 is the large amount of both Flash and SRAM. For example, I use a variety of asynchronous queues to get data out of event handlers like the UART data received event handler. Some of these queues get pretty big, like 1/4 kB wide by 1/2 kB deep. In addition, I find not having to dynamically allocate and deallocate memory is highly beneficial to building robust code. Can you clarify?
Thanks - Gene
You can absolutely use sdram for your arrays if you want to but then you know those specific arrays are in external memory and therefore they are less secure. But you have the option … You are welcome