Chip Award Winner
Product of the Year 2012
Chip Award

API Bindings and package management

written by admin, on Jul 25, 2014 2:36:00 PM.

In the past our API Bindings installation and usage guides did assume that a user already knows one of our languages. In the last days we improved the old documentation considerably. It should now be possible to to install the API Bindings and test an example as a novice without having to look it up anything somewhere else.

You can find links to the usage and install guides for each language in our documentation.

One suggestions we got very often in the past was to use packages and package repositories for languages that have this feature. At first we didn’t like the idea since all of our Bindings are automatically generated and uploading a package to a repository adds an otherwise unnecessary manual step to the process of releasing new Bindings.

However, we got so many requests that we decided to add packages to repositories where it is easily possible for us. Currently we support Maven (Java), NPM (JavaScript), CPAN (Perl), PyPI (Python) and GEM (Ruby). This means, that you can install and update the Bindings for each these languages with one simple command line one-liner.

http://download.tinkerforge.com/_stuff/repo_logos.jpg

Java - Maven

Add dependency to your pom.xml

JavaScript - NPM

> npm -g install tinkerforge

Perl - CPAN

> cpanm Tinkerforge

Python - PyPI

> pip install tinkerforge

Ruby - GEM

> gem install tinkerforge

First LiveHacking in Hamburg

written by admin, on Jul 15, 2014 3:08:00 PM.

As we already wrote in the blog, the first LiveHacking in Hamburg took place yesterday:

http://download.tinkerforge.com/_stuff/live_hacking.jpg

It was organized by the Java User Group Hamburg, Sven Ruppert (Codecentric AG) and Alexander Bischof. Bastian was there to attend the event. The participants where invited in the accommodations of the “Hacker- und Makerspace Attraktor e.V” and could realize their ideas with the Tinkerforge building blocks. It was very nice to look over their shoulders and to discuss different ideas and possible improvements with the participants. We already released some of the suggested improvements today.

Sven has also written an article about the event. You can find it here (in German) .

More LiveHackings will take place all over the country. We will support Sven Ruppert on these events. Many thanks for all the positive feedback and the ideas for improvement! We look forward to the next events.

LED Strip Bricklet supports WS2811 and WS2812(B)

written by admin, on Jul 10, 2014 2:33:00 PM.

With the new firmware version 2.0.4 the LED Strip Bricklet now also supports the LED drivers WS2811, WS2812 and WS2812B (sometimes also called “NeoPixel”) additionally to the already supported driver WS2801.

The tested it with different LED strips as well as a 256 Pixel LED matrix from different manufacturers.

http://download.tinkerforge.com/_stuff/ws2812b_led_matrix.jpg

At the Maker Faire we also had a WS2812B strip connected to a RED Brick which was running two days straight without any hickups. The tutorials in the documentation has also been updated accordingly. It now also describes how you can connect the newly supported drivers (the clock line is not used anymore).

LiveHacking with Tinkerforge

written by admin, on Jun 27, 2014 9:57:00 PM.

http://download.tinkerforge.com/_stuff/jug_hamburg.jpg

There will be a whole series of events about “Tinkerforge and IoT” in different cities of Germany and around the World in the coming months. The first event will be on the 7th of July in Hamburg. The series of events is called LiveHacking and will be managed by Sven Ruppert. You can attend for free, a description can be found here (German).

Sven works for the Codecentric AG and does lots of lectures at Java User Groups (JUGs) and he writes for Jaxenter and EclipseMagazin. Currently he is engaged in “Internet of Things”. While searching for appropriate hardware for his events he found the Tinkerforge building blocks, which he will use to familiarize people with Java8 in the context of IoT.

Bastian (from Tinkerforge) will also be present at the event in Hamburg, which is unfortunately already booked out. More LiveHackings are however planned.

RED Brick Software Infrastructure

written by admin, on Jun 20, 2014 3:34:00 PM.

