Posts with «arm» label

Robot from book Computer Controlled Robots for C64, VIC20, Spectrum and BBC

Primary image

What does it do?

Drive around, and picks up objects

This robot is from the book "Computer Controlled Robots for C64, VIC20, Spectrum and BBC", which can be downloaded, along with other books of a similar vintage, from the publisher's website: https://usborne.com/browse-books/features/computer-and-coding-books/

I used to borrow the book from the library as a child, but never actually got to build the robot from the book. Recently, after finding the book online for free, I decided to finally build the robot for myself.

Cost to build

Embedded video

Finished project

Number

Time to build

Type

wheels

URL to more information

Weight

read more

Who Owns Arduino?

Who owns Arduino? We don’t mean metaphorically — we’d say that’s the community of users and developers who’ve all contributed to this amazing hardware/software ecosystem. We mean literally. Whose chips are on the table? Whose money talks? It looks like it could be ARM!

The Arduino vs Arduino saga “ended” just under a year ago with an out-of-court settlement that created a private holding company part-owned by both parties in the prior dispute over the trademark. And then, [Banzi] and the original founders bought out [Musto]’s shares and took over. That much is known fact.

The murky thing about privately held companies and out-of-court settlements is that all of the details remain private, so we can only guess from outside. We can speculate, however, that buying out half of the Arduino AG wasn’t cheap, and that even pooling all of their resources together, the original founders just didn’t have the scratch to buy [Musto] out. Or as the Arduino website puts it, “In order to make [t]his a reality, we needed a partner that would provide us with the resources to regain full ownership of Arduino as a company… and Arm graciously agreed to support us to complete the operation.” That, and the rest of the Arduino blog post, sure looks like ARM provided some funds to buy back Arduino.

We reached out to [Massimo Banzi] for clarification and he replied:

“Hi arm did not buy nor invest in arduino. The founders + Fabio Violante still own the company. As I wrote in the blog post we are still independent, open source and cross platform.”

We frankly can’t make sense of these conflicting statements, at least regarding whether ARM did or didn’t contribute monetary resources to the deal. ARM has no press release on the deal as we write this.

Announcing a partnership without details isn’t a new activity for Arduino. Recently we wrote about open questions on the Arduino Foundation. [Banzi] was willing to speak with Hackaday at length about that topic, suggesting more details were just weeks away but we have yet to see follow-through on that.

What we can tell is that [Banzi] and Arduino want us to know that they’re still independent. The Arduino post mentions independence and autonomy eight times in a 428-word post. (The lady doth protest too much?) They’re very concerned that we don’t think that they’ve been snapped up by ARM.

And there’s also good reason to believe that Arduino will remain autonomous even if ARM owns a big stake. ARM sells its intellectual property to a number of silicon manufacturers, who then compete fiercely by offering different peripheral sets and power budgets, and they’re very serious about providing them all with a level playing field.

Anyway, the various ARM chips are nice to work with from a hacker perspective. If the AVR-based UNO was the last non-ARM Arduino board ever made, we’d only shed a tiny little tear. On the other hand, if you’re an MSP430 or PIC fanboy or fangirl, we wouldn’t be holding your breath for a light-blue board sporting your favorite silicon but that is just conjecture.

So we have seemingly conflicting information on the details of this deal, but also promises of openness and transparency. On one hand we’re pleased that ARM is the apparent silent partner, but on the other hand we’re left confused and wanting more. Who owns Arduino?


Filed under: Arduino Hacks, Business, Current Events, Featured, news

Arduino announces Arm partnership

Dear Arduino Community,

Back in July, we announced that the original Arduino founders regained full control of Arduino as a company. It was the culmination of a project that lasted several months, which required a tremendous amount of effort in finding the right partner that could help us make it happen while keeping the spirit of Arduino true to itself.

Throughout the litigation we dreamed of reclaiming control of the company, bringing it back to its original principles while designing a strategy that would allow us to tackle the challenges of the contemporary IoT world.

In order to make his a reality, we needed a partner that would provide us with the resources to regain full ownership of Arduino as a company while keeping it independent and true to its values of openness.

