I believe I finally have the Synthetos TinyG v6 working reliably under minicom. To upload Gcode files to TinyG, I found it best to disable the Local Echo ($ee=0), disable the Status Verbosity ($sv=0), disable the Text Verbosity ($tv=0), and finally set the baudrate to 38400 ($baud=3).
The goal of disabling these three options is to minimize "cruft" that is pushed into the TinyG's output buffers. I suspect (but have not confirmed in the firmware code yet) the TinyG will APPEND the XOFF control code to its output buffer, instead of PREPENDING it in front of anything else waiting in the output buffer.
I finally have the Digispark and the RadioBlock devices in stock, and I am now refactoring the slave-controller (Arduino) portion of the "Android-Controlled Arduino" circuit to just the Digispark and the supporting components. More details on that soon.
For now, though, here are my notes on adding Digispark support to Fedora 18. As you know, Fedora has a lot of great tools maintained in their repositories, and that includes the Arduino development environment. Simply do a yum install arduino as root to get the basic tools necessary for Arduino development. Read on for the rest of this recipe...
After a few weeks of procrastination, I finally got around to tapping the rails for the Shapeoko CNC kit. Overall, I like this little kit - pretty easy to assemble with just bolts (with the exception of needing to tap the aluminum extrusions on your own).
All that's left is to install some Home and Limit switches, wire them up along with the Motors to one of the CNC controllers I have lying around. Beyond that, I'll take it for a test run, carving into scrap material until it's finally dialed in.
With any luck, I'll be able to use this for Surface-Mount PCB fabrication and improve the turn-around times on fabricating my own boards.
This article examines the Arduino's role in the overall project. As with most Arduino circuits -- especially those designed on breadboards -- this is a throw-away mock-up of what will ultimately be used in the final circuit. For our purposes of exchanging both commands and sensor readings via JSON messages, an Arduino hooked up to a few simple circuits will work just fine.
Knowing that this portion is a throw-away mock, however, there's little need to spend a lot of time designing the final circuitry just yet. Instead, a handful of established, "tried and true" circuits are dropped onto the breadboard. Furthermore, a few programming conveniences are added to the Arduino Sketch source code to yield a useful mock-up circuit as quickly and as painlessly as possible.
Being the Fedora Linux Badass that I am, though, I have no intention of waiting for the Raspberry Pi Fedora Remix team to produce their next build. Instead, I've downloaded the Fedora ARM binaries, and cobbled together a homebrew solution to shoehorn (err "bootstrap") the Fedora 18 ARM RC2 binaries for use on the Raspberry Pi.
Here, then, are my technical notes that you can follow along with to get Fedora ARM 18 running on your own Raspberry Pi.
So, you love your high-tech gadgets, have the usual toys like an Arduino and a Raspberry Pi, and are tired of seeing that equipment just sitting on your shelf, collecting dust?! Well, this is the Blog for you! Whether you're into the Hardware side or Software side (or both, like me), I hope the articles presented here help to inspire your Inner Geek. Ready to go? Great! Dust off those toys, grab your components kit, and feel free to follow along!
Note: This is one of my longer-term hobby projects, with the end-goal being an automated, web-accessible, solar-powered Aquaponics Pump Controller and Data Acquisition Monitoring System. As such, there are multiple pieces assembled together to make this all work, and some design decisions may appear to be overkill without this end-goal in mind. I am starting this out with a simple Arduino, and will likely migrate over to something more suitable for embedded use, such as a Teensy 3.0, or a DigiSpark.
Each part of this project will (likely) have its own dedicated deep-dive article. Feel free to ask questions along the way if you're following along.
This post is the project design overview. More detailed articles about each of the underlying components (with source code examples) will be published as time permits.
The Arduino Stuff
For this part of the project, we are going to construct an Arduino circuit and an Arduino sketch that reads JSON messages over the Serial Port, and takes action based on the commands received via JSON. Why JSON? Quite frankly, because I'm so damn tired of seeing all these trivial examples floating around the 'Net that just read a single byte.
OK. That, and the fact that JSON is so prevalent when it comes to building simple Web Services. You read right, we're setting this up as a JSON Web Service, and the project is designed for Internet accessibility if you so choose.
As an Open-Source Geek and a Fedora Linux enthusiast, I have been looking forward to finally retiring my nearly-year-old Fedora 16 installation in favor of a fresh new Fedora 18 Beta installation. I'm already in Holiday Shutdown mode in my consulting business and won't have another opportunity to blow away and rebuild my trusty laptop until November of next year.
To my dismay, Fedora 18 is configured to exclusively run on Linux Kernel 3.6 -- which has recently become a problem for me on Fedora 16, as there's a suspend/resume glitch with the NVidia (nouveau) driver that corrupts the screen once resumed. Ironically enough, everything else works perfectly, and you can use Alt-F2 and siblings to get a perfectly usable Text Console. But that's a tangent for another discussion.
Here, then, I have the choice of either living without Suspend/Resume on Fedora 18 until the resolution is corrected upstream; or I can take a shot at compiling a 3.4 Kernel and hope that will run Fedora 18 as well as resolve the suspend/resume isue. My steps are as follows:
Copy the working kernel configuration from Fedora 16. On my original Fedora 16 machine, this file lives in /boot as /boot/config-3.4.11-1.fc16.x86_64
Download the latest Linux Kernel source from kernel.org. At this writing, it's Kernel 3.4.24 - but you're better off examining the Kernel.org homepage to see if a newer version is available to you.
Unpack the Kernel Sources, and navigate into the source directory tree. Copy the kernel configuration file from Fedora 16 (above) as .config in this directory. We'll use it as the baseline for the new Kernel 3.4 configuration.
do a make oldconfig . This will pull in the settings from .config, and prompt you for an answer for any differences that need a response. Fortunately for me, there were no prompts. Had there been any, I'd probably just accept the default answer that is suggested by the prompt.
Compile it by doing a make -j4 rpm. Compiling it as an RPM as done here allows us to rpm install it later on; and once the upstream kernels are working properly, we can yum uninstall it without leaving remnants of your kernel files behind.
At the end of all this compilation stuff, you should now have a pair of rpm files in ~/rpmbuild/RPMS/x86_64 (or i386 if you're on an ancient machine) - the Kernel binaries themselves, and the Kernel header files for kernel module development. Navigate there, and do an rpm install *rpm --force as root. This essentially copies your kernel binaries and headers into the correct locations -- but you're not done yet!
Navigate back to your source tree and do a dracut "" `make kernelrelease` . This will create an initramfs (initial ramdisk filesystem) that corresponds to your newly compiled kernel. The kernel and initramfs go hand in hand.
And now finally, do a grub2-mkconfig -o /boot/grub2/grub.cfg . This will scan your /boot area for kernels and ramdisks, and auto-generate a new grub2 configuration file.
OK, the hard part is now over. Reboot, and select "Advanced Options".. then select the menu option to boot with your custom Kernel 3.4 -- which is probably at the bottom of the list. If everything fires up as expected, celebrate and enjoy your new machine running on a 3.4 Kernel. The NVidia Suspend/Resume issue shouldn't plague you anymore, and you can be productive once more until the proper fix comes along from upstream. Woot!
If you haven't already done so, check out my YouTube Video. of the shoddy, broken equipment that some Chinese scammers on Alibaba and AliExpress would send.
This blog serves as a reminder to be cautious of certain Sellers on Alibaba.com or its affiliate, AliExpress.com. The "escrow" protection does not do you any good, and these sellers are good at stalling and gaming the system until you reach the point where it's too late to do a credit card Chargeback (60 days from day of charge transaction).
How the scheme works: They burn up to 30 days in sending your order out; up to another 7 days in transit; then you have 3 weeks to review what you actually received. At the point where you receive the item, the AliExpress escrow "graciously" allows up to 20 days for you to send the item back to the seller, where they say whether or not they received the returned item in good condition or not. At the end of the process, if you went through the AliExpress Escrow process, you've burned through the 60 days of the credit card chargeback process, and then you're vulnerable to having your returned "denied" by these scammers -- leaving you out your original purchase price plus the cost of shipping the item back.
Fortunately, the unit I received was obviously Defective on Arrival, and I am in the process of going through the Refund Process with the Escrow, and a Chargeback from the credit card company as a fallback. We'll see what happens.
Blecch, I keep getting nailed by this whenever I juggle around my external or removable hard-drives that have Fedora Linux loaded on them. These are the "magic three" that convince Linux to recognize LVM-allocated partitions on removable disks. Perform these commands as root:
lvm vgchange -ay
Thanks to the LVM2 FAQ for providing a comprehensive document, but I really only need these commands to be on my way. This is posted mostly for my own convenience and reference, but I'm sure there are others out there who could use the quick answer.
The first two should be enough to activate the partitions, but I added the third so you can see what's actually there. These LVM-allocated partitions should be available as devices under /dev/mapper.