21 Aug 2019

feedAndroid Developers Blog

The Google Play store’s visual refresh

Boris Valusek, Design Lead, Google Play

The Google Play Store has over two billion monthly active users coming to find the right app, game, and other digital content. To improve the overall store experience, we're excited to roll out a complete visual redesign. Aligning with Material design language, we're introducing several user-facing updates to deliver a cleaner, more premium store that improves app discovery and accessibility for our diverse set of users.

Google Play store's visual refresh

To make browsing faster and easier, we've introduced a new navigation bar at the bottom of the Play Store on mobile devices and a new left navigation on tablets and Chrome OS. There are now two distinct destinations for games and apps, which helps us better serve users the right kind of content. Once users find the right app or game, the updated store listing page layout surfaces richer app information at the top of each page as well as a more prominent call-to-action button. This makes it easier for users to see the important details and make a decision to install your app. You'll also notice our new icon system with a uniform shape, helping content to stand out more over UI. If you haven't done so already, make sure to update your icon following the new icon specifications as soon as possible.

If you're looking for best practices to make a compelling store listing page, we have several resources to help. To ensure your page resonates well with Android users, use store listing experiments to test for the best app icon, images, video, and descriptions on Google Play. You can also tailor your marketing messages to specific user groups based on their country, install state or even pre-registration by creating custom store listings. For even more, try our free e-learning resource, Academy for App Success.

How useful did you find this blogpost?


21 Aug 2019 5:00pm GMT

20 Aug 2019

feedAndroid Developers Blog

Android Studio 3.5: Project Marble goes into stable


Posted by Jamal Eason, Product Manager, Android
Android Studio logo
Have you ever wished that Android Studio was faster, more performant, and more memory efficient? If so, then download Android Studio 3.5 today. This stable version of Android Studio is a different kind of release where the Android Studio team took a step back from large feature work for eight months and instead focused on product quality to further accelerate your day-to-day app development. We called this initiative Project Marble, and it focused on making the fundamental features and flows of Android Studio & Emulator rock-solid by looking at three core areas: system health, feature polish, and bugs. Working on Project Marble was in direct response to feedback from you and we continue to welcome any further feedback you have.
To improve system health in Android Studio, we first created a new set of infrastructure and internal dashboards to better detect performance problems. We did this to establish a safety net to catch issues that are typically difficult to catch with regular unit testing. Then, the team addressed a range of issues from fixing over 600 bugs, 50 memory leaks, 20 IDE hangs, and improving XML & Kotlin typing latency. Additionally, for the Android Emulator, we decreased the CPU and memory impact on your development machine. Project Mable was a focused period to work on the IDE and Android Emulator system health but it also uncovered a set of quality areas we will continue to work on going forward.
On top of memory and performance, we spent time polishing and fixing core user facing feature areas. For example, we took a look at the app deployment flow to a device, and completely re-architectured and replaced Instant Run with Apply Changes so that it's more reliable and trusted. With Apply Changes, we no longer modify an APK during your build but instead, we use runtime instrumentation to redefine classes on the fly. If you want to quickly edit code and see code changes, you should try Android Studio 3.5 today.
Lastly, over the course of Project Marble we fixed bugs which landed in Android Studio in 3.5. We are thankful to those who filed bug reports and engaged with us on social media. We are especially thankful for the over 40 external contributors in the Android community that diligently worked with us in filing and resolving critical quality issues in Android Studio 3.5. Project Marble is not the end of quality work for the Android Studio team, but this latest stable release is a major milestone of our on-going quality investment into the IDE. With the quality work and new infrastructure put in place during Project Marble, we hope that you are even more productive in developing Android apps when you download and use Android Studio 3.5.
There are many quality changes we made to Android Studio 3.5. To see the full list of changes, see the Android Studio 3.5 beta release blog and release notes. But you can dive into some of the highlights of the changes below:

System Health


System health improvements during Project Marble was a combination of memory performance, typing & user interfaces freezes, build speed, CPU usage, and I/O performance. For each of these areas we created new ways to detect issues during development and a better process to analyze your feedback both from opt-in analytics and bugs that you file.
Our system health work has many under the hood improvements but a few notable changes include:
Auto-recommend Memory Settings
With Android Studio 3.5, the IDE will recognize when an app project needs more RAM on a machine with higher RAM capacity and will notify you to increase the memory heap size or you can adjust the settings yourself under Appearance & Behavior → Memory Settings.
Memory Settings
Memory Settings
User Interface Freezes
During the Project Marble development timeframe, we found in our opt-in product analytics that XML code editing was notably slower in the IDE. With this data point, we optimized XML typing, and have measurably better performance in Android Studio 3.5. You can see below that editing data binding expressions in XML is faster due to typing latency improvements.
Code Editing Before
Code Editing Before - Android Studio 3.4

