4 ms·

There are RP2040 boards (e.g. Pi Pico) that offer similar functionality to Arduino boards, are more powerful than Arduinos, and are much less expensive than (of

by II2II 3y ago

There are RP2040 boards (e.g. Pi Pico) that offer similar functionality to Arduino boards, are more powerful than Arduinos, and are much less expensive than (official) Arduinos. If you are more interested in performance or memory than the I/O options offered by a microcontroller, a Pi Zero is about the same price as Arduino's cheapest offering. You can also develop software for the Pi zero on the Pi Zero, which is considerably easier than developing for microcontrollers. I think Arduino boards are best suited for what they were originally designed for: education. While that covers some of the hobbiest market, it doesn't cover all hobbiests.

dylan604 3y ago
Sure, anybody can program when there are GBs of memory on a Pi as evidenced in the fact that I have a job. Those that can do it in the KBs of memory on an Arduino are on a different level. Depending on all of the things you listed just sounds like lazy to me. /s
- II2II 3y ago
  Sorry if I was a bit ambiguous. I was not referring to the gigabytes of memory or even the abundant number of libraries when I mentioned that it is easier to program Raspberry Pis. Those are certainly factors, though I doubt that many embedded projects will exploit that much memory. In cases where they do exploit the resources, it is probably needed (albeit, likely at the level of megabytes rather than gigabytes). I actually meant the Pis are easier to program since development can be self-hosted. Uploading a program to a microcontroller after each build is a royal pain in the bottom. Debugging (with a debugger) is also annoying, both from the perspective of setting up the software and having the necessary hardware. With respect to laziness, I hold two points of view. I definitely agree the inefficient of resources should be viewed in a negative way. This is especially true when a solution goes from bytes or kilobytes to megabytes or gigabytes. More critically, I believe that laziness is a negative when the inefficiencies lead to less robust code. On the other hand, one of the chief benefits of computers is to reduce the burden placed upon people. Setting up a toolchain for microcontrollers can be nearly as complex as developing code for the microcontroller itself. That strikes me as wrong. Aside: I periodically write software for microcontrollers for fun. One of my favourite exercises involves prototyping with high level code, such as using Arduino libraries, and rewriting it using increasingly low level code. It is how I approach learning a microcontroller, but I am also extremely conscious of both volatile and non-volatile memory usage. I am definitely sympathetic with your notion of avoiding laziness. On the other hand, we should also realize that microcontrollers are often used because we are "lazy". There are many cases where microcontrollers are used even when a basic circuit can accomplish the same task since it is cheaper to throw an absurd number of transistors at something than it is to pursue more efficient solutions. (Labour costs add to project costs, along with the number/type of components, board size, the relative ease of iterating code verses iterating on board revisions, etc..) There are reasons beyond the challenge of generating the most efficient solution possible to consider because the efficiency of development is also a factor. As someone who pursues software and hardware development as a hobby, I often bemoan the state of affairs of commercial products. Yet I also realize that commercial development, or even the motivations of other hobbiests, leads to different perspectives.

by II2II 3y ago

dylan604 3y ago

Sure, anybody can program when there are GBs of memory on a Pi as evidenced in the fact that I have a job. Those that can do it in the KBs of memory on an Arduino are on a different level. Depending on all of the things you listed just sounds like lazy to me. /s

II2II 3y ago
Sorry if I was a bit ambiguous. I was not referring to the gigabytes of memory or even the abundant number of libraries when I mentioned that it is easier to program Raspberry Pis. Those are certainly factors, though I doubt that many embedded projects will exploit that much memory. In cases where they do exploit the resources, it is probably needed (albeit, likely at the level of megabytes rather than gigabytes). I actually meant the Pis are easier to program since development can be self-hosted. Uploading a program to a microcontroller after each build is a royal pain in the bottom. Debugging (with a debugger) is also annoying, both from the perspective of setting up the software and having the necessary hardware. With respect to laziness, I hold two points of view. I definitely agree the inefficient of resources should be viewed in a negative way. This is especially true when a solution goes from bytes or kilobytes to megabytes or gigabytes. More critically, I believe that laziness is a negative when the inefficiencies lead to less robust code. On the other hand, one of the chief benefits of computers is to reduce the burden placed upon people. Setting up a toolchain for microcontrollers can be nearly as complex as developing code for the microcontroller itself. That strikes me as wrong. Aside: I periodically write software for microcontrollers for fun. One of my favourite exercises involves prototyping with high level code, such as using Arduino libraries, and rewriting it using increasingly low level code. It is how I approach learning a microcontroller, but I am also extremely conscious of both volatile and non-volatile memory usage. I am definitely sympathetic with your notion of avoiding laziness. On the other hand, we should also realize that microcontrollers are often used because we are "lazy". There are many cases where microcontrollers are used even when a basic circuit can accomplish the same task since it is cheaper to throw an absurd number of transistors at something than it is to pursue more efficient solutions. (Labour costs add to project costs, along with the number/type of components, board size, the relative ease of iterating code verses iterating on board revisions, etc..) There are reasons beyond the challenge of generating the most efficient solution possible to consider because the efficiency of development is also a factor. As someone who pursues software and hardware development as a hobby, I often bemoan the state of affairs of commercial products. Yet I also realize that commercial development, or even the motivations of other hobbiests, leads to different perspectives.