@VBBSim said:
Earlier I did a Early Adopter presentation a bit like yours using TLC ( Touch Logic Control ) which is a parallel visual language in Virtual Breadboard. TLC is a bit like visual ladder logic and it works as a non-programmer language where you click on visual elements in VBB and program by 'doing'. This creates executable storyboards. Here is the presentation.
-----------------SNIP----------------------
I can see what you're doing. I've used Simulator / IDE packages before.... Not as nice as yours though.
However, there is one massive difference between our systems. Each of your macros(?) is it's own independent thread. You as the programmer must control these threads assigning activities to each. You pointed out that the number of threads is limited by number of cogs.
My system is completely independent of number of cogs/cores and the programmer does not even have to think about the number of threads or what they're doing. Code created in KonneX would run on a single core ARM or an AMD Ryzen 3000, 128 core CPU, utilising as many cores as was necessary.
My system is completely independent of number of cogs/cores and the programmer does not even have to think about the number of threads or what they're doing. Code created in KonneX would run on a single core ARM or an AMD Ryzen 3000, 128 core CPU, utilising as many cores as was necessary.
Can you elaborate on how you achieve that? The examples I’ve seen in the video are “classic” graphical programming that I’m familiar with from e.g. Max/MSP. It’s s different paradigm, foregoing the stack for message passing.
But I don’t see how this lends itself to any improvements on concurrency. How do you solve the problems of synchronization, atomic updates, buffering?
My system is completely independent of number of cogs/cores and the programmer does not even have to think about the number of threads or what they're doing. Code created in KonneX would run on a single core ARM or an AMD Ryzen 3000, 128 core CPU, utilising as many cores as was necessary.
Can you elaborate on how you achieve that? The examples I’ve seen in the video are “classic” graphical programming that I’m familiar with from e.g. Max/MSP. It’s s different paradigm, foregoing the stack for message passing.
But I don’t see how this lends itself to any improvements on concurrency. How do you solve the problems of synchronization, atomic updates, buffering?
It took four years development and struggle, so you can probably appreciate that it's not going to be simple to explain how it works in a single reply, but I'll have a go.
KonneX works on the principle of virtual processors. Simple processors with only 5 registers (Resource register, data register, program counter, stack pointer and ID)
Now, the term "virtual processor" does not mean that it emulates a CPU (like Java, for example). It is simply a term that adequately describes what goes on.
The virtual processor has a very limited range of instructions, limited to thread synchronisation and object locking. I doesn't even have basic integer mathematics.
When it encounters an instruction it doesn't understand, it instigates a search. Like the 68000 or 80486 CPUs when they encounter a floating point instruction.
When the required instruction has been located, the instruction (which is simply a call to the correct library function) can be executed independently on its own real CPU core.
So, let us look at an example.
In the image above, there is an instruction marked with "*". This is an integer multiply instruction from an included library.
There are two values that are required for this operation. The top one is the integer signal value given to the "Set Turret Position" instruction (a value between 0 and 5), by it's calling code.
The bottom input comes from the black box. The black box is a built in VP instruction that simply generates a constant integer signal when triggered. The value here is the servo range (180 degrees) divided by the number of possible turret positions (5) = 36.
Let us follow the paths of execution, leading to this multiply.
Each instruction starts with a single VP (with the calling data).
The required turret position value is separated from the input data (the cyan/black dot.... I will have to improve this), creating a new VP.
It is then copied to three separate threads. (You will notice that one of these threads is black, we will come to that later). Creating 2 new VPs.
The top thread goes to be stored in a temporary buffer near exit 1, and the VP for this thread is destroyed.
The lower (blue) one goes into the multiply instruction. However, the other value required (the constant value) hasn't been provided yet, so the turret position value is stored in the instruction's buffer and the VP is destroyed.
The lower (black) line is used to trigger the creation of the constant value. The reason it is black is because it's actual value is unimportant. Black simply indicates that it is used a s NULL trigger.
The VP on this thread, picks up the constant value (36) and puts it into its resource register.
It then moves on to the multiply instruction, providing the required second value for the operation.
Because all the inputs for the multiply have now been satisfied, the VP proceeds to locate the integer library function and then executes it.
The resulting value (turret position * 36) is then put into the data buffer for the Servo.Write instruction.
Meanwhile (and completely independently) the initial VP has copied the data path and created a new VP in the process (the top cyan/black lines).
The very top of these two goes to another buffer (near Exit 0) dumps its data and dies.
The lower of the two cyan/black lines goes to an instruction called "Pickup". This is another built in VP instruction that loads the object handle for the turret servo from the robot's data. This handle is loaded into the resource register of the VP running that thread.
The VP then moves on to the Servo.Write instruction and dumps the servo handle into the instruction buffer.
It doesn't matter which VP gets to the "Write" instruction first or second. The first one dumps its resource register data into the buffer and dies.
The second, picks up all of the buffered data, locates the "Write" instruction within the "Servo" library and executes the function.
Now, "Servo" is an object, and as such, the "Write" instruction requires a handle. It is at this point where object locking can occur.
Prior to executing "Write", the kernel checks the object locks and determines if it is safe to execute the "Write" instruction.
If it is not safe (because it is being accessed elsewhere), the thread is moved to a queue, where it waits for the object to become free.
Side note. In this particular example, locking won't actually be necessary and so won't be implemented in the manner described. I only use it as an example.
Continuing our journey, the "Write" instruction has two exits. The top one is the primary one, where the operation was successful. (The output data is just the servo object handle, but it turns black for reasons we''ll see in a moment).
The lower exit for the "Write" instruction is an error. This is the path taken if the position provided was invalid.
Only one path from any instruction is chosen. It is not possible for an instruction to have two or more "live" exits.
So, in our example, it the turret position given was in range, the top exit is chosen, the VP picks up the value stored in the buffer (small triangle) placed there earlier, and then goes on to exit 0 (OK).
Exit 0 of our map is defined in its instruction definition as outputting the robot's object handle, so the buffer is just there to store this value until it is needed.
Exit 1, on the other hand, is defined to output the errant position value and so, likewise the provided position value is buffered, just in case.
The actual definition of the instructions created by the programmer is entirely up to him (or her). What values are output is a totally free choice. Error exits, could simply be NULL signals if the programmer so desired. However, when defining new instructions, it is good to always ask the question: What would be useful? As such with the "Servo.Write" instruction, it might be useful to be able to examine the errant position value, either in the crash report (if the Exit 1 of your instruction is not implemented in any calling code), or by more code that might be able to do something useful with the data.
For example in an integer overflow situation the instruction to add two 16 bit integers can overflow (an error)... however, that error and the value in that register are useful when extending that add function to perform a 32 bit sum.
I can't help but wonder how hard it would be to use KonneX to generate OpenCL compute shader code. This feels like it would very well target high performance streaming processors like modern gpus.
@Circuitsoft said:
I can't help but wonder how hard it would be to use KonneX to generate OpenCL compute shader code. This feels like it would very well target high performance streaming processors like modern gpus.
There's no reason why not, although you'd never get the same sort of performance as GPUs doing simple calculations. In order to make the best of the parallelism offered by KonneX, the code executed by each thread would have to do more. GPUs are like a printing press or sheet metal stamp. Load up the registers or RAM and "bang" they perform a single operation. KonneX would never be able to compete (sans GPU) even with 1000 cores at its disposal. However, when performing dissimilar operations, it would be able to do better.
@Circuitsoft said:
GPUs are getting to be a lot more general than you may realize. Shadertoy.com is an interesting place to experiment with what shaders can do.
I really don't know what GPUs are capable of. For me, it is not a concern.
Like any programming language, there is absolutely no reason why KonneX could not be used with them. They would be treated like any other device.
Like conventional code, the driver would manage the loading, unloading of data and the triggering of the required operations. Whether these operations are single instructions or complete routines, is neither here nor there.
The way I would envisage it, would be similar to the office photocopier with an operator. Staff would approach the operator with a bunch of paper to copy, together with instructions about quantity and collation. The operator would take these and schedule them in a queue. When each job was completed, the associated members of staff would be notified.
In the same way, utilising the GPU would be a case of calling the GPU library with a bunch of data and the desired operation, with a single block dragged on to the drawing board. When executed, the calling code would simply wait until the operation was complete, before continuing.
For those who weren't at the last live forum, KonneX is still going.
After some health issues and discussions with my partner about where I should be directing my spare time (if you follow my meaning... what is it with women and that?), I resurrected the project in January.
The IDE is currently being rewritten in Java (grrrr *) in order to be cross-platform. I am also simplifying the interface so that it is more intuitive, whilst removing access to some of the cool tricks that are available in the KonneX kernel that only served to confuse the programmer. (Maybe, I can re-introduce these later in a "pro" edition).
I noticed whilst listening to others in the live forum, that some developers have got Patreon or Ko-Fi, so I've opened my own Ko-Fi account here https://ko-fi.com/konnex
If you would like to support me in this venture, I would be extremely grateful (it would also help persuading the other half that it is worth spending time on )
Java - great language ruined by overly obscure, complicated and poorly implemented libraries and documentation.
I would think that the Props would be ideal targets for Node Red
A controls engineer at one of my automotive customers was inspired by my Android HMI solution and so now they are looking to replace PLCs with Node Red
@Mickster said:
I would think that the Props would be ideal targets for Node Red
A controls engineer at one of my automotive customers was inspired by my Android HMI solution and so now they are looking to replace PLCs with Node Red
Craig
I looked at Node Red, and doubt your claims that it would work well on a P2. Firstly, Node Red runs on Node.js which, itself runs on JavaScript. Although they boast that Node Red will run on the Raspberry Pi, it does so under Linux. The rather misrepresented claim that it also runs on Arduino, is utterly false. Essentially, Arduinos (Arduini?) can be part of the Node Red control network, only as basic switches and controllers that have to be controlled externally by the real Node Red system. They are not independently running their own version of Node Red, but almost become passive devices, simply receiving commands and responding.
The P2 is not capable of running Linux and therefore incapable of running Node Red. Although I'm sure that it would be capable of running the remote control software for Node Red, you would reduce a perfectly capable processor into nothing more than a switch, which seems a bit of a waste.
I guess "target" wasn‘t what I actually meant. No, I use tablets as HMIs for Prop-based control systems. I was thinking more along the lines of a Prop being commanded by a Node Red system. TBH, I haven‘t spent time looking at NR because I write my own Android apps for driving multi-axis servo-controlled machine tools and NR wouldn‘t be up to this.
PLCs.net is where you need to promote a somewhat developed product. It's so darned painful reading the posts on there....the $$$$ involved for stupid issues.
The Prop could change everything, if we can ever get their attention.
PLCs.net is where you need to promote a somewhat developed product. It's so darned painful reading the posts on there....the $$$$ involved for stupid issues.
The Prop could change everything, if we can ever get their attention.
Craig
The P2 is one of the intended targets for this system. Firstly, the P2 has more cores than any other micro-controller, yet no multi-threaded programming system. Secondly, I intend to aim this product at the education market (which Parallax are deeply involved with). It's a good way to get kids programming without having to learn a programming language. What's more, any human language can be used, so native speakers of languages other than English won't need to learn English in order to learn programming languages.
Additionally, this is not a tool for programming PLCs or ASICs (I added this after following the link). It is not circuit related, it is not a state machine. It is a flow based zero code programming system.
Granted but you're preaching to the choir. I read your posts like you are revealing the very reason why we're already here...We know this
Personally, I am an integrator, not a programming wizard....but even I am seriously kicking some posterior.
I have to mix with pneumatics, hydraulics, mechanics, HV electrical and then, I sit down and program a real-time control system. Easy with FlexBasic, darned if I need someone else's system to string stuff together. It will never know my priorities and it will always have overhead.
Secondly, I intend to aim this product at the education market (which Parallax are deeply involved with). It's a good way to get kids programming without having to learn a programming language.
So kind but you seek financial support from this community?
@Mickster said: Secondly, I intend to aim this product at the education market (which Parallax are deeply involved with). It's a good way to get kids programming without having to learn a programming language.
So kind but you seek financial support from this community?
Craig
Ummm???? What? No... jeez what has this world come to when everyone just assumes you're out to squeeze money out of people?
What about community, encouragement, discussion. What just because I have a donations page set up??? So damn what.... I GOT THE IDEA FROM ONE OF YOU GUYS!
It's bullcrap like this that just makes me want give up and just say "Screw it, let the world do without.". It's so damn hard trying to innovate when everyone just wants to stomp on you.
Just wanted to say that I watched the video, you did a great job with those animations, and encourage you to 'keep going'. These things are 'never worth it', until they really are.
There's a good variety of experience and opinion here in the forums, it comes from diverse viewpoints. All this will help form Konnex into whatever it will end up becoming
“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford
sigh
All I'm trying to do here is produce a mew way to program computers that easily and intuitively allows anyone to program without having to learn any computer language.
A system that automatically takes advantage of and handles multiple cores.
A system that can easily be translated into any human language, allowing people to program in Chinese, Arabic, Thai...
A system that even children can pick up and put together programs like Lego or Meccano.
A system that avoids the escalating update races that currently plague software development.
After 15 years, I guess the world still ain't ready.
Oh well, I'm on my own again. Sorry to have bothered you all. I'll target the ESP32 instead.
Well, esp32 has got a multitasking operating system. So this part of your system will not be so new there too.
On the other hand the number of customers there will be bigger so the chance to find ones who have been waiting for your system might be larger.
I think you will need to have a working system, that can be tried to convince people. Unfortunately such system has to have a large number of libraries, because this will decide, whether the system is better to use than Arduino.
I do think in pictures so I have tried graphical programming systems. Up to now I have not found one, which was better than writing programs as indented text and use an Editor that is capable of code folding for zooming.
The advantage to use different languages is questionable. Excel has the functions in German here. I do think that the disadvantages are greater than the advantages....
I do not understand, why your system would need less updates?
@Nix said:
“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford
sigh
All I'm trying to do here is produce a mew way to program computers that easily and intuitively allows anyone to program without having to learn any computer language.
A system that automatically takes advantage of and handles multiple cores.
A system that can easily be translated into any human language, allowing people to program in Chinese, Arabic, Thai...
A system that even children can pick up and put together programs like Lego or Meccano.
A system that avoids the escalating update races that currently plague software development.
After 15 years, I guess the world still ain't ready.
Oh well, I'm on my own again. Sorry to have bothered you all. I'll target the ESP32 instead.
Do what you can. Do what you want. Write what you want to write, use or play with.
I already wrote an ancient, 80's style Basic interpreter. It is fun. It works. Who needs the ancient language in its ancient form?
Maybe someone else will use it or play with it. Maybe not, but I am sure there will be a day I will use it not only for playing.
Several years ago I started to play with OS-less Raspberry Pi.. from scratch, so I did a demo program that displayed moving squares on the screen. A friend from the university asked me - what for? What is the real use of the moving squares on the monitor?
The answer was simple, there is no real use. Eccept I optimized display procedures added this, added that and after several years it it ended as a window system on a OS-less RPi that can also get a picture form a camera. Fast. Without OS layers.
Then it was used in several projects that needed something that have a camera and react fast.
Thinking some more about this.
In the systems for simulation where graphical programming actually is used, paths are data, not sequence of instructions. This makes zooming possible. A path in electronics stands for current together with voltage, which can be seen as a trigger of supply. So paths should be a combination of variables with the trigger that either a need for an update is there or an update has been pushed.
It is interesting, that the video actually shows the flow of the product too. The railway transports the data.
Perhaps some graphical Modula would be the thing?
Comments
I can see what you're doing. I've used Simulator / IDE packages before.... Not as nice as yours though.
However, there is one massive difference between our systems. Each of your macros(?) is it's own independent thread. You as the programmer must control these threads assigning activities to each. You pointed out that the number of threads is limited by number of cogs.
My system is completely independent of number of cogs/cores and the programmer does not even have to think about the number of threads or what they're doing. Code created in KonneX would run on a single core ARM or an AMD Ryzen 3000, 128 core CPU, utilising as many cores as was necessary.
Can you elaborate on how you achieve that? The examples I’ve seen in the video are “classic” graphical programming that I’m familiar with from e.g. Max/MSP. It’s s different paradigm, foregoing the stack for message passing.
But I don’t see how this lends itself to any improvements on concurrency. How do you solve the problems of synchronization, atomic updates, buffering?
It took four years development and struggle, so you can probably appreciate that it's not going to be simple to explain how it works in a single reply, but I'll have a go.
KonneX works on the principle of virtual processors. Simple processors with only 5 registers (Resource register, data register, program counter, stack pointer and ID)
Now, the term "virtual processor" does not mean that it emulates a CPU (like Java, for example). It is simply a term that adequately describes what goes on.
The virtual processor has a very limited range of instructions, limited to thread synchronisation and object locking. I doesn't even have basic integer mathematics.
When it encounters an instruction it doesn't understand, it instigates a search. Like the 68000 or 80486 CPUs when they encounter a floating point instruction.
When the required instruction has been located, the instruction (which is simply a call to the correct library function) can be executed independently on its own real CPU core.
So, let us look at an example.
In the image above, there is an instruction marked with "*". This is an integer multiply instruction from an included library.
There are two values that are required for this operation. The top one is the integer signal value given to the "Set Turret Position" instruction (a value between 0 and 5), by it's calling code.
The bottom input comes from the black box. The black box is a built in VP instruction that simply generates a constant integer signal when triggered. The value here is the servo range (180 degrees) divided by the number of possible turret positions (5) = 36.
Let us follow the paths of execution, leading to this multiply.
Each instruction starts with a single VP (with the calling data).
The required turret position value is separated from the input data (the cyan/black dot.... I will have to improve this), creating a new VP.
It is then copied to three separate threads. (You will notice that one of these threads is black, we will come to that later). Creating 2 new VPs.
The top thread goes to be stored in a temporary buffer near exit 1, and the VP for this thread is destroyed.
The lower (blue) one goes into the multiply instruction. However, the other value required (the constant value) hasn't been provided yet, so the turret position value is stored in the instruction's buffer and the VP is destroyed.
The lower (black) line is used to trigger the creation of the constant value. The reason it is black is because it's actual value is unimportant. Black simply indicates that it is used a s NULL trigger.
The VP on this thread, picks up the constant value (36) and puts it into its resource register.
It then moves on to the multiply instruction, providing the required second value for the operation.
Because all the inputs for the multiply have now been satisfied, the VP proceeds to locate the integer library function and then executes it.
The resulting value (turret position * 36) is then put into the data buffer for the Servo.Write instruction.
Meanwhile (and completely independently) the initial VP has copied the data path and created a new VP in the process (the top cyan/black lines).
The very top of these two goes to another buffer (near Exit 0) dumps its data and dies.
The lower of the two cyan/black lines goes to an instruction called "Pickup". This is another built in VP instruction that loads the object handle for the turret servo from the robot's data. This handle is loaded into the resource register of the VP running that thread.
The VP then moves on to the Servo.Write instruction and dumps the servo handle into the instruction buffer.
It doesn't matter which VP gets to the "Write" instruction first or second. The first one dumps its resource register data into the buffer and dies.
The second, picks up all of the buffered data, locates the "Write" instruction within the "Servo" library and executes the function.
Now, "Servo" is an object, and as such, the "Write" instruction requires a handle. It is at this point where object locking can occur.
Prior to executing "Write", the kernel checks the object locks and determines if it is safe to execute the "Write" instruction.
If it is not safe (because it is being accessed elsewhere), the thread is moved to a queue, where it waits for the object to become free.
Side note. In this particular example, locking won't actually be necessary and so won't be implemented in the manner described. I only use it as an example.
Continuing our journey, the "Write" instruction has two exits. The top one is the primary one, where the operation was successful. (The output data is just the servo object handle, but it turns black for reasons we''ll see in a moment).
The lower exit for the "Write" instruction is an error. This is the path taken if the position provided was invalid.
Only one path from any instruction is chosen. It is not possible for an instruction to have two or more "live" exits.
So, in our example, it the turret position given was in range, the top exit is chosen, the VP picks up the value stored in the buffer (small triangle) placed there earlier, and then goes on to exit 0 (OK).
Exit 0 of our map is defined in its instruction definition as outputting the robot's object handle, so the buffer is just there to store this value until it is needed.
Exit 1, on the other hand, is defined to output the errant position value and so, likewise the provided position value is buffered, just in case.
The actual definition of the instructions created by the programmer is entirely up to him (or her). What values are output is a totally free choice. Error exits, could simply be NULL signals if the programmer so desired. However, when defining new instructions, it is good to always ask the question: What would be useful? As such with the "Servo.Write" instruction, it might be useful to be able to examine the errant position value, either in the crash report (if the Exit 1 of your instruction is not implemented in any calling code), or by more code that might be able to do something useful with the data.
For example in an integer overflow situation the instruction to add two 16 bit integers can overflow (an error)... however, that error and the value in that register are useful when extending that add function to perform a 32 bit sum.
I can't help but wonder how hard it would be to use KonneX to generate OpenCL compute shader code. This feels like it would very well target high performance streaming processors like modern gpus.
There's no reason why not, although you'd never get the same sort of performance as GPUs doing simple calculations. In order to make the best of the parallelism offered by KonneX, the code executed by each thread would have to do more. GPUs are like a printing press or sheet metal stamp. Load up the registers or RAM and "bang" they perform a single operation. KonneX would never be able to compete (sans GPU) even with 1000 cores at its disposal. However, when performing dissimilar operations, it would be able to do better.
GPUs are getting to be a lot more general than you may realize. Shadertoy.com is an interesting place to experiment with what shaders can do.
I really don't know what GPUs are capable of. For me, it is not a concern.
Like any programming language, there is absolutely no reason why KonneX could not be used with them. They would be treated like any other device.
Like conventional code, the driver would manage the loading, unloading of data and the triggering of the required operations. Whether these operations are single instructions or complete routines, is neither here nor there.
The way I would envisage it, would be similar to the office photocopier with an operator. Staff would approach the operator with a bunch of paper to copy, together with instructions about quantity and collation. The operator would take these and schedule them in a queue. When each job was completed, the associated members of staff would be notified.
In the same way, utilising the GPU would be a case of calling the GPU library with a bunch of data and the desired operation, with a single block dragged on to the drawing board. When executed, the calling code would simply wait until the operation was complete, before continuing.
Ok.... 101 views to go until I reach 1K... keep the questions coming.
I'm currently trying to create an animated video to describe how it works.
For those who weren't at the last live forum, KonneX is still going.
After some health issues and discussions with my partner about where I should be directing my spare time (if you follow my meaning... what is it with women and that?), I resurrected the project in January.
The IDE is currently being rewritten in Java (grrrr *) in order to be cross-platform. I am also simplifying the interface so that it is more intuitive, whilst removing access to some of the cool tricks that are available in the KonneX kernel that only served to confuse the programmer. (Maybe, I can re-introduce these later in a "pro" edition).
I noticed whilst listening to others in the live forum, that some developers have got Patreon or Ko-Fi, so I've opened my own Ko-Fi account here https://ko-fi.com/konnex
)
If you would like to support me in this venture, I would be extremely grateful (it would also help persuading the other half that it is worth spending time on
I would think that the Props would be ideal targets for Node Red
A controls engineer at one of my automotive customers was inspired by my Android HMI solution and so now they are looking to replace PLCs with Node Red
Craig
I looked at Node Red, and doubt your claims that it would work well on a P2. Firstly, Node Red runs on Node.js which, itself runs on JavaScript. Although they boast that Node Red will run on the Raspberry Pi, it does so under Linux. The rather misrepresented claim that it also runs on Arduino, is utterly false. Essentially, Arduinos (Arduini?) can be part of the Node Red control network, only as basic switches and controllers that have to be controlled externally by the real Node Red system. They are not independently running their own version of Node Red, but almost become passive devices, simply receiving commands and responding.
The P2 is not capable of running Linux and therefore incapable of running Node Red. Although I'm sure that it would be capable of running the remote control software for Node Red, you would reduce a perfectly capable processor into nothing more than a switch, which seems a bit of a waste.
I guess "target" wasn‘t what I actually meant. No, I use tablets as HMIs for Prop-based control systems. I was thinking more along the lines of a Prop being commanded by a Node Red system. TBH, I haven‘t spent time looking at NR because I write my own Android apps for driving multi-axis servo-controlled machine tools and NR wouldn‘t be up to this.
Craig
I did a thing... I created a video to try and explain how KonneX works.
https://youtube.com/watch?v=YMtXalAmXNI
@Nix said:
And your example of the standard CPU program ends on HCF
@Nix
Great concept but wrong audience
PLCs.net is where you need to promote a somewhat developed product. It's so darned painful reading the posts on there....the $$$$ involved
for stupid issues.
The Prop could change everything, if we can ever get their attention.
Craig
The P2 is one of the intended targets for this system. Firstly, the P2 has more cores than any other micro-controller, yet no multi-threaded programming system. Secondly, I intend to aim this product at the education market (which Parallax are deeply involved with). It's a good way to get kids programming without having to learn a programming language. What's more, any human language can be used, so native speakers of languages other than English won't need to learn English in order to learn programming languages.
Additionally, this is not a tool for programming PLCs or ASICs (I added this after following the link). It is not circuit related, it is not a state machine. It is a flow based zero code programming system.
@Nix
Granted but you're preaching to the choir. I read your posts like you are revealing the very reason why we're already here...We know this
Personally, I am an integrator, not a programming wizard....but even I am seriously kicking some posterior.
I have to mix with pneumatics, hydraulics, mechanics, HV electrical and then, I sit down and program a real-time control system. Easy with FlexBasic, darned if I need someone else's system to string stuff together. It will never know my priorities and it will always have overhead.
Craig
Secondly, I intend to aim this product at the education market (which Parallax are deeply involved with). It's a good way to get kids programming without having to learn a programming language.So kind but you seek financial support from this community?
Craig
Ummm???? What? No... jeez what has this world come to when everyone just assumes you're out to squeeze money out of people?
What about community, encouragement, discussion. What just because I have a donations page set up??? So damn what.... I GOT THE IDEA FROM ONE OF YOU GUYS!
It's bullcrap like this that just makes me want give up and just say "Screw it, let the world do without.". It's so damn hard trying to innovate when everyone just wants to stomp on you.
Just wanted to say that I watched the video, you did a great job with those animations, and encourage you to 'keep going'. These things are 'never worth it', until they really are.
There's a good variety of experience and opinion here in the forums, it comes from diverse viewpoints. All this will help form Konnex into whatever it will end up becoming
The "ONE OF YOU GUYS" tend to start-out with a working software product. Anyone can produce vaporware.
How far has this gone?
Craig
"Firstly, the P2 has more cores than any other micro-controller, yet no multi-threaded programming system"
Hm, Catalina supports threads and Taqoz has polled tasks. Of course spin2 and Flexprop support programming of all cores. ?
Nice video!
I politely request that you refrain from further replies to any of my comments. They are neither wanted nor helpful.
Thanks
I know about Flexprop and Spin2... but these cores are assigned by the programmer. It is not automatic. I am unaware of Catalina or Taqoz.
“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford
sigh
All I'm trying to do here is produce a mew way to program computers that easily and intuitively allows anyone to program without having to learn any computer language.
A system that automatically takes advantage of and handles multiple cores.
A system that can easily be translated into any human language, allowing people to program in Chinese, Arabic, Thai...
A system that even children can pick up and put together programs like Lego or Meccano.
A system that avoids the escalating update races that currently plague software development.
After 15 years, I guess the world still ain't ready.
Oh well, I'm on my own again. Sorry to have bothered you all. I'll target the ESP32 instead.
Well, esp32 has got a multitasking operating system. So this part of your system will not be so new there too.
On the other hand the number of customers there will be bigger so the chance to find ones who have been waiting for your system might be larger.
I think you will need to have a working system, that can be tried to convince people. Unfortunately such system has to have a large number of libraries, because this will decide, whether the system is better to use than Arduino.
I do think in pictures so I have tried graphical programming systems. Up to now I have not found one, which was better than writing programs as indented text and use an Editor that is capable of code folding for zooming.
The advantage to use different languages is questionable. Excel has the functions in German here. I do think that the disadvantages are greater than the advantages....
I do not understand, why your system would need less updates?
Do what you can. Do what you want. Write what you want to write, use or play with.
I already wrote an ancient, 80's style Basic interpreter. It is fun. It works. Who needs the ancient language in its ancient form?
Maybe someone else will use it or play with it. Maybe not, but I am sure there will be a day I will use it not only for playing.
Several years ago I started to play with OS-less Raspberry Pi.. from scratch, so I did a demo program that displayed moving squares on the screen. A friend from the university asked me - what for? What is the real use of the moving squares on the monitor?
The answer was simple, there is no real use. Eccept I optimized display procedures added this, added that and after several years it it ended as a window system on a OS-less RPi that can also get a picture form a camera. Fast. Without OS layers.
Then it was used in several projects that needed something that have a camera and react fast.
So, simply do your things.
+1
Thinking some more about this.
In the systems for simulation where graphical programming actually is used, paths are data, not sequence of instructions. This makes zooming possible. A path in electronics stands for current together with voltage, which can be seen as a trigger of supply. So paths should be a combination of variables with the trigger that either a need for an update is there or an update has been pushed.
It is interesting, that the video actually shows the flow of the product too. The railway transports the data.
Perhaps some graphical Modula would be the thing?