{"action":"created","issue":{"url":"https://api.github.com/repos/parallaxinc/ChromeIDE/issues/12","labels_url":"https://api.github.com/repos/parallaxinc/ChromeIDE/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/parallaxinc/ChromeIDE/issues/12/comments","events_url":"https://api.github.com/repos/parallaxinc/ChromeIDE/issues/12/events","html_url":"https://github.com/parallaxinc/ChromeIDE/issues/12","id":58672717,"number":12,"title":"bs2 uploader - perform reset sequence","user":{"login":"jacobrosenthal","id":455796,"avatar_url":"https://avatars.githubusercontent.com/u/455796?v=3","gravatar_id":"","url":"https://api.github.com/users/jacobrosenthal","html_url":"https://github.com/jacobrosenthal","followers_url":"https://api.github.com/users/jacobrosenthal/followers","following_url":"https://api.github.com/users/jacobrosenthal/following{/other_user}","gists_url":"https://api.github.com/users/jacobrosenthal/gists{/gist_id}","starred_url":"https://api.github.com/users/jacobrosenthal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jacobrosenthal/subscriptions","organizations_url":"https://api.github.com/users/jacobrosenthal/orgs","repos_url":"https://api.github.com/users/jacobrosenthal/repos","events_url":"https://api.github.com/users/jacobrosenthal/events{/privacy}","received_events_url":"https://api.github.com/users/jacobrosenthal/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"jacobrosenthal","id":455796,"avatar_url":"https://avatars.githubusercontent.com/u/455796?v=3","gravatar_id":"","url":"https://api.github.com/users/jacobrosenthal","html_url":"https://github.com/jacobrosenthal","followers_url":"https://api.github.com/users/jacobrosenthal/followers","following_url":"https://api.github.com/users/jacobrosenthal/following{/other_user}","gists_url":"https://api.github.com/users/jacobrosenthal/gists{/gist_id}","starred_url":"https://api.github.com/users/jacobrosenthal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jacobrosenthal/subscriptions","organizations_url":"https://api.github.com/users/jacobrosenthal/orgs","repos_url":"https://api.github.com/users/jacobrosenthal/repos","events_url":"https://api.github.com/users/jacobrosenthal/events{/privacy}","received_events_url":"https://api.github.com/users/jacobrosenthal/received_events","type":"User","site_admin":false},"milestone":{"url":"https://api.github.com/repos/parallaxinc/ChromeIDE/milestones/1","html_url":"https://github.com/parallaxinc/ChromeIDE/milestones/Sprint%201","labels_url":"https://api.github.com/repos/parallaxinc/ChromeIDE/milestones/1/labels","id":991736,"number":1,"title":"Sprint 1","description":"","creator":{"login":"phated","id":992373,"avatar_url":"https://avatars.githubusercontent.com/u/992373?v=3","gravatar_id":"","url":"https://api.github.com/users/phated","html_url":"https://github.com/phated","followers_url":"https://api.github.com/users/phated/followers","following_url":"https://api.github.com/users/phated/following{/other_user}","gists_url":"https://api.github.com/users/phated/gists{/gist_id}","starred_url":"https://api.github.com/users/phated/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/phated/subscriptions","organizations_url":"https://api.github.com/users/phated/orgs","repos_url":"https://api.github.com/users/phated/repos","events_url":"https://api.github.com/users/phated/events{/privacy}","received_events_url":"https://api.github.com/users/phated/received_events","type":"User","site_admin":false},"open_issues":11,"closed_issues":2,"state":"open","created_at":"2015-02-23T18:13:05Z","updated_at":"2015-02-25T15:46:16Z","due_on":"2015-03-06T07:00:00Z","closed_at":null},"comments":10,"created_at":"2015-02-24T00:15:21Z","updated_at":"2015-03-01T08:23:20Z","closed_at":null,"body":""},"comment":{"url":"https://api.github.com/repos/parallaxinc/ChromeIDE/issues/comments/76587677","html_url":"https://github.com/parallaxinc/ChromeIDE/issues/12#issuecomment-76587677","issue_url":"https://api.github.com/repos/parallaxinc/ChromeIDE/issues/12","id":76587677,"user":{"login":"PropGit","id":1266318,"avatar_url":"https://avatars.githubusercontent.com/u/1266318?v=3","gravatar_id":"","url":"https://api.github.com/users/PropGit","html_url":"https://github.com/PropGit","followers_url":"https://api.github.com/users/PropGit/followers","following_url":"https://api.github.com/users/PropGit/following{/other_user}","gists_url":"https://api.github.com/users/PropGit/gists{/gist_id}","starred_url":"https://api.github.com/users/PropGit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/PropGit/subscriptions","organizations_url":"https://api.github.com/users/PropGit/orgs","repos_url":"https://api.github.com/users/PropGit/repos","events_url":"https://api.github.com/users/PropGit/events{/privacy}","received_events_url":"https://api.github.com/users/PropGit/received_events","type":"User","site_admin":false},"created_at":"2015-03-01T08:23:20Z","updated_at":"2015-03-01T08:23:20Z","body":"Okay, my first tests were to resurrect an old serial port test program I wrote for Windows.  I modified it to do the same kind of this you're trying and I watched the signals with my logic analyzer.  I'm using my normal development system, with USB ports and our FTDI FT232RQ-based USB-to-Serial adapter.\r\n\r\nI have two good news items to report... \r\n  1. I can duplicate most of what you're describing with my native Windows code (on a system with the FTDI driver installed).\r\n  2. I see what's going on now.\r\n\r\n110, 120, 130, 140, 150, 160, 170, 180 don't cause errors in my test, but they result in an effective baud rate of 115.2 kBaud, strangely.\r\n\r\n184 and 190 work and generate exactly the prescribed baud rate.\r\n\r\n200 works perfectly as well.\r\n\r\nSwitching from 200 to 9600 *seems* to generate only 9600 waveforms, while switching from 9600 to 200 generates the expected signals.\r\n\r\nAfter extensive tests, I got lucky and happened to notice exactly what's going on... The system/UART *is* accepting the request to change the baud rate from 200 to 9600 (or 9600 to 200) and does so even if data is still being transmitted.  By \"lucky,\" I mean that when I was transmitting from 200 to 9600, I happened to get a trace where the first couple bits of my first byte (I was using $55 at the time, for both bytes) were transmitted at 200 baud, but then suddenly there was a short bit followed by bits that were exactly timed at 9600.  It changed baud rates mid-bit!  But most of the time, it changed to 9600 before even the first bit of the first byte was transmitted; which is what you were seeing.  The reason it didn't happen from 9600 to 200 is likely that it just took so little time to transmit the first byte in that case.\r\n\r\nBased on this, I don't think there's anything wrong with the Chrome serial API, other than it doesn't support break conditions yet.\r\n\r\nWe definitely need to ensure that the first byte is finished transmitting before switching to 9600 baud.  \r\n\r\nHave you already coded the write complete callback in your code?  In my attempts to check for Tx empty in my code, it always reports empty, so the results are no different (unpredictable).  I think I'd have to do an overlapped write operation to get the results I need using that mechanism.\r\n\r\nHowever, I reasoned that I could get better results right now by timing it better; and I have.  Using the proposed 200 baud to 9600 baud switch technique, and with a little experimentation and measurement, I've been able to get pretty consistent results where the reset pulse stays near the start of the simulated break condition (sometimes before and sometimes after), the \"break\" lasts for 45 ms, and the baud rate switches consistently after the initial $00 is sent before the next byte at 9600 is sent.\r\n\r\nHere's a captured sample.  The long Tx low is a $00 byte transmitted at 200 baud, followed by a 75+ ms delay, followed by a $55 transmitted at 9600 baud.  The reset pulse occurs (in this example) about 5 ms after the first falling edge of Tx.\r\n\r\n![200-to-9600 reset](https://cloud.githubusercontent.com/assets/1266318/6429886/c2b29088-bfa3-11e4-8437-fdadfe52c1c1.JPG)\r\n\r\nIf I recall, we have about 2.3 seconds after the end of the \"break\" condition before the BASIC Stamp gives up (if it doesn't receive the first byte of the host's serial communication).  In this case, I simply delayed for 100 ms immediately after the call to transmit the first byte, before switching baud rate to 9600 and transmitting a $55 (for example sake).\r\n\r\nAs I alluded to in an earlier message, the relative signal instances (DTR and Tx) and resulting consistency seems to work better slightly out-of-order.  Here's the algorithm I found to work well for this test:\r\n\r\n  * Open the port at 200 baud\r\n  * Transmit $00\r\n  * Assert DTR\r\n  * Delay 2 ms\r\n  * De-assert DTR\r\n  * Delay 100 ms\r\n  * Set port to 9600 baud\r\n  * Transmit $55\r\n  * Close port\r\n\r\nNote: The \"Delay 2 ms\" is intended to prevent the assert/de-assert from happening so fast that it ends up basically nullified by the OS.  The \"Delay 100 ms\" was to allow enough time to transmit the first byte, assuming the OS delivered the byte to the UART soon enough.  The final could be a fixed delay (somewhere in the 100 ms to 1000 ms area would probably be best).  The $55 is just for testing; the point is to send the actual Identification bytes at that point, instead.\r\n\r\nAlso, I never experienced DTR asserting upon port opening in my tests tonight.  What are you using as a development box?  OS X?  If so, one of our developers noticed strange behavior is OS X, like DTR simply toggling instead of asserting or de-asserting on demand.  I'd like to know if you experience this.\r\n\r\n\r\n"}}