Serial API Broken

[Rich Mayfield]

I believe that something broke in the Serial API within the last few weeks. I can't pin a date on it, but when I came back to my app, the serial port would no longer connect. I tested previous stable versions on multiple platforms with the same results. Here's where I'm at:

Primary Development: Ubuntu 12.04 with Chrome Version 30.0.1599.114

Serial Device: Arduino and Parallax xBee Explorer (Both have serial-usb drivers)

I can enumerate a list of ports and see that the device is connected. When I try to open the port, it will not do so and the connection ID is reported as -1. 

I've tested this with my app on PC, Ubuntu, and a Mac. Same issue across all.

I've downloaded another app, Espruino IDE, which has a terminal port. It has the same problems that my App does.

When I connect the hardware to the computer and open up a Terminal Program (CuteCom) I can access the port, open it, and see data. 

It seems like an issue with the Chrome Serial API. Any ideas?

[Rich Mayfield]

I was running a serial port terminal program at it was working. However, I was running the program as root. When I checked for solutions to that problem I found that a special permission was needed to access the serial port. I added my user the the group "dialout" and now I am able to access the serial port in chrome.

In a terminal window:

sudo adduser USERNAME dialout

Then reboot. That solved my problem. Might want to put that in a FAQ if you're distributing apps that use the serial API.

[Renato Mangini]

Thanks for pointing this out, Rich. Permission is something inherent to the platform, although it is worth mentioning it in the docs.

Renato Mangini | Chrome Developer Programs Engineer | man...@google.com | +55 11 2395-8608

--
You received this message because you are subscribed to the Google Groups "Chromium Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-app...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-apps/.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

[Rich Mayfield]

I guess we can start accumulating stuff like this here:

I'm using a Windows 7 Ultimate machine. Updates happened or something and now all the apps that use the serial API won't enumerate a list of ports. Previously, it would show COM1 and COM13, the hardware port, and the USB Serial converter. Now, all the apps show nothing.

[λ Ken Rockot]

Please see the documentation at http://developer.chrome.com/apps/serial.html. The API has been overhauled in a way that breaks backwards-compatibility. Moving forward you can expect the API to be stable.

For one thing, it's now chrome.serial.getDevices instead of chrome.serial.getPorts.

The underlying implementation hasn't changed its strategy for port enumeration on Windows, so it's very unlikely that the set of enumerable ports will change in any way.

[Rich Mayfield]

I see...is there a way to subscribe to these "overhauls"? I read the documentation and see "Stable since Version 23" and make the assumption that nothing major has changed since version 23 that would break compatibility. I would never think to check to see that a function name changed. What should I subscribe to to be informed of stuff like this? Things like this cause a lot of pain.

[λ Ken Rockot]

We didn't make these change without hesitation, and discussion happened on apps...@chromium.org (as most API discussion does).

In general there was much unhappiness surrounding the state of the API, and given the relatively low volume of usage it had seen so far, we chose to overhaul now rather than watch a bad API grow in usage and get stuck with it for the long haul.

We did reach out through the Webstore a few days ago to known serial app developers with a heads-up, including a detailed overview of the changes and advice for adaptation to the new API.

[Rich Mayfield]

Cool. It's good to know you're continuing to support serial. I've put a lot of time into an app that relies heavily on it and I was afraid it was going to break and get dropped due to low usage. Thanks for the support.

[Rich Mayfield]

I've been digging into the changes and as you said, they're for the better. I've updated my app, however, I'm having trouble following how you implemented the read function. I see that it's a callback now, here's what I came up with:

function openSerial(){

var portName = $('#portDropdown').val();

chrome.serial.connect(portName, {bitrate: 115200}, function(connInfo) {

onReceive = new chrome.Event();

SerialID= connInfo.connectionId;

if(SerialID=='-1'){

$('#serialStatus').html("Port Error");

return;

}

$('#msgBuffer').html("Port Open: "+connInfo.connectionId);

$('#serialStatus').html("Port Open");

$('#serialStatus').css("color","green");

//Set listener for serial data

chrome.serial.onReceive.addListener(lineReader(receiveInfo));

});

}

---and then---

function lineReader(receiveInfo){

if (receiveInfo.connectionId === SerialID) {

       var buffer = ab2str(receiveInfo.data);

  for (var i = 0; i < buffer.length; i++) {

       if (buffer[i] === '\n') {

        parseLine(currentLine);

        currentLine = '';

       } else {currentLine += buffer[i];}

  }

}

}

There's probably some fundamental misunderstanding going on on my part. Can you point me in the right direction?

[Ken Rockot]

The really broken code here is your call to addListener - you're passing the result of calling lineReader(receiveInfo) rather than passing an actual function object. This line should probably just be:

chrome.serial.onReceive.addListener(lineReader);

Also for what it's worth, you can add that listener at any time. All serial connections opened by your app will fire events to the same set of handlers. No need to wait until you've opened a connection to register a receive handler.

Note also that connectionId will never be -1 now. If connection fails, connectionInfo itself will be undefined, so you can test for failure with a simple !connInfo condition.

Finally I think the "onReceive = new chrome.Event();" may be a remnant from some other code, as it doesn't really do anything useful here.

Otherwise, looks good and I think you've got the right idea.

[Rich Mayfield]

Got it. That makes sense. However, another problem is cropping up with some code that was previously working:

function refreshPortList(){

chrome.serial.getDevices(function(ports) {

var dd = $('#portDropdown');

dd.empty();

dd.append($('<option>Select Port...</option>'));

for (var i = 0; i < ports.length; i++) {

dd.append($('<option>' + ports[i].path + '</option>')

  .attr({ value: ports[i].path }).addClass('text'));

}

});

}

Again, it was working before, now it's broken.

It's telling me that chrome.serial has no "getDevices" object...and it's strange, when I type in the debugger, sometimes the "getDevices" method shows up in the autocomplete, sometimes it doesn't.

[Rich Mayfield]

So...apparently the API has been rolled back to the previous state? No more listener...no more getDevices. Is there a discussion somewhere I'm missing. Let me express my frustration:

1. The serial connection on my app breaks, I have no idea why.

2. I troubleshoot to no avail, post here, find that it's been updated.

3. I spend a day updating my app to the new API

4. It breaks again.

5. Out of curiosity, I open up a previous version and find that the old code all works again

WTF?

[Brandon Nozaki Miller]

What version of chrome are you developing with? Are you on the stable version? I generally develop on the Dev version which is one step ahead of the stable verison, but I know some people who develop on the beta or canary builds, and they sometimes have issues like you are having since things are far more unstable in those environments.

I ask this because I just built and released a serial terminal app last night or the night before.

-Brandon

[λ Ken Rockot]

It hasn't been rolled back. The new API will be on Chrome 33 and higher. The old API is still exposed in Chromes 31 & 32.

I would encourage you to continue using the new API though. There's some polyfill here that you can add to your app so the new API will mostly work on versions before 33, provided you don't strictly rely on previously unsupported features like timeouts or custom bitrates.

Once 33 is stable, you shouldn't have to worry about supporting the old API, and you can simply remove the polyfill from your app.

[Sungguk Lim]

Great, I'm happy that Serial APIs has been improved! .

2013년 12월 24일 화요일 오전 3시 45분 49초 UTC+9, Ken Rockot 님의 말:

[Rich Mayfield]

Some discrepancies:

This page: http://developer.chrome.com/apps/serial.html#method-getDevices

Describes the "getDevices" method which seems to be the one that works.

While this page: http://developer.chrome.com/apps/app_serial.html describes that "getPorts" which doesn't work. 

I haven't had time to put into updating my code, but I just came back to it and noticed that it's still confusing. 

[Ryan]

Hi Ken,

I am using the new Serial API on Chrome: 33.0.1750.70 beta

I'm noticing a few issues with it:

* When i create a serial connection the bitrate of the opened connection is always 9600, irrespective of the specified bitrate in the connection info;

* chrome.serial.update appears to crash, or at least stop processing further JS commands, (Polyfil indicates this is not implemented is this expected?);

* From my understanding of the API, i don't add a Read listener to a specific connection. What happens if i have two serial ports open, how do i determine which port has invoked the listener?

At what point can we expect the implementation to match the documented API (http://developer.chrome.com/apps/serial.html)? 

Cheers Ryan

[Brandon Nozaki Miller]

All of those things you mentioned should be working fine in chrome 33+

I made a serial repo you can look at. It is creative commons attribution license so if you use it, just credit me somewhere :)

https://github.com/RIAEvangelist/Chrome-Serial-App

[ja...@pinocc.io]

* When i create a serial connection the bitrate of the opened connection is always 9600, irrespective of the specified bitrate in the connection info

Are you using OSX? We ran into an identical problem, filed a bug report here, and are waiting for confirmation that this is a bug, and won't make it into stable.

[Ryan]

Hi Thanks for your response,

Yes i am using OSX. Will give the extension a go on windows

I also should note my mistake that the read listener specifies the connection number, so you can differentiate as to which serial port is responding. 

Its just harder to encapsulate the logic when you are trying to talk to multiple devices.

[Rich Mayfield]

Is there a date in mind that all these updates will be incorporated into the latest stable release?

In other words, the API was updated, and was last updated in version 3x.xx something...when will said version go stable?

[Brandon Nozaki Miller]

I believe the api will be released with stable 33

[λ Ken Rockot]

The API update was in 33, which should be on stable channel in a few weeks.

[Rich Mayfield]

Cool...so if I can wait a few weeks, I won't have to worry about that polyfill?

[Ken Rockot]

That is correct.

--

[Rich Mayfield]

Sweet. Thanks for the support. The change was a little painful, but it's a much better API now.

[Sungguk Lim]

Currently, ChromeOS for ChromeBook is M34, and Chrome for Windows,mac,ubuntu stable channel is M32. 

for now, the problem is the code should be seperated depending on the version.  

any good idea about that? my app is already released. and only chromebook users are complaining. 

--
You received this message because you are subscribed to a topic in the Google Groups "Chromium Apps" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-apps/e9qKDGwHMus/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-app...@chromium.org.

[λ Ken Rockot]

All versions of Chrome should be stable on 33 soon. Chrome 34 is dev channel on ChromeOS right now, not stable.

If you want to support the API on versions older than 33, there's some polyfill here. If run on Chrome 33+, this will have no effect. If run on an older version of Chrome it will set up chrome.serial functions which look and behave close enough to the new API that you can probably update all of your code.

When 33 goes stable you can just remove the polyfill.

[Brandon Nozaki Miller]

If you look at the architecture of my serial app, GitHub link earlier in this thread, you can see how you could easily and cleanly separate out the code based on a simple check of the current chrome version.