The picture I posted at
The Black Hole......
is a C# Windows application form.
It's a test application I'm using to communicate with a PIC18LF4550 via USB.
I'm also using C# to communicate with a Keithley 2001 via the NI GPIB to USB adapter.
The platform (dotnet framework) is quite stable, even if Windows isn't really an example of stability.
However Visual Studio, the development tool, is very powerful.
Contribution like the quote below?
With no supporting objectivity.
Like Java, C# and other .NET languages rely on the existence of a runtime environment, CLR (Common Language Runtime). This may not necessary be available for embedded systems.
Last edited:
As far as I know, the latest versions of Visual Studio are able to compile for ARM cpu.
Contribution like the quote below?
With no supporting objectivity.
While your contribution is null, our contribution is some oscillators in class with Wenzel and Oscilloquartz (the best oscillators available on the market) at affordable prices (around Eur 200 against several thousands USD).
Then there are frequency doublers with SOTA performance, battery power supply system, a few regulators, some interfaces and soon a FIFO buffer and couple of DACs.
Not bad for two hobbyists.
And your contribution is still null.
By stable, I meant will it be viable 25 years from now. The machines we are upgrading I built 25 years ago, windows 95/98 and VB5/6 have served well since. The trick is to build enough software capability at initial design so that it can build super-magnets that are beyond SOTA even 25 years later. I on occasion have to modify code when the physicist desires something that didn't exist previously, but the process subroutines were written to allow that.
We locked 95/98 in because the motion cards are not supported past '98, but the choice of C# has to work for the next 25 years.
The language looks similar to the openscad code I've been using to generate 3-D objects for my 3-D printers, so at least I'll be able to read the code my replacement is writing for the most part.
I must admit, pushing them to hire my replacement so I can transfer knowledge, and then having him there is a weird feeling.
jn
No, quite a list of products up for sale, coming from two hobbysts.
BTW, comparing your bric-à-brac oscillator with the Wenzels is shameless and clearly shows you have no clue about oscillators. Wenzel products are now on the surface of Mars running in the Curiosity rover. Beyond reliability for Space applications, you don't want to know the precision and yes, noise performance required for these products. I am quite sure the martians listened to the Wenzel low frequency jitter and found it satisfactory for their wideband oversized ears.
Pono I was shaped like a Toblerone. Maybe this one looks like a Cadbury Egg?
Hey, just in time for Easter!
(couldn't find a bunny)Talk is cheap. Post real evidence that your DAC is audibly superior to DACs costing 100 Eur or less.
Just for some conversation as it's the weekend.
C Is Not a Low-level Language - ACM Queue
I am not clever enough to fully* critique this but it does make those of us on the 'outside' think a bit. Now embedded covers a range of sins so a number of processor platforms might still meet the 'fast pdp-11' description.
*Ok admit it, even partially
Just for some conversation as it's the weekend.
C Is Not a Low-level Language - ACM Queue
I am not clever enough to fully* critique this but it does make those of us on the 'outside' think a bit. Now embedded covers a range of sins so a number of processor platforms might still meet the 'fast pdp-11' description.
*Ok admit it, even partially
It’s considered ‘low level’ only because you can really get into individual registers in the processor, specific memory locations etc.
If you try to write routines for some of the things you can do in say Python which is great for dealing with big data sets and math manipulation, you end up with huge and complicated code. So C is great for doing stuff at machine level (‘low level’). It’s fast, compact and extremely portable. It’s not well suited to high level data manipulation
But the point of the article was, how many processors actually work that way these days. As soon as you have branch prediction, OOE etc in a CPU all bets are off. some embedded is, some embedded isn't.
C# is a very good language. The language itself is similar to an improved version of Java. It sees very regular updates and a lot of activity. The tools are mature. It'll be around for a long time, it has a huge user base.
It's essentially an interpreted language with garbage collection, so not the best choice if it's going to be an application that requires extremely low / consistent latency. No problem if you are compute bound as JIT optimization is good. None of this matters if it's a simple GUI or web application, of course.
Which programming language is fastest? | Computer Language Benchmarks Game
I'd recommend you target .NET Standard (.NET Core) instead of the full .NET Framework if possible since that is the path forward and gives you possible cross-platform compatibility excepting UI frameworks.
You can inline asm in with most toolchains if you really wanted to. For example, Intel distributes SSE/AVX intrinsics for C that are basically fancy macros that do this.
Intel(R) Intrinsics Guide
The only good use of asm on a big CPU that I can think of is for vector instructions where the compiler is sometimes unable to auto-vectorize your code depending on how it's written.
In most MCUs, you can directly access registers in C.
Last edited:
Yeah, you're working with virtual addresses on a platform with an MMU.
I figure the appeal of C is that it lets you do "dangerous" things, like whatever you want with memory. That and I guess it's not a complete mess / kitchen sink like C++.
I am guessing C will be around a long time because of embedded. I wouldn't be surprised for it to be partially replaced at the OS level by Rust or similar that still offer good performance and more security.
I have already explained on another thread but it looks like there is no chance you can understand. It's your problem.
And yes these are a list of diy boards shared from two hobbyists on a diy audio forum, nothing more.
No audio company, no audio professionals, no commercial interest, since we build these devices for ourselves.
And yes they are not for free, although they are a bargain.
We are not San Francesco (or Saint Francis for those who does not understand italian language).
We spent a lot of money to build these devices and achieve such results (our time is almost for free).
Unlike your bric-à-brac phono stage our oscillators by measurements (your obsession) are in the class of the Wenzel ones (see table).
Our XO:
Pn 1Hz dBc/Hz -123
Pn 10Hz dBc/Hz -155
Pn 100Hz dBc/Hz -157
Pn 1kHz dBc/Hz -168
Pn 10kHz dBc/Hz -171
And since you have not understood anything about oscillators, it's almost obviuos that our oscillators have poor long term stability since we have not implemented an oven.
In audio we don't need it but in case we will use your phono stage to control the oven, although one opamp is more than enough, maybe we can parallel them so the servo will measure spectacular.
Finally, you can't listen to the Wenzel low frequency jitter because you measure but not listen.
Attachments
My DAC does not exist for now as we are still developing it, but for sure it will be audibly superior to your DAC which will never exist.
The application requires the ability to send G code "like" positional information in coordinated moves of 6 axis, with 4 more controlled in real time. Feedback from the controller amps position is used to calculate tip velocity, this used for a few algorithms including ultrasonic power levels and wire feed velocity (think of a bowden tube feed on a 3-D printer).
When I built it back in the day, the ISA buss was the limiting factor, 8 bits at 33 mhz backplane speeds was the limit. Luckily, modern computers won't be the determining factor for communication, fiber is a distinct possibility.
I must admit, being able to transfer files using a USB stick instead of CD's will be such a relief. I will never allow a hard link between the machines and the web, always an air gap.
It is interesting giving up the actual coding to a young guy, but that is both what I wanted, and what is needed. Coming into this millenium with the hardware/software is truly needed.
While this topic may be a tad off topic, I thank all of you for engaging.
jn