It wasn’t easy, but more than a year ago, in the middle of the litigation, we started a conversation with an important technology company that is an essential building block of today’s digital world: Arm.

During a very hot day in spring I visited California to meet with Arm. It was a great meeting of minds and we determined that such a partnership was the right fit for us. Arm is an extremely innovative company whose processors can be found inside virtually every mobile device on the planet; but they don’t actually build silicon. Instead, they have created an ecosystem of a thousand-plus partners, some of whom compete with each other, but Arm works in harmony with all of them.

Arm recognized independence as a core value of Arduino. This was very important for us, as it meant full understanding of our need to work with multiple silicon vendors and architectures as long as they make sense for Arduino—without any lock-in with the Arm architecture.

Following the meeting with Arm, I was thrilled. I shared my excitement with our new CEO Fabio Violante and my cofounders: Arduino could again be 100% ours, with the help of a supportive partner that leaves complete autonomy to our team and our community.

We worked very hard for many months to make this happen, and Arm graciously agreed to support us to complete the operation.

What should you expect from us in the future? A stronger Arduino, free to innovate with more firepower, and plenty of enthusiasm for future challenges and opportunities.

We will continue to work with all technology vendors and architectures moving forward. We stay independent; we stay open, and we still provide the most loved microcontroller development platform that has changed the lives of so many people around the world.

A BluePill for Arduino Dependence

Arduinos are helpful but some applications require more than what Arduinos can provide. However, it’s not always easy to make the switch from a developed ecosystem into the abyss that is hardware engineering. [Vadim] noticed this, which prompted him to write a guide to shepherd people on their quest for an Arduino-free environment, one BluePill at a time.

With an extended metaphor comparing Arduino use and physical addiction, [Vadim’s] writing is a joy to read. He chose to focus on the BluePill (aka the next Arduino Killer™) which is a $1.75 ARM board with the form factor of an Arduino Nano. After describing where to get the board and it’s an accompanying programmer, [Vadim] introduces PlatformIO, an alternative to the Arduino IDE. But wait! Before the Arduino die-hards leave, take note that PlatformIO can use all of the “Arduino Language,” so your digitalWrites and analogReads are safe (for now). Like any getting started guide, [Vadim] includes the obligatory blinking an LED program. And, in the end, [Vadim] sets his readers up to be comfortable in the middle ground between Arduino Land and the Wild West.

The debate for/against Arduino has been simmering for quite some time, but most agree that Arduino is a good place to start: it’s simpler and easier than jumping head first. However, at some point, many want to remove their “crippling Arduino dependency” (in the words of [Vadim]) and move on to bigger and better things. If you’re at this point, or still cling to your Uno, swing on over and give Vadim’s post a read. If you’re already in the trenches, head on over and read our posts about the BluePill and PlatformIO which are great complements for [Vadim’s].


Filed under: hardware, news
Hack a Day 02 Sep 12:00

Secret Serial Port for Arduino/ESP32

If you use the Arduino IDE to program the ESP32, you might be interested in [Andreas Spiess’] latest video (see below). In it, he shows an example of using all three ESP32 UARTs from an Arduino program. He calls the third port “secret” although that’s really a misnomer. However, it does require a quick patch to the Arduino library to make it work.

Just gaining access to the additional UARTs isn’t hard. You simply use one of the additional serial port objects available. However, enabling UART 1 causes the ESP32 to crash! The reason is that by default, UART 1 uses the same pins as the ESP32 flash memory.

Luckily, the chip has a matrix switch that can put nearly any logical I/O pin on any physical I/O pin. [Andreas] shows how to modify the code, so that UART 1 maps to unused pins, which makes everything work. it is a simple change, replacing two parameters to a call that — among other things — maps the I/O pins. You could use the technique to relocate the UARTs to other places if you choose.

If you want to learn more about the ESP32, we covered a good set of tutorials for you to check out. Or if you just want a quick overview, you can start here.


Filed under: Arduino Hacks, ARM
Hack a Day 17 Aug 16:30

