Avatar for dwallersv


Member since May 2016 • Last active Sep 2016
  • 16 conversations

Most recent activity

  • in ESP8266
    Avatar for dwallersv

    Very interesting (and nice work!).

    IS there anything similar, at all, on the other Espruino platforms? Specifically, I'm interested in the HY-STM32F1 board, where I've been working on a GUI. If I could flash the GUI module code to flash memory, and execute it from there, it would free up a TON of RAM for actual application code.

  • in News
    Avatar for dwallersv

    @allObjects, this reminds me of Objective-C and Next Computer's graphical IDE. That was a time when this sort of methodology for application development was all the rage ('90s). I seem to recall some SmallTalk IDEs that also tried to get actual code-writing completely out of the picture.

    What failed, and still does, is that none of these schemes simplify away the underlying engineering complexity of any real application, in which case the "difficulty" simply shifts from coding to interface definitions and protocols. Having been down this path, one soon finds that any "real world" application of any meaningful functionality and complexity ends up being just as much work -- or more -- to architect, specify, and implement interface and protocol specs, finding that in many cases it's "just easier" to fall back to actual code (C, C++, O-C, Java, whatever) and bang out something concise and efficient.

    It's why these methods faded from the scene.

    IMO, the real revolution for software engineering will come with AI, not IDEs and various alternative ways to spec program algorithms, which is really what this sort of thing is. Rather, when we have AI that we can simply describe a problem to, perhaps in some formal syntax, better if we can just talk to it, and it spits out the program.

    That would free the designer to focus on features, function, behavior, etc.

    The other domain that I think is woefully under-invested-in from the standpoint of software development is failure/defect detection and debugging. So little brainpower, relatively speaking, has been spent on improving and enriching this aspect of code development.

  • in News
    Avatar for dwallersv

    Those of us old enough to have been around for the development/introduction of java, plug-ins, etc., have seen this dance before. The Chrome Web App dealio was nice, but nothing innovative. It's all been tried before.

    And it seems to always end the same way. The reasons are obvious: As long as there are different platforms (which will always be), there will be cross-platform work necessary to support applications across them. This reduces the issue to simply, WHO is going to do that on-going engineering? The app developer or the platform provider?

    As another entrant in this space, we have Flash as well. And others. It's an intractable problem.

  • in General
    Avatar for dwallersv

    Old thread, pointed here by @allObjects due to some work I'm doing with this same stepper.

    Some quick summary precautions to add that are covered here, but buried in all the dialog:

    • The 28BYJ-48 can not handle steps faster than about 2ms apart.
    • Sufficient power is critical. Running the motor driver (usually a ULN2003 chip) directly from the MCU board is very dicey, and will have lots of problems. You should use a separate 5V power supply for the driver board.
  • in Interfacing
    Avatar for dwallersv

    @allObjects yeah, "duds" are always a risk when ordering cheap from China via ebay. And they've gotcha if one or more is bad, 'cause there's no point in trying to return or get a refund on such small amounts (a dollar or two) from those sources.

    That's the trade-off... a risk premium. I've been very luck so far, and everything's been solid that's I've ordered from SLC (Slave Labor China). Some of the fabric my wife has ordered came with Opium residue on it though. Are they ever going to unchain the children from those looms? :-) :-) :-)