In the past we only wrote about the hardware of the RED Brick. Today we want to discuss the software infrastructure of the RED Brick.

Attention: This article discusses the technical details of the software of the RED Brick. This detailed background knowledge is not necessary to use the RED Brick in its final stage!

The following graphical overview shows the currently planned software infrastructure. This infrastructure will be explained in this blog post.

http://download.tinkerforge.com/_stuff/red_brick.png

Overview

The colors in the graphic have the following meaning:

  • Blue: Tinkerforge software components

  • Green: Tinkerforge hardware in the Stack of the RED Brick

  • Purple: Tinkerforge hardware externally connected

  • Orange: External software components

The stack, as well as Mini USB and USB A, are shown as the interface between the RED Brick and the environment in the graphic.

The Mini USB connection is used to provide a composite USB gadget driver with two USB classes: The first class is a serial port. It can be used to get easy shell access to the RED Brick. The second class is the Brick API. A PC will see a RED Brick that is connected through USB the same way as any other Brick. The RED Brick has an API like other Bricks and Bricklets. With this API the RED Brick can be configured. The configuration consists of the transfer of the user program, configurations for the program execution (programm is started once, every hour, on startup, etc.), as well as other configurations. Thus the RED Brick can be seen as a black box that controls Bricks and Bricklets with high level languages.

Over the stack connectors it is possible to use all Bricks as well as the Ethernet Extension and RS485 Extension with the RED Brick. For the Ethernet Extension we have to write a driver. This driver will show the Ethernet Extension as a normal Ethernet interface in the linux system (eth0).

With the USB A connector you can use any USB devices (mouse, keyboard, WIFI stick) and of course also other Tinkerforge hardware.

All of these connections can be used at the same time. A RED Brick stack that is connected to a PC via Mini USB, uses Bricks and Bricklets, uses more Bricks and Bricklets through the RS485 Extension, is connected to the Internet through the Ethernet Extension and has other devices connected over USB A is possible without problems.

In the following we will introduce the components that are necessary for this system:

Linux distribution

The Linux distribution of the RED Brick is based on Debian. It is already making very good progress. The Linux kernel configurations that are necessary for the components (RAM, power supply) and the interfaces (USB Mini/A, HDMI, SD card, SPI/I2C/UART in the stack, GPIO, LEDs, etc.) are done. All of the Tinkerforge Bindings and the necessary compilers and interpreters are preinstalled in the distribution. Additionally the most important libraries for all of the supported languages are preinstalled, this allows the development of more complex applications.

Further more it possible to create two images:

  • Full image: This image makes all possible functions of the RED Brick available, including the graphics driver for OpenGL and graphical output via HDMI.

  • Fast image: This image is designed for maximum speed. For example the GPU is turned off in this image, which reduces the boot time significantly.

With the full image the RED Brick acts as a PC replacement. With the fast image the RED Brick is more of a substitute for the Master Brick that has an OnDevice API for C/C++, C#, Delphi/Lazarus, Java, JavaScript, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell and Visual Basic .NET.

Status: 100%

SPI stack communication

The communication between Bricks in the stack is done over SPI. The currently used protocol, which is used between Bricks, is made for the SAM3S4 processor that is used by the Bricks. This protocol is very efficient, but it would bring the Linux system on the RED Brick to its knees. The solution for this problem is to use DMA, the processor is not burdened by the communication if DMA is used. The protocol that is currently used is not compatible to DMA. Thus we have to design a new SPI protocol that is compatible to the DMA controller of the SAM3S4 processor as well as the A10S processor that is used on the RED Brick. This protocol then has to be implemented on the RED Brick as well as all of the other Bricks.

Status: 25%

The new protocol is completely laid out and the implementation for the SPI slaves is finished. Currently we are implementing the SPI master driver for the RED Brick. It looks like we will be able to use /dev/spidev, which simplifies the development since it can be done completely in the Brick Daemon. If we get performance problems we can easily transfer the relevant parts directly into the Linux kernel.