Code Editing After - Android Studio 3.5
Build Speed
For Android Studio 3.5 we made many speed improvements but a significant change is the addition of incremental build support to the top annotation processors including Glide, AndroidX data binding, Dagger, Realm, and Kotlin (KAPT). Incremental support can make a notable impact on build speed. Learn more here.
Disk I/O File Access Speed
For users on Microsoft® Windows®, we found that disk I/O access times were notable higher on average than other platforms. Digging into the data, we found the default configuration of anti-virus scanners did not optimally exclude build output folders. In Android Studio 3.5, we detect this situation and help guide you through the optimal setup.
System Health Notification
System Health Notification - Anti-virus Check

Feature Polish


In addition to improving system health we relooked at a few critical users flows to address bugs and user friction. The areas we looked at ranged from data binding, layout editor, ChromeOS support to project upgrades. One notable area of improvement to highlight is the app deployment flow:
Apply Changes
During the Project Marble time period, we removed Instant Run and re-architectured and implemented from the ground-up a more practical approach in Android Studio 3.5 called Apply Changes. Apply Changes uses platform-specific APIs from Android Oreo and higher to ensure reliable and consistent behavior; unlike Instant Run, Apply Changes does not modify your APK. To support the changes, we re-architected the entire deployment pipeline to improve deployment speed, and also tweaked the run and deployment toolbar buttons for a more streamlined experience.
Apply Changes Buttons
Apply Changes Buttons
App Deployment User Flow
App Deployment User Flow
To recap, Android Studio 3.5 has hundreds of bug fixes and notable changes in these core areas:
System Health
  • Memory Settings
  • Memory Usage Report
  • Reduce Exceptions
  • User Interface Freezes
  • Build Speed
  • IDE Speed
  • Lint Code Analysis
  • I/O File Access
  • Emulator CPU Usage
Feature Polish
  • Apply Changes
  • Gradle Sync
  • Project Upgrades
  • Layout Editor
  • Data Binding
  • App Deployment
  • C++ Improvements
  • Intellij 2019.1 Platform Update
  • Conditional Delivery for Dynamic Feature Support
  • Emulator Foldables & Google Pixel Device Support
  • Chrome OS Support
Check our the Android Studio release notes page for more details and read about deep dives into several areas of Project Marble in the following Medium blog posts & Google I/O talk:

Opt-In & Feedback


The specific areas and the approach we took to optimize Android Studio for Project Marble were all based on your feedback and metrics data. The aggregate metrics you can opt-in to inside of Android Studio allow us to figure out if there are broader problems in the product for all users, and the data also allows the team to prioritize feature work appropriately. There are are a couple pathways to help us build better insights. At a baseline, you can opt-in to metrics, by going to Preferences /Settings → Appearance & Behavior → Data Sharing.
IDE Data Sharing
IDE Data Sharing
Additionally, throughout the year, you might see user sentiment emojis in the bottom corner of the IDE. Those icons are a lightweight way to inform the Android Studio team on how things are going and to give us in-context feedback, and the fastest way to log a bug and send to the team.
IDE User Feedback
IDE User Feedback

Getting Started


Download
Download Android Studio 3.5 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio.
To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.1.9 downloaded via the Android Studio SDK Manager.
As mentioned above, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

20 Aug 2019 5:00pm GMT

feedPlanet Maemo

Migrating to a new Mastodon instance

The wonders of improvised Mastodon instances: one node disappears after an outage caused by a summer heatwave, leaving its users no way to migrate their data or to notify their followers.

After about one month of waiting for the node to come up or give some signals of life, I've decided to create a new account on another instance. If you use Mastodon and you were following me, please forgive me for the annoyance and follow me again here.

0 Add to favourites0 Bury

20 Aug 2019 2:39pm GMT

15 Aug 2019

feedAndroid Developers Blog

Improving Accessibility in the Android Ecosystem

Posted by Ian Stoba, Program Manager, Accessibility Engineering

With billions of Android devices in use around the world and millions of apps available on the Play Store, it might seem difficult to drive change across the entire ecosystem, but the Accessibility Developer Infrastructure team is doing just that.

Every time a developer uploads an APK or app bundle to the open or closed tracks, Play tests this upload on various device models running different versions of Android and generates a pre-launch report to inform the developer of issues.

