Unnoticeable yet awesome new C# feature
-
Don't forget the .net nano framework :-) C# for the win, on ALL ESP32 based devices :-) [.NET nanoFramework – Making it easy to write C# code for embedded systems.](https://www.nanoframework.net/)
Yeah, assuming that's garbage collected I don't see the point.
Real programmers use butterflies
-
the best thing for bloating is a good fart or two. I wonder if there is a way to make software fart.
i keep working on the challenge of making my code not flatulent :wtf:
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Yeah, assuming that's garbage collected I don't see the point.
Real programmers use butterflies
I believe it is, well as far as I know, they use a rather scaled down micro GC that (from what I'm told) does a better job than the full GC in the .net framework. Of course, this is only what I'm told. :-)
-
I believe it is, well as far as I know, they use a rather scaled down micro GC that (from what I'm told) does a better job than the full GC in the .net framework. Of course, this is only what I'm told. :-)
I have to be very careful in practice about where my RAM is allocated. For example, I have SRAM (fast) and PSRAM (over an 80mhz bus). PSRAM isn't DMA capable, meaning for me to blt bitmaps to the screen requires me to tie up the CPU. So I need to use SRAM to do so asynchronously. Then you have ISR code, which must be loaded into SRAM, and I doubt you can even make ISR code with .net No offense, but what exactly are you going to do with a garbage collected managed code framework on something like an ESP32 that couldn't be done on the same platform several orders of magnitude more efficiently without it? Because nobody has been able to satisfactorily answer that question for me, I have dismissed it as a viable IoT development framework. For now. As time goes on, I'll reconsider my position as the technology warrants it. Micropython I'm uneasy about, but at least there's a better argument for it, and it's battle tested at this point. As much as I don't like it, it has proven capable enough. As for me, for now I'll stick with C++, because of all of the C++ ecosystem I can leverage in the IoT world but also because every cycle i don't spend garbage collecting or interpreting script is one more cycle of battery life.
Real programmers use butterflies
-
I have to be very careful in practice about where my RAM is allocated. For example, I have SRAM (fast) and PSRAM (over an 80mhz bus). PSRAM isn't DMA capable, meaning for me to blt bitmaps to the screen requires me to tie up the CPU. So I need to use SRAM to do so asynchronously. Then you have ISR code, which must be loaded into SRAM, and I doubt you can even make ISR code with .net No offense, but what exactly are you going to do with a garbage collected managed code framework on something like an ESP32 that couldn't be done on the same platform several orders of magnitude more efficiently without it? Because nobody has been able to satisfactorily answer that question for me, I have dismissed it as a viable IoT development framework. For now. As time goes on, I'll reconsider my position as the technology warrants it. Micropython I'm uneasy about, but at least there's a better argument for it, and it's battle tested at this point. As much as I don't like it, it has proven capable enough. As for me, for now I'll stick with C++, because of all of the C++ ecosystem I can leverage in the IoT world but also because every cycle i don't spend garbage collecting or interpreting script is one more cycle of battery life.
Real programmers use butterflies
I hear you, and yes I follow your concerns. What I do know about the nano framework however, is that for me, right now my biggest drawback is lack of drivers for common hardware. For example, I wanted to make use of an HD44780 LCD display, but my displays where all 4 bit with an I2C backpack on them, rather than the full 8 bit one the drivers where designed for. I have for a large chunk had to write my own shims for the hardware I'm using, but I have to say aside from that I have had no other issues in any of the work I've been doing. The project is also getting funding directly from Microsoft to help progress it, so that I think counts for something. To be perfectly honest, I would rather use the meadow platform : [Meadow](https://www.wildernesslabs.co/) But right now they only run on their own hardware. Meadow is more mature, not going to deny that, but it's not available to me right now what I'm working on. As for Nano, as I say, I can't say I've had any issues, but then again maybe I'm not working on the same type of projects you are, nano works largely ok for me, and my increases in productivity come from the fact that I'm using the same language and the same dev environment on both the device, and the device client sides of the equation.
-
I hear you, and yes I follow your concerns. What I do know about the nano framework however, is that for me, right now my biggest drawback is lack of drivers for common hardware. For example, I wanted to make use of an HD44780 LCD display, but my displays where all 4 bit with an I2C backpack on them, rather than the full 8 bit one the drivers where designed for. I have for a large chunk had to write my own shims for the hardware I'm using, but I have to say aside from that I have had no other issues in any of the work I've been doing. The project is also getting funding directly from Microsoft to help progress it, so that I think counts for something. To be perfectly honest, I would rather use the meadow platform : [Meadow](https://www.wildernesslabs.co/) But right now they only run on their own hardware. Meadow is more mature, not going to deny that, but it's not available to me right now what I'm working on. As for Nano, as I say, I can't say I've had any issues, but then again maybe I'm not working on the same type of projects you are, nano works largely ok for me, and my increases in productivity come from the fact that I'm using the same language and the same dev environment on both the device, and the device client sides of the equation.
For doing things like truetype rendering and partial double buffering over SPI (not I2C which is dog slow) you really benefit from DMA, and being able to niggle hardware some. I mean my unoptimized drivers get about 20fps and TFT_eSPI's spi drivers for the same configuration get 30fps. SPI on an ESP32 for 320x240@16bpp tops out at 31fps - just fast enough that the user hopefully doesn't notice your redrawing too much. However, I routinely deal with 800x480 displays using an RA8875 controller that's not even as fast as most other SPI displays. I can top it out at only 20MHz rather than say, 27. All the extra pixels compounds the problem. For me to render true type fonts, jpegs, and such reasonably I really need the speed that DMA buys me when it's available.
Real programmers use butterflies
-
For doing things like truetype rendering and partial double buffering over SPI (not I2C which is dog slow) you really benefit from DMA, and being able to niggle hardware some. I mean my unoptimized drivers get about 20fps and TFT_eSPI's spi drivers for the same configuration get 30fps. SPI on an ESP32 for 320x240@16bpp tops out at 31fps - just fast enough that the user hopefully doesn't notice your redrawing too much. However, I routinely deal with 800x480 displays using an RA8875 controller that's not even as fast as most other SPI displays. I can top it out at only 20MHz rather than say, 27. All the extra pixels compounds the problem. For me to render true type fonts, jpegs, and such reasonably I really need the speed that DMA buys me when it's available.
Real programmers use butterflies
Ah, well you see that's the difference. a huge amount of what I do communicates with a faster device on the client end that does the display (Automotive electronics) All I realistically need to be concerned with at the small device end is, does the device read the inputs fast enough, respond to the instructions sent to it fast enough. In most cases, anything that's time critical is on a GPIO all of it's own, anything that's computed, does so based on input to it's UART, the devices I build are typically sat down in the gunk and crap of the engine block, miles away from the user sat behind the dashboard, and very often each device handles at most only a handful of I/O pins, the most stressful thing I put any of my devices through is upping the serial baud rate :-) Display is usually sat up on the dash, and has something like an ARM7 with a decent clock speed and good amount of memory sat on it. For those cases where the engine end really needs to perform, I'll typically deeply something like a PIC Micro and write it's firmware directly in PIC ASM, but where I can get away with it, I do like using the ESP32 and the Nano framework, as the "head end" that has the display on is very often written using .NET/C# on a device that can handle it.
-
Ah, well you see that's the difference. a huge amount of what I do communicates with a faster device on the client end that does the display (Automotive electronics) All I realistically need to be concerned with at the small device end is, does the device read the inputs fast enough, respond to the instructions sent to it fast enough. In most cases, anything that's time critical is on a GPIO all of it's own, anything that's computed, does so based on input to it's UART, the devices I build are typically sat down in the gunk and crap of the engine block, miles away from the user sat behind the dashboard, and very often each device handles at most only a handful of I/O pins, the most stressful thing I put any of my devices through is upping the serial baud rate :-) Display is usually sat up on the dash, and has something like an ARM7 with a decent clock speed and good amount of memory sat on it. For those cases where the engine end really needs to perform, I'll typically deeply something like a PIC Micro and write it's firmware directly in PIC ASM, but where I can get away with it, I do like using the ESP32 and the Nano framework, as the "head end" that has the display on is very often written using .NET/C# on a device that can handle it.
That makes sense. It hadn't occurred to me to even use an ESP32 in an application like that. It's a bit heavier than what I'd have gone with but then with the ESP32 you get .NET and I suppose battery isn't an issue.
Real programmers use butterflies
-
Or more like:
ADD 5 TO SUM GIVING SUM5
Yuk! :rolleyes:
Mircea
We always used: ADD Poop TO Diaper GIVING Stench and for Fortran. God is real unless declared otherwise!
-
That makes sense. It hadn't occurred to me to even use an ESP32 in an application like that. It's a bit heavier than what I'd have gone with but then with the ESP32 you get .NET and I suppose battery isn't an issue.
Real programmers use butterflies
Nope, no battery problems, as the power is taken directly from the automotive electrical system, and I have a LOT of Amps to play with :-) The biggest problem I have is trying to make things wireless. When you have something effectively encased inside solid steel sealed assemblies, your pretty much guaranteed to need a wiring harness, and where there is a wiring harness there is capacity for leaks. Oil Pressure/Temp monitoring is one such case, which makes maintenance a complete PITA. I would dearly love to make more use of things like WiFi/Bluetooth etc, but there's often just far too much metal in the way. One thing we did experiment with however, was to use the entire metal encasing as the antenna, but that unfortunately didn't work too well. What I work on, is all about taking software design concepts such as microservices, and applying them to hardware, we try to make each "unit" as stand alone as possible.
-
...and spice it up with some '?.' and what else. Once upon a time c# was such a beautiful, simply/logical structured language :((
Or have the '?' at the end of the conditional then what falls under it is the answer:
if (x is not null)?
{
do_something();
}we first ask if x is not null, then the answer would be to do_something(). This does make the language look more conversational. (Yes, this is going off the deep end.)
-
With latest c# iteration, instead of
x != null, one can writex is not null. Meh, I initially thought. But then I tried to override the==and!=operators and then.. I understood! :-DA new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Been using that all over the place. Technically, it does about the same as != null, but I think it's increased readability is a boon. A comparison may look like any other value comparison at a quick glance, but an is not null screams "Yo dawg, this is a very special case here, potentially used for high-level control flow/error handling".