RED Brick API Daemon

The RED Brick API Daemon is a daemon that implements the API of the RED Brick. That means it implements the configuration that can be done over Mini USB.

Status: 25%

The most important components of the API are laid out and the necessary infrastructure (communication with Brick Daemon etc) is implemented.

Composite USB Gadget Driver

The composite USB gadget driver makes two interfaces available over Mini USB. Through this driver the RED Brick is seen as a “normal Brick” on the PC. It is however possible to get shell access to the Linux on the RED Brick at the same time.

Status: 100%

The driver is ready and functional.

User Interface

The goal is to be able to configure the RED Brick with the Brick Viewer. The API of the RED Brick only needs to be used by “power users”. The “normal user” can use the Brick Viewer to transfer his program to the RED Brick.

Status: 0%

The implementation of the user interface has not yet started.

Ethernet driver (W5200)

The Ethernet Extension uses the WIZnet W5200 IC for Ethernet communication. There is unfortunately currently no Linux kernel driver available for this IC. But there are drivers available for the very similar W5100 and W5300, which will simplify the implementation of the driver greatly.

Status: 0%

The implementation of the Ethernet driver has not yet started.

RS485 Extension support

Support for the RS485 Extension has currently a low priority. We will start with the implementation after the RED Brick is officially released.

Maker Faire 2014

written by admin, on Jun 12, 2014 4:36:00 PM.

http://download.tinkerforge.com/_stuff/MakerFaireHannover.jpg

Last year the first German Maker Faire in Hanover took place. We were glad to meet some of our customers at the exhibition and had interesting conversation with you guys. Therefore we will be at the Maker Faire this year, too.

Maker Faire takes place from 5th to 6th of July at Hanover Congress Centrum. This time with much more space. You can find more information about it at: http://makerfairehannover.com/.

Of course we will have some RED Bricks with us ;) . We look forward to meet you!

Revised Documentation and Kits

written by admin, on Jun 6, 2014 5:58:00 PM.

Screenshot of Tinkerforge Documentation

Documentation

We have revised the Tinkerforge documentation. A newly created Primer should give an overview over Bricks, Bricklets, Master Extensions and the concepts behind the system of Tinkerforge building blocks.

While doing this we also overhauled each product page. Most likely something has gone wrong somewhere during this process (broken links etc). Please contact us if you find dead or wrong links. Thanks!

Kits

The compilation of modules in the Education and Tinker Kits has been been improved:

The Education Kit is intended to be used in education. We didn’t modify the kit for a long time. The number of Bricklets which can be used directly, without any custom external hardware, has grown. We revised the kit with this in mind. For example we have replaced the IO-16 Bricklet, where buttons and LEDs can be attached, by Bricklets such as the Motion Detector Bricklet or Multi Touch Bricklet. The new Kit permits a bigger number of projects that can be created only by sticking the modules together.

The Tinker Kit is intended to provide the hardware for nearly any imaginable project. This kit also was not revised for a long time, such that the question came up which new modules should be put in the kit and which to remove. We have decided to put everything in the kit. In this kit each Tinkerforge module is now included at least once. Exactly the right kit for those who need a collection of parts and do not know what future projects will bring.

RED Brick

Things are going well with the RED Brick. Next week we will give you more information about the current status.

RED Brick: Does it work?

written by admin, on May 23, 2014 1:49:00 PM.

RED Brick prototype

In our last blog entry we wrote about the first prototypes of the RED Brick. We found an error in the hardware design. One of the processor pins was mistakenly connected to ground. To sever the connection we used a drill bit that was a bit too large, nevertheless we were able to bring one of the RED Bricks to life. One week has passed and we have already gone big steps forward.