One year ago, the team added accessibility suggestions to the report based on industry best practices and Google's own experience. These tests check for common issues that can make an app harder to use by people with disabilities. For example, they check that buttons are large enough to be comfortable for people to press, and that text has enough contrast with the background to be easier to read.

Since launching in July 2018, more than 3.8 million apps have been tested and over 171 million suggestions have been made to improve accessibility. Along with each suggestion, the developer gets detailed information about how to implement it. Every developer, from a one-person startup to a large enterprise, can benefit from the accessibility suggestions in the pre-launch report.

We are already seeing the real-world impact of these efforts. This year at Google I/O, the number of developers signing up for in-person accessibility consultations was four times the number from 2018. Googlers staffing these sessions reported that the developers had specific questions that were often based on the suggestions from the pre-launch report. The focused questions allowed the Googlers to give more actionable recommendations. These developers found that improving accessibility isn't just the right thing to do, it also makes good business sense by increasing the potential market for their apps.

Accessibility tests in the pre-launch report are just one way Google is raising awareness about accessibility in the global developer community. We partnered with Udacity to create a free online course about web accessibility, released our Accessibility Scanner for Android on the Play Store, and published iOS Accessibility Scanner on GitHub, allowing iOS developers to easily instrument apps to accessibility tests. Together, these efforts support Google's mission to organize the world's information and make it universally accessible and useful.

Learn more about developing with accessibility in mind by visiting the Android Developer Guidelines and the Google Developer Documentation Style Guide.

15 Aug 2019 11:00pm GMT

09 Aug 2019

feedPlanet Maemo

calibDB: easy camera calibration as a web-service

This image has an empty alt attribute; its file name is overlay1.jpg

Camera calibration just got even easier now. The pose calibration algorithm mentioned here is available as web-service now.

This means that calibration is no longer restricted to a Linux PC - you can also calibrate cameras attached to Windows/ OSX and even mobile phones.
Furthermore you will not have to calibrate at all if your device is already known to the service.
The underlying algorithm ensures that the obtained calibrations are reliable and thus can be shared between devices of the same series.

Aggregating calibrations while providing on-the-fly calibrations for unknown devices form the calibDB web-service.

In the future we will make our REST API public so you can transparently retrieve calibrations for use with your computer vision algorithms.
This will make them accessible to a variety of devices, without you having to worry about the calibration data.

0 Add to favourites0 Bury

09 Aug 2019 4:13pm GMT

Beyond the Raspberry Pi for Nextcloud hosting

When using Nextcloud it makes some sense to host it yourself at home to get the maximum benefit of having your own cloud.

If you would use a virtual private server or shared hosting, your data would still be exposed to a third party and the storage would be limited as you would have to rent it.

When setting up a server at home one is tempted to use a Raspberry Pi or similar ARM based device. Those are quite cheap and only consume little power. Especially the latter property is important as the machine will run 24/7.

I was as well tempted and started my self-hosting experience with an ARM based boards, so here are my experiences.

Do not use a Raspberry Pi for hosting

Actually this is true for any ARM based board. As for the Pi itself, only the most recent Pi 4B has a decent enough CPU and enough RAM to handle multiple PHP request (WebCAL, Contacts, WebDAV) from different clients without slowdown.
Also only with the Pi 4B you can properly attach storage over USB3.0 - previously your transfer rates would be limited by the USB2.0 bus.

One might argue that other ARM based computers are better suited. Indeed you could get the decently equipped Odroid U3, long before the Pi 4B was available.
However, non-pi boards have their own set of problems. Typically, they are based on an Smartphone design (e.g. the Odroid U3 essentialy is a Galaxy Note 2).

This makes them plagued by the Android update issues, as these boards require a custom kernel, that includes some of the board specific patches which means you cannot just grab an Ubuntu ARM build.
Instead you have to wait for a special image from the vendor - and just as with Android, at some point, there will be no more updates.

Furthermore ARM boards are actually not that cheap. While the Pi board itself is indeed not expensive at ~60€, you have to add power-supply housing and storage.

Intel NUC devices are a great choice

While everyone was looking at cheap and efficient ARM based boards, Intel has released some great NUC competitors.
Those went largely unnoticed as typically only the high-end NUCs get news coverage. It is more impressive to report how much power one can cram into a small form-factor.

However one can obviously also put only little power in there. More precisely, Intels tablet celeron chips that range around 4-6W TDP and thus compete with ARM boards power-wise. (Still they are an order of magnitude faster then a Raspberry Pi)

