To me, the syntax is nearly identical... I've cut and pasted decent size pieces of code between them and had it work with just some minor changes. Maybe it's because I'm not a programmer, but to me the syntax is most of what makes the language...
To me, the syntax is nearly identical... I've cut and pasted decent size pieces of code between them and had it work with just some minor changes. Maybe it's because I'm not a programmer, but to me the syntax is most of what makes the language...
Yes, it could be because you are not a programmer. All of the languages were based on the C/C++ syntax but they are very different semantically.
"The syntax of JavaScript is actually derived from C"
Yes but syntax is only a superficial part of a language. I guess that's where we disagree. I consider the semantics of a language to define it more than the syntax. It's like the people who claim Spin and Python are similar languages just because they both use white space to indicate block structure. They are actually very different.
Yes it is true that you can get exactly or almost exactly the same source code to run as C or Javascript and give the same results. The syntax is very similar that way.
On the other hand it's very likely to do something completely different. The meaning, is very different.
Most would take the view that it's the semantics that makes the language not the syntax.
How are you going to do this in C or C++:
"use strict";
function Actor(name) {
let lines = 0;
return function sayLine(line) {
name = name;
console.log(`${++lines}: ${name}: ${line}`);
};
}
var heater = Actor('Heater');
var rayman = Actor('Rayman');
heater(`My dog's go no nose.`);
rayman(`Oh, how does it smell?`);
heater(`Awful.`);
heater(`When is a door not a door?`);
rayman(`I don't know, when is a door not a door`);
heater(`When it's ajar`);
Outputs:
1: Heater: My dog's go no nose.
1: Rayman: Oh, how does it smell?
2: Heater: Awful.
3: Heater: When is a door not a door?
2: Rayman: I don't know, when is a door not a door
4: Heater: When it's ajar
@mindrobots
Yes, ALGOL is the mother of all modern "structured programming" languages. The first to be built from a formal specification, BNF. If you squint really hard most languages we use today look like ALGOL. I don't recall that ALGOL had lambdas and closures and first class functions though.
Ultimately anything one can do in Javascript one can do in C++ or even C.
We know this is true because one can:
1) Write a JS interpreter in C.
2) Include that interpreter into your C program
3) Write some JS as a string in C.
4) Run that string through the JS interpreter.
That's all a bit meta though.
In Javascript you can write:
x = 3.14159;
x = "Some string";
x = ["an", "array", "of", "mixed", types, 9, 5, {x: 4, y: 10}];
x = {x: 4, y: 10};
x = function (param) {
// code here.
}
But to do that in C++ you are going to have to define some weird class for x
class WeirdThing {
...
}
and define x as a weird thing:
weirdThing x = new WeirdThing;
And use lots of operator overloading of "="
When you have done all that you start to realize how different the C++ and JS languages are
...I don't write weird code like that...
Well, it's a contrived example. But it demonstrates first class functions and closures, which can be very useful in non-weird situations.
It's a bit of a different view of program construction.
Price and availability. I've got varieties of microcontrollers and microcomputers sitting here on my desk.
The favoured units are those which are which are inexpensive enough to drop into projects at a low price point.
Current consistent players are the Raspberry Pi Zero (although hurt right now due to availability thanks to Rpi3 production, but priced at a point where I don't mind using them frequently in projects.) PICAXE, PROPELLER, and PIC. I wish I could say that I use any of them in my day work, but none of them are proven to be reliable enough for industrial control. (A whole different breed of controllers there.) Provide an actual product. I don't care if it's not perfect, I'm willing to invest myself in the development process and incorporate the improved version 2, 3, 4, and so on designs as they become physically available.
- What's bad/frustrating about them?
Bad IDEs and compiler chains. Worse yet strange language limitations. Continue to head toward modern languages were we can use the development platform of our own choosing. Python, C, and I hate to admit it, Java a good choices right now, but certainly not the only ones. I'm not a fan of web-based interfaces. Give me console/Ethernet/USB access. Hardware interfacing needs to be friendly on both 3v and 5v (tolerant) levels. Heck if educational considerations are still of interest, drop in some PLC stuff and definitely consider some tutorials on binary, hex, and octal counting.
- Is there an increasing sense of liberation using modern microcontrollers, or do you sense a long arm of increasing control?
Dear god, every new design seem to bring more programming abstract layers with it preventing me from being close to the hardware itself. This is a weakness that seem to come more with "microcomputers" than with "microcontrollers", but the distinction between these two is starting to become very fuzzy, especially for those who simply want to get things done and don't really care. Perhaps this is a fact of the industry, but the closeness to the actually I/O of the Propeller is certainly something I'd always appreciated about the chip.
- Are they fun?
If you give me something that doesn't try to do EVERYTHING, but does the things it's designed to do very well, then yes it's a blast. I prefer the challenge of a lowered bar anyway.
...none of them are proven to be reliable enough for industrial control...
Did you just say that a Propeller was not reliable?
In what way?
What kind of industrial control are we talking about here?
He's talking about the kits more than the chips. Industrial control equipment is DIN-rail mounted, 24Vdc, with opto-isolation all round, including analogue channels.
We have many industrial machines we sell in decent quantities that could probably benefit from a Propeller, but what I see from an industrial point of view is that there is a lot of in house testing and design review and some of these guys are pretty serious and set in their "engineering mind" ways. <- I generally don't fault that stereo type, but there are times when I run into someone that just needs to relax a little, forget what they learned in school for a moment, and accept that there might be another approach outside of the box. Unfortunately I am outnumbered, and many views about the Propeller, not just in my field, are that it's difficult to take seriously in a large industry where the "engineering mind" stereo types dominate. Mainly because they don't understand the programming, ... it's out of the box and so foreign to how they were taught in school they don't want to risk it. The risk is real money when some machines we have sell for $125k a piece. Often it's not just one machine sold either, and it's not the same machine. There are usually a set of machines that are designed to all work together that in total can well approach $1million for a single sale. I happen to be right in the middle of Research and Development of such machines, and to design in a "new" micro controller that doesn't have any kind of a track record within the company certainly raises more than a few eyebrows. In order to make large industry appeal, a micro (whatever it may be) is going to have to come from a different angle than the approach it is currently taking. Education is only part of it, but the way it's programmed must meet the current curriculum that is sculpting the "engineering mind" stereo type mind I have made reference to. You have to be careful that the Education program is not constructed in a way that a student rushes through the material just to make the grade or else nothing is really learned. <-- I find this so frustrating and perhaps the most difficult to convey and yet I see it time and time again. In class it's often treated as a race and it's not a race. It's a true commitment that needs to be recognized as such.
As far as Opto-Isolation this is basically done as described above, but it;s not always locked to a specific voltage. Voltages can be all over the place... 12V, 24V, 0V-10V, 0V-20V, 4ma-20ma, etc.. Typically power to the micro and supporting circuitry has it's own galvanic isolation from the mains with an on-board power supply and Earth ground is kept separate from Circuit ground unless there is any kind of human interaction. In that case the Circuit ground is the same potential as Earth ground. Where Opto isolation is needed is only to prevent ground loops on I/O's. Anything powered on the PCB board such as relays, motors, etc. don't necessarily need isolation, unless there is potential for a ground loop. For example, we have a motor controller card that takes an input signal from 0V to 10V to control the speed of a 90V DC motor, however the motor controller input is NOT isolated from the mains. (This is the fault of the manufacturer of the motor controller card) In this case you would need a linear Opto-Isolator to convey the 0V to 10V signal from the micro controller board or some other mechanism to convey an analog value... i.e. PWM
As to the state of microcontrollers these days? I have been programming micros for 35 years starting with the 6502 when I was 12 years old. I'm old school in the sense that I prefer to program in Assembly language, I don't like C, I don't really even like Basic, heck I can't even type without looking at the keyboard ... so that said, that removes any bias that a higher level programming language might introduce. I might also add, that I am completely self taught (which might explain the typing skills ... at 12-there wasn't much in the way of typing class) so the bias of the "engineering mind" stereo type I mention earlier is also not there. I consider myself completely off-grid and out of the box when it comes to answering the question ... "So what classes did you take to learn that?"... Sure I took classes, but on many occasions I ended up tutoring and teaching a majority of the class... As someone said earlier tonight in the "Propeller Powered Chat room" ... "it's just You and the micro controller when programming in Assembly." <- Completely true. If it's not working right, it's because you programmed it to do exactly what it's not doing right .... In 35 years much has changed, mostly the IDE. A step up from manually keying in the hex codes (which I have done) to program, you used to only be able to use a standard text editor without any syntax checking and then send it off to a compiler that turned the Assembly code into Machine code (or HEX)... Now there are all sorts of things you can do with a modern IDE ... Emulation, Debugging, defining Macro's, etc. ... and even handling page boundaries... <-wait what are those? A real programmer knows, but I will leave that as an exercise for you to find out. Anyway, the micro itself hasn't changed a great deal, I mean sure there are specialized functions that do cool things, and some of those features have been made atomic to the micro controller, but at the same time many of those features have limitations because they are hard coded. Unless you are planning on building an army of many different variations of micro controllers and have a mapped time line of their existence, hard coding a specific feature that may be popular now becomes a time capsule in essence and may be outdated in just few years from now. Most if not all function/features can be programmed in software... think about it, they had to be at one time before they were made an atomic feature. Now, think about why they were made atomic in the first place? It's because you had a Single threaded Controller and needed a background task to take place, or something you could set and forget. .... Let me ask.... isn't that one of the core premises of the Propeller? I applaud the efforts of feature packing the Propeller2, but how much of those features will be outdated a few years down the road? Where if it's just software, it can migrate towards whatever is current and popular a little bit easier. From this approach, there could still be 8 cogs (or whatever number) but also have smaller 'atomic cogs' that could also have a round robin approach, but in parallel with the existing 8 cogs as to not interfere with any deterministic timing. The atomic cogs could be programmed in a very similar way to FPGA cells and perform basic functions. Some of the new micro controllers are allowing just this type of programming behavior and seem to be moving in this general direction.
...Let me ask.... isn't that one of the core premises of the Propeller? I applaud the efforts of feature packing the Propeller2, but how much of those features will be outdated a few years down the road? Where if it's just software, it can migrate towards whatever is current and popular a little bit easier.
That's more mirage than reality, because Software may be flexible, but it is also very slow.
P2 uses the smarter approach of using hardware to do the bit-level stuff, and then software can work above that.
From this approach, there could still be 8 cogs (or whatever number) but also have smaller 'atomic cogs' that could also have a round robin approach, but in parallel with the existing 8 cogs as to not interfere with any deterministic timing. The atomic cogs could be programmed in a very similar way to FPGA cells and perform basic functions. Some of the new micro controllers are allowing just this type of programming behavior and seem to be moving in this general direction.
Yes and no. There are also many more designers, simply putting in a lot of MCUs.
Quite decent MCUs are now cheaper than ADCs, or even IO expanders.
They get that 'atomic cog' you describe, and deterministic timing, and even better, they get software sign-off benefits.
Highest I've seen recently on 'putting in a lot of MCUs' is 16 AVRs mentioned on one PCB.
I was perusing this thread the other day and while reading comments about what microcontrollers are used "professionally" I decided to take a look at products that I have built at work over the past 5 or so years to make a usage chart. I work for an EMS (Electronics Manufacturing Service provider or "contract manufacturer") and we serve numerous industries, from medical products and instruments, sensor based mesh-networking devices, high end video hardware (HD and 4K), building access/security, HVAC control systems, high end programmable power supplies, vehicle add-ons that interface directly with the vehicle computer, agricultural inspection equipment, robotics systems, and LED lighting/control. Heck, we even make a 802.11 wireless module for washing machines.
In reviewing microcontrollers we have populated on to circuit boards, here is the list, from highest usage to lowest usage:
Atmel AVR and Microchip PIC pretty much tie for the first spot
Xilinx FPGAs of every size imaginable
TI MSP430 (many paired with a CC2420)
ARM devices: Freescale, Analog Devices, and NXP
Cypress PSOC
Misc specialized usage microcontrollers from various manufacturers
Propeller (yep, 3 different boards a few years ago)
Intel MCS-96 (2 legacy boards still in production)
Phillips 80C31 (we used to build 2 oil pipeline monitoring 28.8 k modems a few years ago)
TI Piccolo 32 bit MCU (on 1 board)
XMOS (1 USB DAC Audio device that never could get the chip to work to published specs even with XMOS engineers helping)
Rayman,
It works really really well when you are reading machine wiring diagrams all day long. The two merge almost symbiotically.
The way to look at Ladder Logic is as a top level managerial feature. It does the gluing together. It can do some processing but the real computations are usually in separate modular hardware (Say a defect detector) with simplified ins and outs that suits the Ladder.
The defect detector may well have a DSP running latest image analysis algorithms. But simply provides a basic pass/fail digital output to the PLC. Or it might have categorised results passed over EtherCAT or some other industrial network. The PLC then accordingly operates the multitude of parts for machine and linking conveying systems in an easy to follow, and editable, logic flow.
We, at work, had an out of production machine controller go down recently that we had no source code for. This is a second-hand machine and the machine OEM is long dead. It was a 10.4" panel PC based compiled solution, so we had no way to edit the binary code, ie: Not a PLC. Luckily, we are currently not running at production capacity and the bigger second machine can absorb the workload for the time being. That still meant relearning the product set-up for the other machine, so no-one was particularly happy.
This has resulted in us calling in quotes to replace and reprogram the machine's control system. Aside from the still unknown time frame required, it is likely going to be about four times the cost of just replacing the estimated $6000 controller and reloading/recompiling the existing software.
Comments
This reminded me that I wish Spin had more of a C++ syntax...
Now that I think about it, I suppose Spin with a more C++ syntax would be similar to JavaScript...
"The syntax of JavaScript is actually derived from C"
Python and Spin both use white space, but that's about all they have in common...
Actually, ALGOL is generally considered the root for all the languages you mention.
Yes it is true that you can get exactly or almost exactly the same source code to run as C or Javascript and give the same results. The syntax is very similar that way.
On the other hand it's very likely to do something completely different. The meaning, is very different.
Most would take the view that it's the semantics that makes the language not the syntax.
How are you going to do this in C or C++:
"use strict"; function Actor(name) { let lines = 0; return function sayLine(line) { name = name; console.log(`${++lines}: ${name}: ${line}`); }; } var heater = Actor('Heater'); var rayman = Actor('Rayman'); heater(`My dog's go no nose.`); rayman(`Oh, how does it smell?`); heater(`Awful.`); heater(`When is a door not a door?`); rayman(`I don't know, when is a door not a door`); heater(`When it's ajar`);Outputs:@mindrobots
Yes, ALGOL is the mother of all modern "structured programming" languages. The first to be built from a formal specification, BNF. If you squint really hard most languages we use today look like ALGOL. I don't recall that ALGOL had lambdas and closures and first class functions though.
Anyway, I don't write weird code like that, but I bet something very similar can be done in C++
Ultimately anything one can do in Javascript one can do in C++ or even C.
We know this is true because one can:
1) Write a JS interpreter in C.
2) Include that interpreter into your C program
3) Write some JS as a string in C.
4) Run that string through the JS interpreter.
That's all a bit meta though.
In Javascript you can write:
x = 3.14159; x = "Some string"; x = ["an", "array", "of", "mixed", types, 9, 5, {x: 4, y: 10}]; x = {x: 4, y: 10}; x = function (param) { // code here. }But to do that in C++ you are going to have to define some weird class for xclass WeirdThing { ... }and define x as a weird thing:And use lots of operator overloading of "="
When you have done all that you start to realize how different the C++ and JS languages are
Well, it's a contrived example. But it demonstrates first class functions and closures, which can be very useful in non-weird situations.
It's a bit of a different view of program construction.
Ok, I'll step up to bite on a few of these...
- What's good/effective about them?
Price and availability. I've got varieties of microcontrollers and microcomputers sitting here on my desk.
The favoured units are those which are which are inexpensive enough to drop into projects at a low price point.
Current consistent players are the Raspberry Pi Zero (although hurt right now due to availability thanks to Rpi3 production, but priced at a point where I don't mind using them frequently in projects.) PICAXE, PROPELLER, and PIC. I wish I could say that I use any of them in my day work, but none of them are proven to be reliable enough for industrial control. (A whole different breed of controllers there.) Provide an actual product. I don't care if it's not perfect, I'm willing to invest myself in the development process and incorporate the improved version 2, 3, 4, and so on designs as they become physically available.
- What's bad/frustrating about them?
Bad IDEs and compiler chains. Worse yet strange language limitations. Continue to head toward modern languages were we can use the development platform of our own choosing. Python, C, and I hate to admit it, Java a good choices right now, but certainly not the only ones. I'm not a fan of web-based interfaces. Give me console/Ethernet/USB access. Hardware interfacing needs to be friendly on both 3v and 5v (tolerant) levels. Heck if educational considerations are still of interest, drop in some PLC stuff and definitely consider some tutorials on binary, hex, and octal counting.
- Is there an increasing sense of liberation using modern microcontrollers, or do you sense a long arm of increasing control?
Dear god, every new design seem to bring more programming abstract layers with it preventing me from being close to the hardware itself. This is a weakness that seem to come more with "microcomputers" than with "microcontrollers", but the distinction between these two is starting to become very fuzzy, especially for those who simply want to get things done and don't really care. Perhaps this is a fact of the industry, but the closeness to the actually I/O of the Propeller is certainly something I'd always appreciated about the chip.
- Are they fun?
If you give me something that doesn't try to do EVERYTHING, but does the things it's designed to do very well, then yes it's a blast. I prefer the challenge of a lowered bar anyway.
<LURKING>
Thanks, Everyone Else, for your posts, too.
In what way?
What kind of industrial control are we talking about here?
I do agree about the complexity of modern devices. Doing small and simple things seems to get harder everyday.
That bodes well for Prop2.
I miss you... and Ohio.
You need to take a look at the P2v. I've got one if you want it. A9... only the best for friends.
best regards
Rich
He's talking about the kits more than the chips. Industrial control equipment is DIN-rail mounted, 24Vdc, with opto-isolation all round, including analogue channels.
As far as Opto-Isolation this is basically done as described above, but it;s not always locked to a specific voltage. Voltages can be all over the place... 12V, 24V, 0V-10V, 0V-20V, 4ma-20ma, etc.. Typically power to the micro and supporting circuitry has it's own galvanic isolation from the mains with an on-board power supply and Earth ground is kept separate from Circuit ground unless there is any kind of human interaction. In that case the Circuit ground is the same potential as Earth ground. Where Opto isolation is needed is only to prevent ground loops on I/O's. Anything powered on the PCB board such as relays, motors, etc. don't necessarily need isolation, unless there is potential for a ground loop. For example, we have a motor controller card that takes an input signal from 0V to 10V to control the speed of a 90V DC motor, however the motor controller input is NOT isolated from the mains. (This is the fault of the manufacturer of the motor controller card) In this case you would need a linear Opto-Isolator to convey the 0V to 10V signal from the micro controller board or some other mechanism to convey an analog value... i.e. PWM
As to the state of microcontrollers these days? I have been programming micros for 35 years starting with the 6502 when I was 12 years old. I'm old school in the sense that I prefer to program in Assembly language, I don't like C, I don't really even like Basic, heck I can't even type without looking at the keyboard ... so that said, that removes any bias that a higher level programming language might introduce. I might also add, that I am completely self taught (which might explain the typing skills ... at 12-there wasn't much in the way of typing class) so the bias of the "engineering mind" stereo type I mention earlier is also not there. I consider myself completely off-grid and out of the box when it comes to answering the question ... "So what classes did you take to learn that?"... Sure I took classes, but on many occasions I ended up tutoring and teaching a majority of the class... As someone said earlier tonight in the "Propeller Powered Chat room" ... "it's just You and the micro controller when programming in Assembly." <- Completely true. If it's not working right, it's because you programmed it to do exactly what it's not doing right .... In 35 years much has changed, mostly the IDE. A step up from manually keying in the hex codes (which I have done) to program, you used to only be able to use a standard text editor without any syntax checking and then send it off to a compiler that turned the Assembly code into Machine code (or HEX)... Now there are all sorts of things you can do with a modern IDE ... Emulation, Debugging, defining Macro's, etc. ... and even handling page boundaries... <-wait what are those? A real programmer knows, but I will leave that as an exercise for you to find out. Anyway, the micro itself hasn't changed a great deal, I mean sure there are specialized functions that do cool things, and some of those features have been made atomic to the micro controller, but at the same time many of those features have limitations because they are hard coded. Unless you are planning on building an army of many different variations of micro controllers and have a mapped time line of their existence, hard coding a specific feature that may be popular now becomes a time capsule in essence and may be outdated in just few years from now. Most if not all function/features can be programmed in software... think about it, they had to be at one time before they were made an atomic feature. Now, think about why they were made atomic in the first place? It's because you had a Single threaded Controller and needed a background task to take place, or something you could set and forget. .... Let me ask.... isn't that one of the core premises of the Propeller? I applaud the efforts of feature packing the Propeller2, but how much of those features will be outdated a few years down the road? Where if it's just software, it can migrate towards whatever is current and popular a little bit easier. From this approach, there could still be 8 cogs (or whatever number) but also have smaller 'atomic cogs' that could also have a round robin approach, but in parallel with the existing 8 cogs as to not interfere with any deterministic timing. The atomic cogs could be programmed in a very similar way to FPGA cells and perform basic functions. Some of the new micro controllers are allowing just this type of programming behavior and seem to be moving in this general direction.
P2 uses the smarter approach of using hardware to do the bit-level stuff, and then software can work above that.
Yes and no. There are also many more designers, simply putting in a lot of MCUs.
Quite decent MCUs are now cheaper than ADCs, or even IO expanders.
They get that 'atomic cog' you describe, and deterministic timing, and even better, they get software sign-off benefits.
Highest I've seen recently on 'putting in a lot of MCUs' is 16 AVRs mentioned on one PCB.
In reviewing microcontrollers we have populated on to circuit boards, here is the list, from highest usage to lowest usage:
Atmel AVR and Microchip PIC pretty much tie for the first spot
Xilinx FPGAs of every size imaginable
TI MSP430 (many paired with a CC2420)
ARM devices: Freescale, Analog Devices, and NXP
Cypress PSOC
Misc specialized usage microcontrollers from various manufacturers
Propeller (yep, 3 different boards a few years ago)
Intel MCS-96 (2 legacy boards still in production)
Phillips 80C31 (we used to build 2 oil pipeline monitoring 28.8 k modems a few years ago)
TI Piccolo 32 bit MCU (on 1 board)
XMOS (1 USB DAC Audio device that never could get the chip to work to published specs even with XMOS engineers helping)
You need a PLC with online edits capabilities and hot swappable IO cards.
I guess it works, but I'm not a big fan...
It works really really well when you are reading machine wiring diagrams all day long. The two merge almost symbiotically.
The way to look at Ladder Logic is as a top level managerial feature. It does the gluing together. It can do some processing but the real computations are usually in separate modular hardware (Say a defect detector) with simplified ins and outs that suits the Ladder.
The defect detector may well have a DSP running latest image analysis algorithms. But simply provides a basic pass/fail digital output to the PLC. Or it might have categorised results passed over EtherCAT or some other industrial network. The PLC then accordingly operates the multitude of parts for machine and linking conveying systems in an easy to follow, and editable, logic flow.
This has resulted in us calling in quotes to replace and reprogram the machine's control system. Aside from the still unknown time frame required, it is likely going to be about four times the cost of just replacing the estimated $6000 controller and reloading/recompiling the existing software.