Another Arduino Compatible? This Time, It’s A Sony

When it comes to microcontroller development boards, we have a plethora of choices at our disposal. Each has its strengths and weaknesses, be they associated with its support and community, its interface capabilities, or its choice of processor family. Most boards you’ll find in our communities come from niche manufacturers, or at least from manufacturers who started as such. Just occasionally though along comes one whose manufacturer you will have heard of, ever whose manufacturer the Man in the Street will have heard of.

Which brings us neatly to today’s story, the quiet announcement from Sony, of a new microcontroller development board called the Spritzer. This is Arduino compatible in both physical footprint and IDE, is intended for IoT applications, and packs GPS, an audio codec, and an ARM Cortex M4 at 156 MHz. There is a Japanese page with a little more detail (Google Translate link), on which they talk about applications including audio beam forming with up to eight microphones, and a camera interface. 

The board is due to be available sometime early next year, and while it looks as though it will be an interesting device we’d sound a note of caution to Sony. It is not good enough to have an amazing piece of hardware; the software and community support must be more than just make-believe. If they can crack that then they might just have a winner on their hands, if they fail to make any effort then they will inevitably follow Intel into the graveyard of also-ran boards.

Thanks [Chris] for the tip.


Filed under: hardware
Hack a Day 13 Aug 15:00

A Concept for a Robot that I am planning to build

PlatformIO and Visual Studio Take over the World

In a recent post, I talked about using the “Blue Pill” STM32 module with the Arduino IDE. I’m not a big fan of the Arduino IDE, but I will admit it is simple to use which makes it good for simple things.

I’m not a big fan of integrated development environments (IDE), in general. I’ve used plenty of them, especially when they are tightly tied to the tool I’m trying to use at the time. But when I’m not doing anything special, I tend to just write my code in emacs. Thinking about it, I suppose I really don’t mind an IDE if it has tools that actually help me. But if it is just a text editor and launches a few commands, I can do that from emacs or another editor of my choice. The chances that your favorite IDE is going to have as much editing capability and customization as emacs are close to zero. Even if you don’t like emacs, why learn another editor if there isn’t a clear benefit in doing so?

There are ways, of course, to use other tools with the Arduino and other frameworks and I decided to start looking at them. After all, how hard can it be to build Arduino code? If you want to jump straight to the punch line, you can check out the video, below.

Turns Out…

It turns out, the Arduino IDE does a lot more than providing a bare-bones editor and launching a few command line tools. It also manages a very convoluted build process. The build process joins a lot of your files together, adds headers based on what it thinks you are doing, and generally compiles one big file, unless you’ve expressly included .cpp or .c files in your build.

That means just copying your normal Arduino code (I hate to say sketch) doesn’t give you anything you can build with a normal compiler. While there are plenty of makefile-based solutions, there’s also a tool called PlatformIO that purports to be a general-purpose solution for building on lots of embedded platforms, including Arduino.

About PlatformIO

Although PlatformIO claims to be an IDE, it really is a plugin for the open source Atom editor. However, it also has plugins for a lot of other IDEs. Interestingly enough, it even supports emacs. I know not everyone appreciates emacs, so I decided to investigate some of the other options. I’m not talking about VIM, either.

I wound up experimenting with two IDEs: Atom and Microsoft Visual Studio Code. Since PlatformIO has their 2.0 version in preview, I decided to try it. You might be surprised that I’m using Microsoft’s Code tool. Surprisingly, it runs on Linux and supports many things through plugins, including an Arduino module and, of course, PlatformIO. It is even available as source under an MIT license. The two editors actually look a lot alike, as you can see.

PlatformIO supports a staggering number of boards ranging from Arduino to ESP82666 to mBed boards to Raspberry Pi. It also supports different frameworks and IDEs. If you are like me and just like to be at the command line, you can use PlatformIO Core which is command line-driven.