With the 0.3mm drill bits that arrived last week we were able to repair more RED Bricks. We used a professional xy-stage to position the drill bit correctly, but it was still a big challenge. For some of the Bricks we did damage traces of the 6-layer circuit board that are in proximity to the drill hole. In sum we now have six working RED Bricks.

U-Boot/Linux Image

Most of our work until now went into U-Boot (bootloader) and the Linux image of the RED Brick. Some of the tasks have been to create a toolchain, write build scripts, implement hardware modifications (LEDs, DDR, interfaces), configure the image (language, hostname, etc) and similar. It is particularly time consuming to optimize boot time. We removed lots of daemons, drivers and similar that are not sensible on the RED Brick. The current boot time including graphical user interface is 45 seconds. We will still optimize that. Additionally to the full image with graphical user interface we are also working on a fast stripped down image without graphical user interface. In first tests we were able to reach a boot time of 15 seconds.

HDMI

Since some of the HDMI signals are routed in direct proximity to the via that we had to drill out, HDMI does not work on all of the repaired RED Bricks. It seems we damaged the HDMI traces on those. The RED Bricks that have intact HDMI signals do have a working HDMI output: (Screenshot was taken directly on the RED Brick)

RED Brick Prototyp LXFE Screenshot

USB host

USB host is working too. Currently we are using USB WIFI dongles to connect the RED Brick to our local network.

RAM and heat testing

The connection of the DDR RAM to the processor is quite complex which means that it has to be tested thoroughly. We used the tool stress, which was able to heat up the RED Brick considerably. Stress uses up all of the available processor, RAM and SD card resources. We ran the test for several hours without a heatsink. While the RED Brick got hot, we could not observe any problems. Additionally we used memtester to run different tests on the RAM. These also couldn’t detect any problems. With sysbench and dd we were able to reach the expected performance goals. As far as we can tell there are no problems present with the connection, stability and performance of RAM, processor and SD card at all, they work exactly as expected.

It seems your finger crossing did work out, thanks!

What next?

There is still a huge amount of work that we have to put into the Linux image. We are also working hard to get the kernel drivers ready that are needed for communication between RED Brick and brickv. Over this interface it will be possible to configure the RED Brick and to transfer your own programs to the RED Brick. We will try to keep you informed in future blog posts!

RED Brick news

written by admin, on May 13, 2014 4:32:00 PM.

It has been a while since we announced the RED Brick here in the blog. We are working hard on the new Brick and are very happy to be able to give you a status update:

The circuit board order with clarification of technical details, the delivery time of one month and the long planning and preparation to populate the board had the consequence that we got the first populated prototype only on last Friday.

RED Brick prototype from different angles

We created our own debian image based on Sunxi Linux, which aims to support all Allwiner processors. Unfortunately we were not able to get it running at all with the prototype. So we already had to search for bugs in the very early stages of testing. Fortunately Allwinner processors have an easy method to directly speak with the processor, the FEL Interface. With FEL we were able to determine that the processor was not able to boot from the SD card. After days of searching we were finally able to identify the culprit. The processor has a JTAG interface, which can also be used for debugging. With two pins from the processor it is possible to configure on which pins the JTAG interface is available. Unfortunately the JTAG interface was configured to be active on the SD card interface pins. Because of that it was impossible for us to use an SD card. The processor has several SD card interfaces, which where exchanged during the hardware design phase. It seems that in the end we forgot to adjust the SD card interface accordingly.

The guilty pins are connected to a via directly below the (BGA) processor, so they are not reachable. Thus we tried to utilize one of the other SD card interfaces. Fortunately we have another SD card interface on the general purpuse/camera interface. After a little while of botch wiring we were able to connect them:

RED Brick prototype with botch wires

We were not able to get this SD card interface running. The datasheet of the processor did not help in this regard. We suspect that the processor is not able to boot from this secondary SD card interface at all. Alternatively we had electrical problems or we were not able to configure the image correctly.

