For this week, most of my time was spent installing all of the various drivers/programs needed to run Arduino and ezDisplay on Windows.
Eventually, I got the files to compile and was able to upload the examples today (after a long and arduous battle with a defective programmer).
I was able to create my own image using the image2cpp site to display (mind the black line, as the screen is refreshing :') ).
I also looked into the functions and capabilities of the ezDisplay board, which weren't too many. Here is what I wrote down so far (it is still a very basic overview).
In summary: I've rebuilt the API used to compile Arduino sketches. The old version would not adapt easily to our needs.
Several weeks ago, when I was doing digging on why the minified Blockly generators did not match the un-minified version, I stumbled on Chromeduino, a Chrome app for Arduino coding. It includes a web server where users can send code to have it compiled. In the source code for the web server, I noticed a /version endpoint with a rather specific output.
Barnabas has a code compiler server as well, with the same specific version endpoint. It turns out compile.barnabasrobotics.com runs this API. Barnabas Blocks uses this site to convert C code generated by Blockly to the machine (binary) code sent to a microcontroller.
However, Chromeduino's compiler server has... problems. To name a few:
There exists an entirely new version of Arduino IDE called arduino-cli that exists to fulfill this need - other programs using Arduino. Instead of doing this, Chromeduino "hacks into" Arduino IDE, which is... problematic:
First, it works by downloading a copy of Arduino IDE (despite never needing to open the actual graphical window) and running a utility program inside it which is not meant to be used by end users (it's more of a middle-man between Arduino IDE's compile button and the actual compiler program).
Since this program is a middleman, it does not try to detect custom libraries, boards, or anything - it looks in and only in the list of places it is told to look (i.e. a list basically hard-coded into Arduino IDE). Specifically, the Chromeduino web server only allows libraries from its own copy of Arduino IDE.
Content like boards and libraries not built into Arduino IDE are installed in another folder outside of Arduino IDE (~/Arduino on *nix and Mac and $HOME\Documents\Arduino on Windows). Chromeduino never looks at these, so it can't support custom boards or libraries.
Instead of asking Arduino IDE to find libraries and boards, Chromeduino tries to do it all - looking for everything in one hardcoded location. Its practices in doing so are downright negligent.
Because of all of this, I decided to reimplement the compiler server using arduino-cli to support custom boards, libraries, and the like. It completely replicates the behavior of the Chromeduino server (meaning no changes are required of Barnabas Blocks in terms of changing how it sends C code and receives code back from a server). The result is currently under testing and will evolve as its use case evolves.
The project is licensed under GPL3+ and its code is viewable here.
Attached is a demonstration I made of compiling a short Arduino program which waits until a button on pin 2 is pressed and prints "press!" to serial.
So I was easily able to set up the arduino IDE, however I've come across a problem with the ezDisplay set up. While doing the instructions listed in the SETTINGUP.md in Step 2 I tried to install the latest version and got the following error:
Which I am a bit confused by, I tried using the version that he used in his instructions, aka version 1.4.1 and received another error. I'm not entirely sure what's going on but I am unable to see the exact same image as seen in step 3 of the SETTINGUP.md. For comparison, these are the images versus what I see:
However, the code appears to be mostly working. The issue now is the maximum bytes:
It seems Dante will be working on this issue but as for now I'm a bit stumped. It seems that the program in the end is running fine however and with the converter I'm sure we'll see further how this will work out.
I don't know if "fixed" is the right word here, but I deleted a superfluous code snippet from blocks_compressed.js which, at least on face value, fixed the issue. Code up on my git.
We've ironed out the kinks in how the project is to be developed. We have new additions should follow a specific process for adding blocks instead of being placed in random files. I've updated the README accordingly which can be viewed here (once GitHub is online and I can actually push it):
Hi all, sorry for the bad quality photo (currently at work in the car). But I thought I should post something for the week.
Since I do not have internet on the laptop, I have lightly written some notes for the README page and a few realizations from generator files while thinking about how we could clean up the generators/arduino directory.
However, I am still not entirely sure whether all of the generators js files are necessary, as I do not have access to the internet and cannot run the code. I also do not know if the README is thorough enough; I just took bits and pieces from the old README and the notes we took from the past week to maintain consistency within the writing styles. (Or were we doing a complete overhaul? Haha)
Hopefully I can get a better look into this as soon as I get home tonight!
Besides deleting(or re-locating) a whole bunch of unused .js files, the only real thing it seems we have to do is consolidate blocks/custom/arduino.js and blocks_compressed.js. When someone wishes to create a new block, it then simplifies things a whole bunch by them really only having to add onto adruino.js file for the block and then add a generator function for the other arduino.js file in generators. I think this is the right way to go about this, but please correct me if I'm missing something or if I misunderstood the assignment.
Running into a small bug presently with the consolidating (colors) attached below, but so far, everything else seems to be fine and compiling. I will take a look to address the bug later and also continue on getting to know ArduinoIDE for the purpose of our greater project.
I've implemented the pulseIn function, which waits for a certain pin to rise then fall (or fall then rise):
The generator code already existed but was not compiled, and needed only a few modifications. The block code also already existed but also needed modifications. The code seems a bit disorganized which I will address in another log after some engagements today.
For my function (millis), I decided to state the value under the "Constants" tab because I thought that the function, which returns a set unsigned long value, was sort of a constant that the user could not change. This value can be inserted in a conditional statement to test for whether it should run or not, like so:
This is what the editors tab looked like with my millis function:
For the block itself, I followed Richard's steps of putting all of the necessary code inside the millis.js file. I initially tried to put the millis block in the blocks/customs/arduino.js file, but had struggles with making the files link and work. Thus, putting it altogether made the linking easier.I noticed that for the current state of Barnabas blocks, some blocks were put in the arduino.js file in the blocks/custom directory, while others were declared in the blocks_compressed.js file in the generators. Still others were declared in both files, which threw me off a little bit. So, I just created the millis.js file above and placed it in the generators file, then invoked it in index.html.I also placed the block itself in the constants tab:Hence, this is what I had for the assignment so far. It was definitely a bit of a challenge, figuring out where to put all this information. The 'deconstructed' method of manually putting every part of the block in the compressed files proved difficult; it made more sense for me to make separate files for different block types and invoke them in the index.html file. Perhaps the overall project could be a lot more organized and easily understandable for users if we were to structure it this way. Again, I'm still new to html and js, so there may be things I do not fully comprehend about the functionality of having these multiple files.
Following Ed's instructions, I created a micros.js file that is referenced to from index. This js file is used in conjunction with arduino_compressed.js and blocks_compressed.js. Basically, everything needed for micros() to function is in the micros.js file.
A couple questions did come up while putting the code together(and I emphasize "putting it together" because there wasn't much I did except analyze the code for what's necessary), 1) Why can't I seem to consolidate the two over-arching UMDs?(New term I learned while googling! the function(root, factory)). If anybody can shed some light on that, that'd be awesome.
Also, should I change the block's location, what other changes would I need to make to code?
Heading to Norcal soon! Have a great weekend everyone :)
Edward Li
However, the code appears to be mostly working. The issue now is the maximum bytes:
It seems Dante will be working on this issue but as for now I'm a bit stumped. It seems that the program in the end is running fine however and with the converter I'm sure we'll see further how this will work out.
This is what the editors tab looked like with my millis function:
I noticed that for the current state of Barnabas blocks, some blocks were put in the arduino.js file in the blocks/custom directory, while others were declared in the blocks_compressed.js file in the generators. Still others were declared in both files, which threw me off a little bit. So, I just created the millis.js file above and placed it in the generators file, then invoked it in index.html.
I also placed the block itself in the constants tab:
Hence, this is what I had for the assignment so far. It was definitely a bit of a challenge, figuring out where to put all this information. The 'deconstructed' method of manually putting every part of the block in the compressed files proved difficult; it made more sense for me to make separate files for different block types and invoke them in the index.html file. Perhaps the overall project could be a lot more organized and easily understandable for users if we were to structure it this way. Again, I'm still new to html and js, so there may be things I do not fully comprehend about the functionality of having these multiple files.