In fact, that’s one of the things you first notice about PlatformIO is that it can’t decide if it is a GUI tool or a command line tool. I suspect some of that is in the IDE choice, too. For example, with Code, you have to run the projection initialization tool in a shell prompt. Granted, you can open a shell inside Code, but it is still a command line. Even on the PlatformIO IDE (actually, Atom), changing the Blue Pill framework from Arduino to mBed requires opening an INI file and changing it. Setting the upload path for an FRDM-KL46 required the same sort of change.

Is it Easy?

Don’t get me wrong. I personally don’t mind editing a file or issuing a command from a prompt. However, it seems like this kind of tool will mostly appeal to someone who does. I like that the command line tools exist. But it does make it seem odd when some changes are done in a GUI and some are done from the command line.

That’s fixable, of course. However, I do have another complaint that I feel bad for voicing because I don’t have a better solution. PlatformIO does too much. In theory, that’s the strength of it. I can write my code and not care how the mBed libraries or written or the Arduino tools munge my source code. I don’t even have to set up a tool chain because PlatformIO downloads everything I need the first time I use it.

When that works it is really great. The problem is when it doesn’t. For example, on the older version of PlatformIO, I had trouble getting the mBed libraries to build for a different target. I dug around and found the issue but it wasn’t easy. Had I built the toolchain and been in control of the process, I would have known better how to troubleshoot.

In the end, too, you will have to troubleshoot. PlatformIO aims at moving targets. Every time the Arduino IDE or the mBed frameworks or anything else changes, there is a good chance it will break something. When it does, you are going to have to work to fix it until the developers fix it for you. If you can do that, it is a cost in time. But I suspect the people who will be most interested in PlatformIO will be least able to fix it when it breaks.

Bottom Line

If you want to experiment with a different way of building programs — and more importantly, a single way to create and build — you should give PlatformIO a spin. When it works, it works well. Here are a few links to get you started:

Bottom line, when it works, it works great. When it doesn’t it is painful. Should you use it? It is handy, there’s no doubt about that. The integration with Code is pretty minimal. The Atom integration — while not perfect — is much more seamless. However, if you learn to use the command line tools, it almost doesn’t matter. Use whatever editor you like, and I do like that. If you do use it, just hope it doesn’t break and maybe have a backup plan if it does.


Filed under: Arduino Hacks, ARM, Hackaday Columns, reviews, Skills

The $2 32-Bit Arduino (with Debugging)

I have a bit of a love/hate relationship with the Arduino. But if I had two serious gripes about the original offering it was the 8-bit CPU and the lack of proper debugging support. Now there’s plenty of 32-bit support in the Arduino IDE, so that takes care of the first big issue. Taking care of having a real debugger, though, is a bit trickier. I recently set out to use one of the cheap “blue pill” STM32 ARM boards. These are available for just a few bucks from the usual Chinese sources. I picked mine up for about $6 because I wanted it in a week instead of a month. That’s still pretty inexpensive. The chip has a lot of great debugging features. Can we unlock them? You can, if you have the right approach.

The Part

For a few bucks, you can’t complain about the hardware. The STM32F103C8T6 onboard is a Cortex-M3 processor that runs at 72 MHz. There’s 64K of flash and 20K of RAM. There’s a mini-USB that can act as a programming port (but not at first). There’s also many 5 V-tolerant pins, even though this a 3.3 V part.

You can find a lot more information on this wiki. The board is a clone–more or less–of a Maple Mini. In fact, that’s one way you can use these. You can use the serial or ST-Link port to program the Maple bootloader (all open source) and use it like a Maple. That is, you can program it via the USB cable.

From my point of view, though, I don’t want to try to debugging over the serial port and if I have the ST-Link port already set up, I don’t care about a bootloader. You can get hardware that acts as a USB to ST-Link device inexpensively, but I happen to have an STM32VLDISCOVER board hanging around. Most of the STM32 demo boards have an ST-Link programmer onboard that is made to use without the original target hardware. On some of the older boards, you had to cut traces, but most of the new ones just have two jumpers you remove when you want to use the programmer to drive another device.