Device Power (Idle) Power (load)
Odroid U3 3.7 W 9 W
GB-BPCE-3350C 4.5 W 9.6 W

Here, you get the advantages of the mature x86 platform, namely interchangeable RAM, interchangeable WiFi modules, SATA & m2 SSD ports and notably upstream Linux compatibilty (and Windows for that matter).

As you might have guessed by the hardware choice above, I made the switch already some time ago. On the one hand you only get reports for the by now outdated N3350 CPU - but on on the other hand it makes this a long term evaluation.

Regarding the specific NUC model, I went with the Gigabyte GB-BPCE-3350C, which are less expensive (currently priced around 90€) than the Intel models.

Consequently the C probably stands for "cheap" as it lacks a second SO-DIMM slot and a SD-card reader. However it is fan-less and thus perfectly fine for hosting.

So after 2 Years of usage and a successful upgrade between two Ubuntu LTS releases, I can report that switching to the x86 platform was worth it.

If anything I would probably choose a NUC model that also supports M.2/ M-Key in addition to SATA to build a software RAID-1.

0 Add to favourites0 Bury

09 Aug 2019 3:45pm GMT

25 Sep 2017

feedPlanet Openmoko

Holger "zecke" Freyther: Brain dump what fascinates me

A small brain dump of topics that currently fascinate me. These are mostly pointers and maybe it is interesting to follow it.

Books/Reading:

My kobo ebook reader has the Site Reliability Engineering book and I am now mostly done. It is kind of a revelation and explains my interest to write code but also to operate infrastructure (like struggling with ruby, rmagick, nginx…). I am interested in backends since… well ever. The first time I noticed it when we talked about Kolab at LinuxTag and I was more interested in the backend than the KDE client. At sysmocom we built an IoT product and the backend was quite some fun, especially the scale of one instance and many devices/users, capacity planning and disk commissioning, lossless upgrades.

It can be seen in my non FOSS SS7 map work on traffic masquerading and transparent rewriting. It is also clear to see which part of engineering is needed for scale (instead of just installing and restarting servers).

Lang VM design