Our only other hope was to somehow cut the JTAG configurations pins to get the correct SD card interface working. We already had all of the processors that we ordered populated. To populate new boards with a fixed circuit board would have taken a huge amount of time. Another possible solution would have been to desolder the processor (FBGA), cut the trace to the via, reball the processor and solder it on again. Unfortunately this wasn’t an feasible option because of the small distance between processor and RAM. As a last resort we drilled out the via that connects one of the pins to the ground layer to sever the connection. An internal pull-up of the processors now pulls the pin high.

But how do you drill a via that has an outer diameter of 0.3mm and a drill diameter of 0.15mm?

RED Brick prototype: Drilling

We tried it with this temporary setup. Unfortunately we only had a 0.5mm drill bit lying around. To position the drill on top of the via was not easy at all. We were only able to determine the drill depth by trial and error. The ground layer has a distance to the top layer (that is used by the processor) of 0.2mm. We needed to drill open this connection without drilling into the processor itself.

RED Brick Prototyp with hole

You can find the result of our destructive work in the image above. As we connected the RED Brick to the PC and waited for a sign of life the tension was at an all time high. You might imagine how joyful we were when we actually got a prompt:

RED Brick prototype prompt

What now?

We are currently testing the new Brick. We will have to show that it works absolutely stable. Tomorrow we will get new smaller drills, which we will use to bring more prototypes to life. After that we have to test all of the interfaces, such as HDMI and USB host. Then we will test the stack interface for the Bricks as well as the Master Extensions. In parallel our linux image is improved, there are still lots of customizations and optimizations needed. A big open task is to write a Linux kernel driver for communication with stack participants as well as (if necessary) changing the stack communication of all Bricks. The last and biggest open task is to implement the end user interface and the internal program execution.

We are super happy with the prototypes. All of the bugs in the hardware design that we found until now can be corrected with ease. Currently it looks like we will even be able to reuse the SMD stencil of the prototype for the mass production, since we don’t have to relocate any of the pads.

In the future we will write more blog entries about the RED Brick. We hope to be able to pass all of the remaining tests without changes. Cross your fingers!

New Starter Kit: Internet of Things

written by admin, on May 5, 2014 5:09:00 PM.

We just released our newest starter kit, the Starter Kit: Internet of Things. It is available for the introductory price of 49.99€.

http://www.tinkerforge.com/en/doc/_images/Kits/iot_on_table_600.jpg

The Internet of Things is an evolution of the Internet. It interconnects not only human and computer as before but also physical objects (things). Things can be home appliances, vehicles, industrial facilities or potentially everything we interact with daily.

http://www.tinkerforge.com/en/doc/_images/Kits/iot_half_open_600.jpg

The Starter Kit: Internet of Things basically consists consists of a Remote Switch Bricklet and a Master Brick. It allows to contol 433MHz actuators such as remotely controlled mains switches, remote dimmers and home automation components like automated blinds. We developed the web site iot-remote.com for the kit. It allows to control those acutators and the devices that are connected to them without any programming. The web sie uses the Tinkerforge Javascript Bindings, after you downloaded the web site for the first time you can use it in offline mode without an internet connection. Communication happens only between the controlling device, e.g. PC, smart phone or tablet and the actuator itself. The communication does not go through the Tinkerforge server or similar. If you don’t want to program anything yourself, you can easily use this web site to control your living room lights or other devices over the internet.

http://www.tinkerforge.com/en/doc/_images/Kits/iot_website_iot_remote_switch_600.jpg

If you want to implement your own project ideas you can use the Bindings for the Remote Switch Bricklet and as appropriate integrate other Tinkerforge modules. As an example a light or temperature dependent controlling with the Ambient Light or Temperature Bricklet is very easy to realize. The case of the starter kit does have additional holes for the Ethernet Extension, which can also be easily integrated. With the Ethernet Extension you can go without a Raspberry PI or similar that is used as a gateway.

About Us

 

Follow Us