The “blue pill” designation is just a common nickname referring to the Matrix, not the pharmaceuticals you see on TV ads. The board has four pins at one edge to accommodate the ST-Link interface. The pin ordering didn’t match up with the four pins on the STM32VLDISCOVER, so you can’t just use a straight four-pin cable. You also need to bring power over to the board since it will have to power the programmer, too. I took the power from the STM32VLDISCOVER board (which is getting its power from USB) and jumpered it to my breadboard since that was handy.

The Plan

Programming the board is easy — I knew the community had done a lot of work to create a support package for it. You do need a recent version of the Arduino IDE (not the one that shows up in the default Ubuntu repositories). I downloaded version 1.8.1 from the Arduino website, just to be sure. That was the first step of my general plan of attack:

  1. Load the latest Arduino IDE
  2. Set the compile messages to verbose
  3. Use the Board Manager to install the STM32 F1 packages
  4. Get more tools
  5. Capture the build directory
  6. Run the right version of GDB

The recent versions of the Arduino IDE let you select platforms by using the Board Manager (available from the Tools | Board menu). However, if you look, you won’t see this board on the list. You’ll need to tell the IDE where to get the third-party support package. To do that, you can go to the Preferences menu item (on the File menu for Windows and Linux; I understand it is on the Arduino menu on the Mac). You need this same preferences dialog for step two, also.

Step 2 isn’t strictly necessary, but it will make step 5 easier. Just check “Show verbose output during compilation.” What you really need to know is the temporary directory the IDE uses for your build and this is the easiest way to do that, as you’ll see.

Further down the preferences screen is an entry for “Additional Boards Manager URLs.” If there’s already something there you should click the little button to edit the list. If it is empty, you can add this URL:

https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json

Now you can go back to the Tools | Board menu, pick Board Manager, and search for STM. You’ll probably see a few packages (I had three) but the one for the F1 will specifically mention the blue pill. Click the button to install and wait for it to do its thing.

Once installed, you’ll have some new entries on your board menu. When you have the blue pill selected, you’ll be able to pick a few options for uploading including the one we want: ST-Link.

Coding

The package has all the stuff you need to build and download programs using a variety of methods, including ST-Link. However, it doesn’t have the particular tool you need to do debugging.

It is simple enough to build the tools. The GitHub repo has the code and some simple build instructions. You do need libusb and CMake, but the page explains all that and once you have all the pieces, the build goes fast. For many OS choices, there are pre-built binaries you can use, too.

You’ll also need to know the USB ID of your ST-Link board and add it to the udev rules for Linux. If you don’t do this, you’ll need to be root to program the device and that’s not a good idea. However, depending on which ST-Link interface you use, it may already be there from other software or from the Arduino install. I’d try a test first and if it only works as root, you’ll need to update udev.

If you did your own build, I suggest running the tool stlink-gui to perform the test. You can also run st-info --descr

If you run stlink-gui, press the connect button with the ST-Link and blue pill powered up and connected. You should get the information about the device. If not, try as root. If that works, you need to update udev. I created a file, /etc/udev/rules.d/45-stlink.rules.

ACTION=="add" SUBSYSTEM=="usb", ATTR(idVendor)=="0483", 
     ATTR(idproduct)=="3744", MODE="0666", GROUP="usbusers"

You’ll need to modify that for the USB ID of your particular interface (mine was 0483:3744; the lsusb command can help). The mode allows all users to read and write the device. I made the group owner usbusers, but since everyone can access the device that probably isn’t strictly necessary.

Once you can do all that, try running the blink sketch from the IDE examples. Be sure to pick “Upload Method: STLink” from the Tools menu of the Arduino IDE. If it doesn’t work, you may need to use the tools you just built instead of the ones that come with the Arduino IDE. Mine worked but the debugging required the custom build (because the Arduino package didn’t ship with that particular tool built).

Finding the Tools and Build Directory

The Arduino IDE is pretty friendly, so it doesn’t try to install things like boards for all users, since that would require root. The board package you loaded winds up in your home directory under ~/.arduino15/packages/STM32/tools. There’s an STM32Tools directory and a few more levels down you’ll find copies of the ST-Link tools. If they don’t work, you can manually run the tools you built in the previous step to do your uploads. When we debug, we are going to do that anyway.

