[I am fixing the speed problem, it will run as fast as c++. By using different software paradigms we can code with less boiler plate code.
I need to understand more from you what part takes 3 times to understand is it the oop, language syntax, gc, or libraries.
As I said trying to cram everything into the OO paradigm distorts design, the syntax is unnecessarily prolix DRY wasn't heard of when the language was invented but later some simplifications retrofitted, GC has no effect on comprehension, and the libraries are the worst because there is so much you have to read before you can start to use them.
If you're going to start arguing those points, then perhaps you have already made up your mind, and you should just release the software and let it live or die on its own merits, or lack of.
So, good luck and
[I am fixing the speed problem, it will run as fast as c++. By using different software paradigms we can code with less boiler plate code.
I need to understand more from you what part takes 3 times to understand is it the oop, language syntax, gc, or libraries.
As I said trying to cram everything into the OO paradigm distorts design, the syntax is unnecessarily prolix DRY wasn't heard of when the language was invented but later some simplifications retrofitted, GC has no effect on comprehension, and the libraries are the worst because there is so much you have to read before you can start to use them.
If you're going to start arguing those points, then perhaps you have already made up your mind, and you should just release the software and let it live or die on its own merits, or lack of.
So, good luck and
What do you think about kotlin or swift?
What do you think about kotlin or swift?
I don't develop for those platforms these days. But certainly less verbiage than Java.
What I don't get, is this thing to release a new board for your own pet language.
Is your processor somehow specifically engineered to run Java? Or will it just be another stock every-day processor with a pre-loaded bootloader/firmware glob that goes in before your java code?
My guess, is it's more that you can't make the money off the software, but if you shove the software in a chip, you can skim a nice profit off the "service" of adding value. And worse, if you make it a new board, it can be different enough that people have to come to your design to run that software, and mayhaps can't decide to scub your software off of it and put Micropython on instead.
What I'd like to see, is an extensible tool that takes source code in one end, and produces an image ready to burn out the other. Specifying a processor as the target, means I probably then have to specify also a lot of other things. Specifying a board as the target, locks down several of those blanks, and provides defaults for several more. One of those options, would be the choice of "operating system", so an Arduino normally comes with its bootloader, but that could have already been replaced by this Java runtime, maybe it's just known to be corrupted on this particular board, or I might just want of the various alternatives, or, the tool might recognise that the language coming in requires a different runtime to the one already present, and so offer to include it (or one of said alternatives) alongside the application image. And then there's the delivery mode; could be a straight up hex image or two (the bootloader, for example) ready to burn, could be a combined image of both the bootloader and the application for "bare metal" installs to fresh chips, and then you only do application images for update installs. Or at the extreme end, the option to smush it all together because you know you're Micropython code doesn't use the eval() function, and isn't ever going to need to do anything else, so you can do away with all that interpreter nonsense and just generate the microcode, and then feed it to the interpreter source as a constant, and let the compiler boil it all away to a static function — now THAT would be magic indeed (and probably isn't all that far off with modern compilers). And when that's all done, your bootloader/runtime might offer OTA support, and so so a delivery package that takes the output and wraps it up in the correct format too (same layer as the one that converts the binary image into a nice hex file for the burner).
Now THAT is a thing I would like to see. Kind of a mega-gcc. Not this, "oh, I have a new pet language, I'm going to make a brand new board just for it" nonsense. If that Micropython board has some extra bit of hardware that I like, but I don't know Python, why can't I target my Java code at it, it's just a different firmware. (It'd actually be the other way around for me, but, nevermind that.) When Arduino came out, it was pretty much the only game in town for it's target market. Now they're a dime a dozen, and it's time to move on up the chain a little.
<ranty conclusion>
Do I think Java support for microcontrollers is a good idea? Sure… Why not. I'm sure someone will appreciate it. Do I think there should be a new Arduino UNO like board with Java8 programming? No thanks. If you've got something new to add to the board space, then put out a new board as well, and fine, preload it with your Java8 if you like. But I do wish people would stop doing whole new boards that are only a slight tweak on existing ones, just for their own pet language. If you have a significant idea for a new board, then do a new board. If you have a significant idea for a new language, then do a new language. If you happen to have both, then sure, offer them pre-combined as an option, and write "works with X" on the box. Just don't make it a requirement.
</ranty conclusion>
Hi All,
I am trying to build a new development board which you can program in Java with Lambda support.
OK but why?
It has Arduino simplicity like apis to program and use hw peripherals. It make fw upgrade a magic as code can be put to any location.
Swapping codes/apps by dropping or maintaining its state is just an api call. Would you be interested in such a development platform?
What do you think is the best form factor and price point? Any feedback is appreciated!
You can't possibly put a worthwhile Java onto an Arduino class processor and have any redeeming value in the implementation.
package demo;
import eapi.*;
public class App {
public static void main(String args[]) {
final Led led = Led.init('C', 13); // Port C Pin 13
PushButton pushButton = PushButton.init('A',
8, //Port A Pin 8
GPIO.INPUT_PULL_UP,
GPIO.FALLING_EDGE,
200, //debounce
(time) -> {
Core.println("push button event");
led.flip();
});
while (true) {
Looper.loop();
}
}
Best Regards,
First off if I need rapid development on a microprocessor I can use MicroPython which is a much better environment for that type of work. Python is well known and frankly it is easier for those one off projects. If I need something more robust I can use C++ with far more control over the final executable.
On the other hand if I went JAVA I'd have the JVM to slow things down. More likely if want to use a specific JAVA api it will not be supported mainly because there are far too many to choose from. So I have the mess of a slow system and an endless number of apis that may or may not be supported. What is sad is that JAVA had an embedded start but what it has evolved into is just a total disaster no matter what you use it for. There are probably 10-20 other languages that would be a better choice for microprocessor programming.
Just no (tm)
You either learn which language to use on MCUs or play with a garbage language like that on a device that has enough performance to handle it.
Same goes for micropython.
"We have more performance today so lets degrade it to what could be found 20 years ago"
Just stop this nonsense
Well number one no JVM. If you can get either to compile to native code you might have something. Swift is especially interesting as it merges new technology with code that can be written cleanly. The biggest Swift issue is that it is not mature, literally many things are just coming online library wise.
If you went Swift or Kotlin you would have a huge marketing challenge to simply get the languages accepted in the embedded world. Frankly I think the embedded world needs something better than C++. Swift has a lot of potential here but there are not a lot of cross compilers at the moment. So you would need a compiler developer as part of any board development solution. I look at it this way we already know that JAVA in this space is a complete failure due to other attempts so if you went Swift or Kotlin you would not be trying to repeat those failures.
So the question becomes do you have the resources to build up the libraries for the use of these new languages. You also need a cross compiler and a development environment. You could go with a Swift REPL and have an interpreted environment which might work well. However I suspect many developers would prefer a cross development environment where they can tune code size to a specific need. Honestly I've thought about a Swift REPL embedded in a micro processor but I simply don't have the resources to work on something that big. I can see a Swift REPL being better than a MicroPython solution.
[I am fixing the speed problem, it will run as fast as c++. By using different software paradigms we can code with less boiler plate code.
I need to understand more from you what part takes 3 times to understand is it the oop, language syntax, gc, or libraries.
As I said trying to cram everything into the OO paradigm distorts design, the syntax is unnecessarily prolix DRY wasn't heard of when the language was invented but later some simplifications retrofitted, GC has no effect on comprehension, and the libraries are the worst because there is so much you have to read before you can start to use them.
If you're going to start arguing those points, then perhaps you have already made up your mind, and you should just release the software and let it live or die on its own merits, or lack of.
So, good luck and
What do you think about kotlin or swift?
I'm wondering if the market is already saturated with *duino development platforms. Who is your target market for this platform?
A few years ago I experimented with Microsoft .Net Micro Framework - basically embedded C#. I used a Netduino, which as the name suggests, was an Arduino form factor, with a Cortex CPU. I did the 'hello blink led world' and PWM motor code, but I felt the feature rich .Net language was disconnected with the low level programming needs of a microcontroller. It's still around today under the open source .NET Gadgeteer platform, which tries to compete with the mbed programming system from Arm.
Thinking of mbed, and arduino playground, would your Java be integrated with a cloud service? The mbed Nucleo IoT boards for example, can be developed/updated direct from the cloud.
Hi All,
I am trying to build a new development board which you can program in Java with Lambda support.
It has Arduino simplicity like apis to program and use hw peripherals. It make fw upgrade a magic as code can be put to any location.
Swapping codes/apps by dropping or maintaining its state is just an api call. Would you be interested in such a development platform?
What do you think is the best form factor and price point? Any feedback is appreciated!
How would you like to implement it? Write your own JVM? It will be like running emulator. It took Sun/Oracle many years to make it work at reasonable speed.
And also garbage collection and memory management ...
Maybe consider some alternatives like:
- Convert java source code into C / assembly
- Convert java byte code (compiled on your PC) into C / assembly
- Have FPGA and implement your own soft CPU which can run java natively. IMO this one is the best.
I don't think this idea is stupid (but most people here do
)
Java has few advantages compared to C. Easy to learn as a first language. Safety checks. Run/debug your code on PC before uploading it to the board. If you need GUI, Swing probably will be too slow, but something native (AWT) should be ok. Huge amount of open source libraries, for anything you can think of. And the best development IDE, I'm not aware of anything for C/C++ even remotely close to IntelliJ Idea
Java was originally intended for embedded, and is widely used, so why not?
Of course the audience here probably already have a solution that suits them so most wont see the point.
One issue for me is how much usable space will remain on the device after the JVM, Java, and the basics libraries.
Usually with embedded you have two sometimes competing requirements, one is the best performance possible on the device which today means C or C++. The opposite requirement is to get the job done as fast as possible with minimal stress, that is handled today with MicroPython or sometimes even Basic on older systems. Sometimes these issues compete but for the most part tow different domains. Java doesn't really fit either use case.
Maybe a few years down the road Swift embedded on a processor might make sense but right now you either compile a "C: language or run a processor with something like MicroPython on it. I just don't see a future for java and frankly its past in embedded has been a failure.
I don't think this idea is stupid (but most people here do )
Java has few advantages compared to C. Easy to learn as a first language. Safety checks. Run/debug your code on PC before uploading it to the board. If you need GUI, Swing probably will be too slow, but something native (AWT) should be ok. Huge amount of open source libraries, for anything you can think of. And the best development IDE, I'm not aware of anything for C/C++ even remotely close to IntelliJ Idea
I like your spirit of wanting to help people learn to program in embedded MCU's.
However, I think Java is a resource pig for an MCU. Granted the processors have continued to get bigger and bigger.... but MCU's fundamentally mean working with minimal resources, minimal power, minimal memory for a specific purpose. If you want general purpose get a Pi. The higher level your language, the more overhead and resources are consumed to implement it.
I started with the Basic Stamp on my first project. It was easy to access, but it was still programming and too complex to build a product out of. So I rebuilt it in Arduino. Then I rolled my own based on the ATTiny85. I then decided to add an interface, so I used the Atmega328 so I'd have enough lines to run the 5 LED display units. When I looked at doing ethernet I realized how resource intensive it was and then the ESP8266 series came along solving the problem.... actually reversing it because they emulate Arduino.
anyhow, my point is that if someone wants to program in MCU then he or she should be comfortable thinking through byte and line utilization. It's sort of like Haiku for electronics. Microsoft is like cow vomit for code. There is a lot of it, it's very messy, and you aren't really sure what the cow ate.