Looking for some advice

I am looking for some advice on application development/organization.
I am embarking on a fairly large user interface design using TinyCLR with a 7" screen. There will be a lot of screens and menus, maybe as many as 50 screen layouts. I have most of the core functions working (network, interface ports, SD card, USB, etc.), along with the “business logic” or data handling/application code started. This device interfaces to devices out in the field (Modbus over serial and ethernet) and displays the data for the user, serves it through a web interface, data logging to USB and the cloud.

When it comes to UI screen development what is the best practice for keeping a good clean separation for maintainability in Visual Studio? Would it make sense to have a separate UI application that gets loaded in at runtime using AppDomain? Would that make it more difficult for the UI to get to the application data? Or should I just take the more straightforward approach and just use folders in the Solution Explorer and keep everything in the same application?

Maybe there is no easy way but I am hopeful that maybe someone else has been down this road with a large application and has some tips and tricks.

It’s on a stand for development so I can get to both boards. In the real product, the controller board mounts behind the display.

something to consider https://nextion.tech/

@RobvanSchelven, Thanks for the info. It looks interesting. However, I am committed to SitCore and the built-in graphics. The hardware design is pretty much finalized and is in the quoting process for production.

I have been working on big projects recently and I have found it useful to make different TinyCLR class libraries for my code.

To start with, I have written a big and extensive library set to handle stuff like our configuration engine, CAN heartbeat messages and some basic wrapper classes to make GPIO a bit simpler.

Splitting everything up into smaller class libraries of their own and just having those in folders by category in VS has really made everything more manageable. This project started out in one single project/solution and that got out of hand fast. The entire project is now split up over about 15 different class libraries and it’s super managable :slight_smile:

P.S.: where are you finding stock for the network switch IC? I need 'em too! :smiley:

1 Like

Cool board/project…

Trying not to be an all take and no give scoundrel…have not used the UI elements as our solution does not require such, so am of no help on subject…

You board appears to have some of the same elements as our new SCM20260D based board, which is in final design phase…Gerber files, etc. Our new board is much the same as our old board that was based on the G120 SoM.

If you don’t mind, I have a few questions about your board.

The 2 big blue caps, are they for short duration battery-backup.?

Lower left corner next to what appears to be a USB Type-B port/cable,
is a silver device with ‘+’ on it…assume that is a SuperCap, correct.?

If that is a USB Type-B connector, was it chosen because it is more stout than mini/micro Type-B, C connectors.?

I appears you also have a USB Micro Type-B port below SCM20260D SoM, is there a reason you chose this connector over others.?

…BTW, I have looked all over GHI, documentation, yadi-yada…anybody know what the USB Client Spec is…(USB 2.0, USB 3.0, USB 3.2 Gen 1 / Gen 2 / Gen 2x2)…?,…and is the ~max spec(d) data speed, and bandwidth within in range of what you may have measured.?

USB Host - I have done zero dev on this port…any caveats (gotchas).?

Curious…what looks to be 3-Ethenet port (upper-right)…are there really 2-serial ports, and 1-ethernet port.?

If serial port(s), RS 232/422/485.?

…Again, not trying to be a heel, just glad to see other folks that re traveling along same path.

It is USB2.0 running at 12Mhz.

@LucaP , thanks for the suggestion. I think that is probably the route I am going to go. I was already planning on a class file for each screen. Currently, all major functions are split into their own files as well. In regards to the network switch IC, I have my fingers crossed. The board is out for quote now for production so we will see what they come back with. I have added extra jumpers so I can fall back to just the SitCore ethernet port if necessary. I also have 2 different package size options on both I2C and SPI buses for FRAM memory so I can hopefully get around any shortages.

@mhardy, No worries, I welcome the discussion. Yes, the 2 blue caps are for power-fail backup. It gives me about 5 seconds to get files closed and saved. The SitCore, microSD, and FRAM are on their own 3.3V supply powered through that backup power supply so only the necessary components keep power.

The lower-left corner is a standard CR2032 for real-time clock and battery-backed RAM. I like the idea of a super cap but sometimes these devices can sit unpowered for 6 months and I was worried a super cap wouldn’t hold out.