What’s really important though is back under the STM32/tools directory is another directory with the compiler that the IDE uses to compile your code. There’s also a matching version of GDB — the GNU Debugger — there that you will have to use.

If you loaded an example, make sure you save it to your own directory (I hate saying sketchbook). If you don’t, the IDE will make a private copy of any changes you make and things will get confusing.

Do a build (the checkmark icon) and — assuming you checked the box in step 2 — you’ll get a lot of output from the build tools. You might verify that the compiler in use is the one we mentioned above. You’ll also see that your program gets added to other things and put in a directory named something like /tmp/arduino_build_XXXXXX where the XXXXXX is a number. Your source code will be in this directory named something like sketch/Blink.ino. In the top-level directory will be the executable Blink.ino.elf. This is what you need to debug.

If you are comfortable editing your Arduino settings file (just be sure the IDE isn’t running first) you can also force a build directory using the build.path key. The IDE does have an “export binary” command (on the Sketch menu) that compiles to your sketch folder. However, this .bin file doesn’t have enough information for the debugger.

Debugging at Last

Finally, you can debug. Use the arm-none-eabi-gdb executable from the same directory as the GCC used to compile your program. This is important. If the versions don’t match you’ll get strange errors even though many things will seem to work. Provide the name of the elf file as an argument to GDB.

If you like, you can use the -tui flag to GDB to get a sort of text-based GUI. Either way, you have one more step to go. The st-util tool you built earlier can listen to the ST-Link interface and provides a socket that GDB can use to do debugging.

Start it like this:

st-util -p 1234

That will make it listen on port 1234. If you already use that port for something else, pick another one. Just remember that on Linux only root can listen on ports below 1024, so pick a bigger number.

Once that is running, you fire up GDB with your elf file name and issue the command:

target extended-remote :1234

Or, I’ve recently started using:

target remote :1234

You can run the two parts on different computers, so use a hostname if necessary (that is, devbox21:1234). Most times, the programs are on the same box and you can use localhost or omit it like I did. The difference between remote and extended-remote is that the server does not shut itself down at the end of an extended-remote session. It often works, but I have seen cases where I had to restart the server anyway, so lately I’ve been using plain-old remote to force me to restart it with each session.

A “load” command to GDB will now flash your program to the board. A typical session after a load might be:

break main
continue
list
n
n
n

The “n” command steps to the next instruction.You can find a lot more about using GDB in an earlier post. You also might find it easier to watch the walkthrough in this video:

A few caveats. First, optimization can cause your lines to execute out of order, or even go backwards. It can also cause variables to not be visible where they have been optimized out. The other thing to watch out for is that, in some cases, the debugger internally single steps. This can cause very slow execution of delay routines, for instance. You might reduce or remove delays while debugging or be careful where you try to single step instead of placing breakpoints.

Final Thoughts

It would be neat if the Arduino IDE let you debug inside of it. However, there are ways to do that using Eclipse (and GDB) or Visual Studio (if you use Windows). If you are like me and OK with the command line, you might think about using one of the Makefiles for Arduino instead of the IDE. If you aren’t OK with the command line, there are GUI shells for GDB that you could try. If you’d rather hack the ST-Link firmware, we’ve seen that done, too. If you miss doing printf’s, you might want to try a Black Magic probe, which ought to work about the same as the ST-Link interface, but also provides a serial port for printf and other mischief.

By the way, Arduino isn’t the only choice for this board. It is possible to use mBed and other development tools with them. But that’s a topic for a future post.


Filed under: Arduino Hacks, ARM
Hack a Day 30 Mar 18:01

Tertiarm - low cost, 3d printed robot arm based on Ikea lamp

Primary image

What does it do?

Move things, push buttons, etc.

Cost to build

Embedded video

Finished project

Complete

Number

Time to build

Type

URL to more information

Weight

read more

Let's Make Robots 07 Feb 15:54