One technology that made Java fast (Hotspot) and has seen its way into JavaScript is dynamic optimization. Most Just in Time Compilers start with generating native code per method, either directly or after the first couple of calls when the methods size is significant enough. The VM records which call paths are hot, which types are used and then can generate optimized code (e.g. specialized for integers, remove type checks). A technique pioneered at Sun for the "Self" language (and then implemented for Strongtalk and then brought to Java) was "adaptive optimization and deoptimization" and was the Phd topic of Urs Hoelzle (Google's VP of Engineering). One of the key aspects is inlining across method boundaries as this removes method look-up, call stack handling and opens the way for code optimization across method boundaries (at the cost of RAM usage).

In OpenJDK, V8 and JavaScriptCore this adaptive optimization is typically implemented in C++ and requires quite some code. The code is complicated as it needs to optimize but also need to return to a basic function (deoptimize, e.g. if a method changed or the types passed don't match anymore), e.g. in the middle of a for loop with tons of inlined code (think of Array.map being inlined but then need to be de-inlined). A nice and long blog post of JSC can be found here describing the On Stack Replacement (OSR).

Long introduction and now to the new thing. In the OpensmalltalkVM a new approach called Sista has been picked and I find it is genius. Like with many problems the point of view and approach really matters. Instead of writing a lot of code in the VM the optimizer runs next to the application code. The key parts seem to be:

The revelation is the last part. By just optimizing from bytecode to bytecode the VM remains in charge of creating and managing machine code. The next part is that tooling in the higher language is better or at least the roundtrip is more quick (edit code and just compile the new method instead of running make, c++, ld). The productivity thanks to the abstraction and tooling is likely higher.

As last part the OSR is easier as well. In Smalltalk thisContext (the current stack frame, activation record) is an object as well. At the right point (when the JIT has either written back variables from register to the stack or at least knows where the value is) one can just manipulate thisContext, create and link news ones and then resume execution without all the magic in other VMs.

Go, Go and escape analysis

Ken Thompson and Robert Pike are well known persons and their Go programming language is a very interesting system programming language. Like with all new languages I try to get real world experience with the language, the tooling and which kind of problems can be solved with it. I have debugged and patched some bigger projects and written two small applications with it.

There is plenty I like. The escape analysis of the compiler is fun (especially now that I know it was translated from the Plan9 C compiler from C to Go), the concurrency model is good (though allowing shared state), the module system makes sense (but makes forking harder than necessary), being able to cross compile to any target from any system.

Knowing a bit of Erlang (and continuing to read the Phd Thesis of Joe Armstrong) and being a heavy Smalltalk user there are plenty of things missing. It starts with vague runtime error messages (e.g. panicslice not having parameters) and goes to runtime and post-runtime inspection. In Smalltalk thanks to the abstraction a lot of hard things are easy and I would have wished for some of them to be in Go. Serialize all unrecovered panics? Debugging someone else's code seems like pre 1980…

So for many developers Go is a big improvement but for some people with a wider view it might look like a lost opportunity. But that can only be felt by developers that have experienced higher abstraction and productivity.

Unsupervised machine learning

but that is for another dump…

25 Sep 2017 10:11am GMT

02 Sep 2017

feedPlanet Openmoko

Harald "LaF0rge" Welte: Purism Librem 5 campaign

There's a new project currently undergoing crowd funding that might be of interest to the former Openmoko community: The Purism Librem 5 campaign.

Similar to Openmoko a decade ago, they are aiming to build a FOSS based smartphone built on GNU/Linux without any proprietary drivers/blobs on the application processor, from bootloader to userspace.

Furthermore (just like Openmoko) the baseband processor is fully isolated, with no shared memory and with the Linux-running application processor being in full control.

They go beyond what we wanted to do at Openmoko in offering hardware kill switches for camera/phone/baseband/bluetooth. During Openmoko days we assumed it is sufficient to simply control all those bits from the trusted Linux domain, but of course once that might be compromised, a physical kill switch provides a completely different level of security.

I wish them all the best, and hope they can leave a better track record than Openmoko. Sure, we sold some thousands of phones, but the company quickly died, and the state of software was far from end-user-ready. I think the primary obstacles/complexities are verification of the hardware design as well as the software stack all the way up to the UI.

The budget of ~ 1.5 million seems extremely tight from my point of view, but then I have no information about how much Puri.sm is able to invest from other sources outside of the campaign.

If you're a FOSS developer with a strong interest in a Free/Open privacy-first smartphone, please note that they have several job openings, from Kernel Developer to OS Developer to UI Developer. I'd love to see some talents at work in that area.

It's a bit of a pity that almost all of the actual technical details are unspecified at this point (except RAM/flash/main-cpu). No details on the cellular modem/chipset used, no details on the camera, neither on the bluetooth chipset, wifi chipset, etc. This might be an indication of the early stage of their plannings. I would have expected that one has ironed out those questions before looking for funding - but then, it's their campaign and they can run it as they see it fit!

I for my part have just put in a pledge for one phone. Let's see what will come of it. In case you feel motivated by this post to join in: Please keep in mind that any crowdfunding campaign bears significant financial risks. So please make sure you made up your mind and don't blame my blog post for luring you into spending money :)

02 Sep 2017 10:00pm GMT

01 Sep 2017

feedPlanet Openmoko

Harald "LaF0rge" Welte: First actual XMOS / XCORE project

For many years I've been fascinated by the XMOS XCore architecture. It offers a surprisingly refreshing alternative virtually any other classic microcontroller architectures out there. However, despite reading a lot about it years ago, being fascinated by it, and even giving a short informal presentation about it once, I've so far never used it. Too much "real" work imposes a high barrier to spending time learning about new architectures, languages, toolchains and the like.

Introduction into XCore

Rather than having lots of fixed-purpose built-in "hard core" peripherals for interfaces such as SPI, I2C, I2S, etc. the XCore controllers have a combination of

  • I/O ports for 1/4/8/16/32 bit wide signals, with SERDES, FIFO, hardware strobe generation, etc
  • Clock blocks for using/dividing internal or external clocks
  • hardware multi-threading that presents 8 logical threads on each core
  • xCONNECT links that can be used to connect multiple processors over 2 or 5 wires per direction
  • channels as a means of communication (similar to sockets) between threads, whether on the same xCORE or a remote core via xCONNECT
  • an extended C (xC) programming language to make use of parallelism, channels and the I/O ports

In spirit, it is like a 21st century implementation of some of the concepts established first with Transputers.

My main interest in xMOS has been the flexibility that you get in implementing not-so-standard electronics interfaces. For regular I2C, UART, SPI, etc. there is of course no such need. But every so often one encounters some interface that's very rately found (like the output of an E1/T1 Line Interface Unit).

Also, quite often I run into use cases where it's simply impossible to find a microcontroller with a sufficient number of the related peripherals built-in. Try finding a microcontroller with 8 UARTs, for example. Or one with four different PCM/I2S interfaces, which all can run in different clock domains.

The existing options of solving such problems basically boil down to either implementing it in hard-wired logic (unrealistic, complex, expensive) or going to programmable logic with CPLD or FPGAs. While the latter is certainly also quite interesting, the learning curve is steep, the tools anything but easy to use and the synthesising time (and thus development cycles) long. Furthermore, your board design will be more complex as you have that FPGA/CPLD and a microcontroller, need to interface the two, etc (yes, in high-end use cases there's the Zynq, but I'm thinking of several orders of magnitude less complex designs).

Of course one can also take a "pure software" approach and go for high-speed bit-banging. There are some ARM SoCs that can toggle their pins. People have reported rates like 14 MHz being possible on a Raspberry Pi. However, when running a general-purpose OS in parallel, this kind of speed is hard to do reliably over long term, and the related software implementations are going to be anything but nice to write.

So the XCore is looking like a nice alternative for a lot of those use cases. Where you want a microcontroller with more programmability in terms of its I/O capabilities, but not go as far as to go full-on with FPGA/CPLD development in Verilog or VHDL.

My current use case

My current use case is to implement a board that can accept four independent PCM inputs (all in slave mode, i.e. clock provided by external master) and present them via USB to a host PC. The final goal is to have a board that can be combined with the sysmoQMOD and which can interface the PCM audio of four cellular modems concurrently.

While XMOS is quite strong in the Audio field and you can find existing examples and app notes for I2S and S/PDIF, I couldn't find any existing code for a PCM slave of the given requirements (short frame sync, 8kHz sample rate, 16bit samples, 2.048 MHz bit clock, MSB first).

I wanted to get a feeling how well one can implement the related PCM slave. In order to test the slave, I decided to develop the matching PCM master and run the two against each other. Despite having never written any code for XMOS before, nor having used any of the toolchain, I was able to implement the PCM master and PCM slave within something like ~6 hours, including simulation and verification. Sure, one can certainly do that in much less time, but only once you're familiar with the tools, programming environment, language, etc. I think it's not bad.

The biggest problem was that the clock phase for a clocked output port cannot be configured, i.e. the XCore insists on always clocking out a new bit at the falling edge, while my use case of course required the opposite: Clocking oout new signals at the rising edge. I had to use a second clock block to generate the inverted clock in order to achieve that goal.

Beyond that 4xPCM use case, I also have other ideas like finally putting the osmo-e1-xcvr to use by combining it with an XMOS device to build a portable E1-to-USB adapter. I have no clue if and when I'll find time for that, but if somebody wants to join in: Let me know!

The good parts

Documentation excellent

I found the various pieces of documentation extremely useful and very well written.

Fast progress

I was able to make fast progress in solving the first task using the XMOS / Xcore approach.

Soft Cores developed in public, with commit log

You can find plenty of soft cores that XMOS has been developing on github at https://github.com/xcore, including the full commit history.

This type of development is a big improvement over what most vendors of smaller microcontrollers like Atmel are doing (infrequent tar-ball code-drops without commit history). And in the case of the classic uC vendors, we're talking about drivers only. In the XMOS case it's about the entire logic of the peripheral!

You can for example see that for their I2C core, the very active commit history goes back to January 2011.

xSIM simulation extremely helpful

The xTIMEcomposer IDE (based on Eclipse) contains extensive tracing support and an extensible near cycle accurate simulator (xSIM). I've implemented a PCM mater and PCM slave in xC and was able to simulate the program while looking at the waveforms of the logic signals between those two.

The bad parts

Unfortunately, my extremely enthusiastic reception of XMOS has suffered quite a bit over time. Let me explain why:

Hard to get XCore chips

While the product portfolio on on the xMOS website looks extremely comprehensive, the vast majority of the parts is not available from stock at distributors. You won't even get samples, and lead times are 12 weeks (!). If you check at digikey, they have listed a total of 302 different XMOS controllers, but only 35 of them are in stock. USB capable are 15. With other distributors like Farnell it's even worse.

I've seen this with other semiconductor vendors before, but never to such a large extent. Sure, some packages/configurations are not standard products, but having only 11% of the portfolio actually available is pretty bad.

In such situations, where it's difficult to convince distributors to stock parts, it would be a good idea for XMOS to stock parts themselves and provide samples / low quantities directly. Not everyone is able to order large trays and/or capable to wait 12 weeks, especially during the R&D phase of a board.

Extremely limited number of single-bit ports

In the smaller / lower pin-count parts, like the XU[F]-208 series in QFN/LQFP-64, the number of usable, exposed single-bit ports is ridiculously low. Out of the total 33 I/O lines available, only 7 can be used as single-bit I/O ports. All other lines can only be used for 4-, 8-, or 16-bit ports. If you're dealing primarily with serial interfaces like I2C, SPI, I2S, UART/USART and the like, those parallel ports are of no use, and you have to go for a mechanically much larger part (like XU[F]-216 in TQFP-128) in order to have a decent number of single-bit ports exposed. Those parts also come with twice the number of cores, memory, etc- which you don't need for slow-speed serial interfaces...

Insufficient number of exposed xLINKs

The smaller parts like XU[F]-208 only have one xLINK exposed. Of what use is that? If you don't have at least two links available, you cannot daisy-chain them to each other, let alone build more complex structures like cubes (at least 3 xLINKs).

So once again you have to go to much larger packages, where you will not use 80% of the pins or resources, just to get the required number of xLINKs for interconnection.

Change to a non-FOSS License

XMOS deserved a lot of praise for releasing all their soft IP cores as Free / Open Source Software on github at https://github.com/xcore. The License has basically been a 3-clause BSD license. This was a good move, as it meant that anyone could create derivative versions, whether proprietary or FOSS, and there would be virtually no license incompatibilities with whatever code people wanted to write.

However, to my very big disappointment, more recently XMOS seems to have changed their policy on this. New soft cores (released at https://github.com/xmos as opposed to the old https://github.com/xcore) are made available under a non-free license. This license is nothing like BSD 3-clause license or any other Free Software or Open Source license. It restricts the license to use the code together with an XMOS product, requires the user to contribute fixes back to XMOS and contains references to importand export control. This license is incopatible with probably any FOSS license in existance, making it impossible to write FOSS code on XMOS while using any of the new soft cores released by XMOS.

But even beyond that license change, not even all code is provided in source code format anymore. The new USB library (lib_usb) is provided as binary-only library, for example.

If you know anyone at XMOS management or XMOS legal with whom I could raise this topic of license change when transitioning from older sc_* software to later lib_* code, I would appreciate this a lot.

Proprietary Compiler

While a lot of the toolchain and IDE is based on open source (Eclipse, LLVM, ...), the actual xC compiler is proprietary.

Further Reading

01 Sep 2017 10:00pm GMT

12 Nov 2011

feedPlanet Linux-to-go

Paul 'pfalcon' Sokolovsky: Shopping for 3D TV...

Shopping for 3D TV (again), few findings:

12 Nov 2011 6:55pm GMT

Paul 'pfalcon' Sokolovsky: Hacking Luxeon SP-1

I finally going to get Arduino, and while I'm choosing flavor and waiting for it, I can't help but disassembling all devices I have at home, each time speaking: "This must have Arduino inside!" (meaning of course that I expect it to be based on general-purpose MCU). Gosh, I usually get "blob chip" (uncased chip with blob of epoxy on top).

Well, I finally had my expectations fulfilled - Luxeon SP-1 voltage stabilizer/cutter features ATMEGA48V-10PU (Flash: 4k, EEPROM: 256, RAM:512). Not only that, it is installed in DIP socket! Buy from Luxeon, they're hacker-friendly ;-).

I bought the device actually for a wattmeter it features (which fact is hard to figure out from common specs found in the shops, I accidentally read somebody mentioning it on a forum). The wattmeter is of course not bright - for a lamp rated 100W it shows 88W, and for more powerful equipment (like perforator) understates wattage even more (maybe it's difference between real and apparent power factor).

Still, for $17 you get Arudino-alike with voltage/current sensor and hacking possibility. Woot!

BOM:
High-power board:

MCU board:


12 Nov 2011 5:58pm GMT

10 Nov 2011

feedPlanet Linux-to-go

Paul 'pfalcon' Sokolovsky: Links for November 2011

Kindle:


Linux kernel module tricks:

10 Nov 2011 3:21pm GMT

19 Oct 2011

feedPlanet OpenEZX

Antonio Ospite: Gnome 3: go to Shell? Not just yet, thanks.

In Debian Unstable the transition to Gnome 3 is taking place; when Gnome 3.0 firstly came out some unnamed geeky users complained loudly about the design decisions of the development team to push strongly towards gnome-shell as a new default UI; gnome-shell was designed focusing on usability (usability is a metric relative to a certain target audience BTW) and simplicity, hiding a lot of details from the users. Obviously you can never make everyone happy so some of us simply happened to be "out of target": you know us computer people (*cough cough*), we like to be in charge and control The Machine... I must admit I still don't have a definitive opinion about the gnome-shell concept, for now I just know that it does not suit me; I am going to try it eventually, maybe I'll get used to it, but in the mean time I need my desktop back just like I shaped it through the years; can this be done without loosing all the good Gnome technologies (Empathy over all of them)?

To be completely fair I have to say that there is little to complain about with Gnome developers, we can still get our good old GNOME desktop fully back by using the fall-back mode based on gnome-panel and live happily ever after, let's take a look at how this can be accomplished.

NOTE: GNOME people state that the fall-back mode is meant for systems with older graphic cards which cannot run gnome-shell, however it can very well be seen as a good opportunity for those who do not want to run gnome-shell just yet.

Getting back to the topic: some minor touches are needed to make the panel look more like what we are used to, maybe some of these settings could even become default for fall-back mode, we'll see.

First, enable fall-back mode (on Debian there is a dedicated session you can choose from the Log-in Manager for that) and change some desktop settings, in a terminal type:

$ gsettings set org.gnome.desktop.session session-name 'gnome-fallback'
$ gsettings set org.gnome.desktop.interface 'menus-have-icons' true
$ gsettings set org.gnome.desktop.interface 'buttons-have-icons' true
$ gsettings set org.gnome.desktop.background 'show-desktop-icons' true

gnome-tweak-tool can be used for some of these settings like shown in the attached images.

Then rearrange the applets on the panel as you please (use Alt-RightClick to access the panel properties), and fix the theming using this patch to have a light panel again (against gnome-themes-standard=3.0.2-1):

$ mkdir $HOME/.themes
$ cd $HOME/.themes
$ cp -r /usr/share/themes/Adwaita Adwaita-fallback
$ cd Adwaita-fallback
$ patch -p1 < $HOME/adwaita-fallback-panel-theme.patch
$ gsettings set org.gnome.desktop.interface 'gtk-theme' 'Adwaita-fallback'

Some final touches for the Metacity window manager and to the clock applet, and we are all set:

$ gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse
$ gconftool-2 --type boolean --set /apps/metacity/general/compositing_manager true
$ gconftool-2 --type string --set /apps/panel3-applets/clock/custom_format '<span color="#333">%a %d %b</span> <b>%H:%M</b>'
$ gconftool-2 --type string --set /apps/panel3-applets/clock/format custom

Ah, in the new gnome-panel based on Gtk3 there are still some details to take care of, I hope issues like that will be addressed and that the panel will be supported for quite some time.

Attached images:
Gnome Shell default look on Debian
gnome-tweak-tool show desktop icons
Gnome 3 fall-back mode default look on Debian
Gnome 3 fall-back mode applets rearranged
Gnome 3 fall-back mode rethemed to have a light panel
Attached files:
text/x-diff iconAdwaita theme patch for fall-back mode

19 Oct 2011 9:37pm GMT

09 Jun 2011

feedPlanet OpenEZX

Michael Lauer: The Eagle Has Landed!

After letting us wait for a bit longer than scheduled (13 days), the hospital initiated the contractions. For the first couple of hours, everything went just perfect, but then the little one got stuck on the way and we had to resort to a cesarean section. Lara Marie Lauer was born 8th of June at 04:41 (AM) with 3460 gramms and 49 cm.

Mummy was still on intensive care and so they gave her to me. I can't express the feelings I had in this very moment. I'm still kind of overwhelmed every time I see her. Thanks for all of you who waited anxiously with me and those who prayed for us. The most important tasks for the near future is getting Mummy to recover and Lara Marie to become accustomed to us and the rest of the outside world.

Please bear with me if in the next time I'm not as responsive as usually :)

Lara Marie Lauer

09 Jun 2011 4:06pm GMT

30 May 2011

feedPlanet OpenEZX

Michael Lauer: German Post on time!

And now for something completely different… while we are all waiting for my baby to arrive (who was scheduled for 25th of May), she just received her first greeting card - together with a personalized bib and a towel (with integrated hood - pretty fancy!) from my good friends at #openmoko-cdevel.

Guys, seeing this card was very heartwarming - it means a lot to me that you share my anticipation, thanks a lot! And I'm 100% sure she will appreciate her gifts… now let's cross fingers it won't take much longer… waiting is the hardest part of it :)

Yours,

Mickey.

30 May 2011 8:54am GMT