The USB Type-B is the main programming port. I wanted a more robust port, especially if it needed to be accessed in the field. (These devices go in rock quarries and mines.) The bigger port is easier to keep clean and being thru-hole can handle a bit more abuse.

The micro USB is attached to an FTDI USB to UART going to UART 5. This was added as a backup debug/troubleshooting port.

USB host at this time and on this board is just intended for USB Flash drive for data logging, software updates, etc. I haven’t done too much work with it yet but what I have done it just kind of works. I do think there have been some compatibility issues with different formats or manufacturers of USB drives.
In the future, I am hoping we will see USB hub support and Cellular modem support. :wink: That would make my cellular modem work MUCH easier.

The 3 ethernet ports are part of the 5 port ethernet switch. The SitCore’s ethernet port is capacitive coupled to one of the ports, giving me 3 external ethernet ports. (5th port not used.) Two ports can source power using passive PoE that is software controlled on/off and current monitored. This is primarily designed to power an Ethernet radio. The monitoring and control will allow us to cycle the power to the radio from the UI and monitor the current usage to see if it is truly powered. By reading the port stats from the network switch IC we can monitor link status and even measure the cable length to check for shorts. (Radios can sometimes be 100+ away from the device up high where they are inaccessible.) The 3rd port can take PoE in, again just the passive version, to power the whole board.

There is an RS-232 and RS-485 at the bottom left. Along with 3 expansion ports. Each port has a UART, I2C, and SPI bus going to them as well as a few I/O. Those will allow expansion for 4-20ma current loop outputs, digital I/O, more serial ports, cellular modem, wifi, etc.

The 4 ports along the bottom right are loosely based on the STEMMA standard. The first one is shared with UART5, the next one is I2C and the last 2 are UARTS. It is just a 4 pin plug with 2 data lines, GND and 5V. UARTS can be valuable down the road, you never know when you might need them so I like to have some way of accessing them for future use. One of the I/O option cards will be a dual serial port card. The card will use the UART at the port that it is plugged into and the second will come from a jumper cable going to one of these plugs.

1 Like

@gus —thx
@skeller – Way to get started on writing the datasheet for your product.!..appreciate it…

Hey Steve, the board looks awesome. The switches located around the LCD look great and I guess are needed for when users have gloves?

The UI is a bit tedious to develop compared to the old way with Glide but does give some flexibility. Mifmasterz has done some good additions to this with DataGrid and a SwitchButton being 2 of the new controls I use. The SwitchButton is nice as it has a toggle state for ON/OFF control. A custom image control for buttons would be a nice addition to the UI which I have started to create. Lack of transparency means rectangular is the only current option.

@Dave_McLaughlin , thanks for the reply. Yes, the buttons are for gloved hands. The primary day-to-day functions will be accessible with the physical buttons. Operators could have gloved, or dirty, greasy, gritty hands so hopefully it will keep the wear and tear off the cap touch screen. Over time pressing the same locations on the screen would cause scuffs, scratches, etc. Then there is the gloved hand issue. I could have used resistive touch but that doesn’t solve the dirty, grimy hands issue. Resistive also doesn’t have a smooth feel that people are used to with their devices.

I am a bit nervous about the capabilities of the UI. I am confident that I can work through everything and make a good product. The first version might not be as clean as I would like and I might have to wait for some of the UI capabilities to catch up, but I feel even at its current state it will be an improvement over our current product that has a 256x64 Graphical LCD with membrane keypad.

I have thought about maybe designing the screens in Illustrator, the lines, fixed graphics, text box borders, button outlines would be a graphic image. In TinyCLR I would show the image and overlay text boxes and buttons in the appropriate locations. I am not sure what kind of hit that would take to my internal flash storage but if I have issues getting the look I want that is possibly a fallback plan over doing everything in TinyCLR.

An Image Button would be a huge asset. I am hopeful that as more people dig into the UI it will be improved and expanded.

I do agree, Glide was a nice package. Looking at xaml which is used for desktop WPF it seems someone smarter than me could create an app that would parse through a xaml file that has been created in VisualStudio and create a ‘XAML Lite’ version that TinyCLR could use. It would give Glide like functionality and design experience but use Visual Studio designer. Anyway. . . one can dream.