Thread: [Flashforth-devel] USB, flow-control, and linux
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Mark G. <bit...@gm...> - 2014-02-13 00:58:04
|
Hello everyone, I am trying to run flashforth latest from GIT (appears to be 5.0, git commit 304e4cc23851c7ff5bd6360f4c8c16b880a0d51c) I have an old USB BitWhacker board (v1) with an 18f2550 on it, 20MHz crystal. I have made the adjustments to the frequency and divider to get USB working, however when I connect via /dev/ttyACM0, it appears to send some, but not all of the characters in the tx buffer. If I hit enter a couple of times, or cause enough traffic, another chunk of the txbuffer comes down. I have setting hardware flow control, disabling idle_mode, and a couple of other things, but I don't seem to get proper expected behavior. Are there other things I should be doing to enable USB besides defining USB_CDC when assembling? I have tried searching the archives, but I didn't come up with anything. -mdg -- Our problems are mostly behind us, now all we have to do is fight the solutions. |
|
From: Randall Y. <ras...@in...> - 2014-02-13 01:09:05
|
Hi Mark, I'm seeing exactly the same thing, with the PIC18F14k50 build of FF 5.0. Some characters come down, well formed, then a delay, I send a carriage return, and then more characters follow with zany formatting on the next line of my terminal session. FF 3.8 formats perfectly on the same setup, so I guess my terminal program(s) are ok. Just sharing, don't have a clue what's sideways. Best, Randy -----Original Message----- From: Mark Goldman [mailto:bit...@gm...] Sent: Wednesday, February 12, 2014 7:58 PM To: fla...@li... Subject: [Flashforth-devel] USB, flow-control, and linux Hello everyone, I am trying to run flashforth latest from GIT (appears to be 5.0, git commit 304e4cc23851c7ff5bd6360f4c8c16b880a0d51c) I have an old USB BitWhacker board (v1) with an 18f2550 on it, 20MHz crystal. I have made the adjustments to the frequency and divider to get USB working, however when I connect via /dev/ttyACM0, it appears to send some, but not all of the characters in the tx buffer. If I hit enter a couple of times, or cause enough traffic, another chunk of the txbuffer comes down. I have setting hardware flow control, disabling idle_mode, and a couple of other things, but I don't seem to get proper expected behavior. Are there other things I should be doing to enable USB besides defining USB_CDC when assembling? I have tried searching the archives, but I didn't come up with anything. -mdg -- Our problems are mostly behind us, now all we have to do is fight the solutions. ---------------------------------------------------------------------------- -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Flashforth-devel mailing list Fla...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mark G. <bit...@gm...> - 2014-02-13 01:18:21
|
Hi Randall, I was able to go back to what reports itself as 3.81 (git commit 291d6490ad45bf4c20c7bc7f196e86802f2c92ab), recompiled (after twiddling the oscillator settings) and everything seems good. Sometime when I'm less lazy, I'll try to bisect and figure out when the regression happened. Thanks, -mdg On Wed, Feb 12, 2014 at 8:09 PM, Randall Young <ras...@in...> wrote: > Hi Mark, > > I'm seeing exactly the same thing, with the PIC18F14k50 build of FF 5.0. > > Some characters come down, well formed, then a delay, I send a carriage > return, and then more characters follow with zany formatting on the next > line of my terminal session. > > FF 3.8 formats perfectly on the same setup, so I guess my terminal > program(s) are ok. > > Just sharing, don't have a clue what's sideways. > > Best, > > Randy > > > > -----Original Message----- > From: Mark Goldman [mailto:bit...@gm...] > Sent: Wednesday, February 12, 2014 7:58 PM > To: fla...@li... > Subject: [Flashforth-devel] USB, flow-control, and linux > > Hello everyone, > > I am trying to run flashforth latest from GIT (appears to be 5.0, git commit > 304e4cc23851c7ff5bd6360f4c8c16b880a0d51c) > > I have an old USB BitWhacker board (v1) with an 18f2550 on it, 20MHz > crystal. > > I have made the adjustments to the frequency and divider to get USB working, > however when I connect via /dev/ttyACM0, it appears to send some, but not > all of the characters in the tx buffer. If I hit enter a couple of times, > or cause enough traffic, another chunk of the txbuffer comes down. > > I have setting hardware flow control, disabling idle_mode, and a couple of > other things, but I don't seem to get proper expected behavior. > > Are there other things I should be doing to enable USB besides defining > USB_CDC when assembling? > > I have tried searching the archives, but I didn't come up with anything. > > -mdg > > -- > Our problems are mostly behind us, now all we have to do is fight the > solutions. > > ---------------------------------------------------------------------------- > -- > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > -- Our problems are mostly behind us, now all we have to do is fight the solutions. |
|
From: Mikael N. <mik...@pp...> - 2014-02-13 04:11:04
|
Hi, Try Timer2 as a system clock. For some reason the timer1 and 3 does not work properly with the 2 millisecond timeout for sending USB characters. I did some "improvements" in 5.0 to timer 1 and 3 for better accuracy. I'll need to fix that. BR Mikael On 02/13/2014 03:09 AM, Randall Young wrote: > Hi Mark, > > I'm seeing exactly the same thing, with the PIC18F14k50 build of FF 5.0. > > Some characters come down, well formed, then a delay, I send a carriage > return, and then more characters follow with zany formatting on the next > line of my terminal session. > > FF 3.8 formats perfectly on the same setup, so I guess my terminal > program(s) are ok. > > Just sharing, don't have a clue what's sideways. > > Best, > > Randy > > > > -----Original Message----- > From: Mark Goldman [mailto:bit...@gm...] > Sent: Wednesday, February 12, 2014 7:58 PM > To: fla...@li... > Subject: [Flashforth-devel] USB, flow-control, and linux > > Hello everyone, > > I am trying to run flashforth latest from GIT (appears to be 5.0, git commit > 304e4cc23851c7ff5bd6360f4c8c16b880a0d51c) > > I have an old USB BitWhacker board (v1) with an 18f2550 on it, 20MHz > crystal. > > I have made the adjustments to the frequency and divider to get USB working, > however when I connect via /dev/ttyACM0, it appears to send some, but not > all of the characters in the tx buffer. If I hit enter a couple of times, > or cause enough traffic, another chunk of the txbuffer comes down. > > I have setting hardware flow control, disabling idle_mode, and a couple of > other things, but I don't seem to get proper expected behavior. > > Are there other things I should be doing to enable USB besides defining > USB_CDC when assembling? > > I have tried searching the archives, but I didn't come up with anything. > > -mdg > > -- > Our problems are mostly behind us, now all we have to do is fight the > solutions. > > ---------------------------------------------------------------------------- > -- > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
|
From: Mark G. <bit...@gm...> - 2014-02-13 04:26:52
|
Hi Mikael, Is the system timer declared in MS_TMR? If so, it appears that in HEAD, MS_TMR is timer 2. -mdg On Wed, Feb 12, 2014 at 11:10 PM, Mikael Nordman <mik...@pp...> wrote: > Hi, > Try Timer2 as a system clock. > For some reason the timer1 and 3 does not work properly > with the 2 millisecond timeout for sending USB characters. > I did some "improvements" in 5.0 to timer 1 and 3 for better accuracy. > > I'll need to fix that. > > BR Mikael > > On 02/13/2014 03:09 AM, Randall Young wrote: >> Hi Mark, >> >> I'm seeing exactly the same thing, with the PIC18F14k50 build of FF 5.0. >> >> Some characters come down, well formed, then a delay, I send a carriage >> return, and then more characters follow with zany formatting on the next >> line of my terminal session. >> >> FF 3.8 formats perfectly on the same setup, so I guess my terminal >> program(s) are ok. >> >> Just sharing, don't have a clue what's sideways. >> >> Best, >> >> Randy >> >> >> >> -----Original Message----- >> From: Mark Goldman [mailto:bit...@gm...] >> Sent: Wednesday, February 12, 2014 7:58 PM >> To: fla...@li... >> Subject: [Flashforth-devel] USB, flow-control, and linux >> >> Hello everyone, >> >> I am trying to run flashforth latest from GIT (appears to be 5.0, git commit >> 304e4cc23851c7ff5bd6360f4c8c16b880a0d51c) >> >> I have an old USB BitWhacker board (v1) with an 18f2550 on it, 20MHz >> crystal. >> >> I have made the adjustments to the frequency and divider to get USB working, >> however when I connect via /dev/ttyACM0, it appears to send some, but not >> all of the characters in the tx buffer. If I hit enter a couple of times, >> or cause enough traffic, another chunk of the txbuffer comes down. >> >> I have setting hardware flow control, disabling idle_mode, and a couple of >> other things, but I don't seem to get proper expected behavior. >> >> Are there other things I should be doing to enable USB besides defining >> USB_CDC when assembling? >> >> I have tried searching the archives, but I didn't come up with anything. >> >> -mdg >> >> -- >> Our problems are mostly behind us, now all we have to do is fight the >> solutions. >> >> ---------------------------------------------------------------------------- >> -- >> Android apps run on BlackBerry 10 >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >> Now with support for Jelly Bean, Bluetooth, Mapview and more. >> Get your Android app in front of a whole new audience. Start now. >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> >> >> ------------------------------------------------------------------------------ >> Android apps run on BlackBerry 10 >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >> Now with support for Jelly Bean, Bluetooth, Mapview and more. >> Get your Android app in front of a whole new audience. Start now. >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- Our problems are mostly behind us, now all we have to do is fight the solutions. |
|
From: Mikael N. <mik...@pp...> - 2014-02-13 05:34:19
|
I just pushed a solution to the tmr1 and tm3 problem. At least my 14k50 chip works with this code and USB on Linux. The only problem is that Linux wants to send AT+CG... periodically. That corrupts the output until Linux stops polling the ttyACM line. BR Mikael On 02/13/2014 06:26 AM, Mark Goldman wrote: > Hi Mikael, > > Is the system timer declared in MS_TMR? If so, it appears that in > HEAD, MS_TMR is timer 2. > > -mdg > > On Wed, Feb 12, 2014 at 11:10 PM, Mikael Nordman > <mik...@pp...> wrote: >> Hi, >> Try Timer2 as a system clock. >> For some reason the timer1 and 3 does not work properly >> with the 2 millisecond timeout for sending USB characters. >> I did some "improvements" in 5.0 to timer 1 and 3 for better accuracy. >> >> I'll need to fix that. >> >> BR Mikael >> >> |
|
From: Mikael N. <mik...@pp...> - 2014-02-13 18:41:38
|
What about now. There was still the real bug left. I had commented out interrupt enable in WARM. That prevented the system clock from running and the TX0 send timeout did not work. BR On 02/13/2014 07:59 PM, Mark Goldman wrote: > > Still no joy on the 2550 on my dev board. > > I did a clean clone and adjusted the oscillator to match my 20Mhz > crystal. Same behavior as last night. > > -mdg > > On Feb 13, 2014 12:34 AM, "Mikael Nordman" <mik...@pp... > <mailto:mik...@pp...>> wrote: > > I just pushed a solution to the tmr1 and tm3 problem. > |
|
From: Mark G. <bit...@gm...> - 2014-02-13 18:53:06
|
That did the trick! Thank you. -mdg On Thu, Feb 13, 2014 at 1:41 PM, Mikael Nordman <mik...@pp...> wrote: > What about now. > There was still the real bug left. I had commented out interrupt enable > in WARM. > That prevented the system clock from running and the TX0 send timeout > did not work. > > BR > > On 02/13/2014 07:59 PM, Mark Goldman wrote: >> >> Still no joy on the 2550 on my dev board. >> >> I did a clean clone and adjusted the oscillator to match my 20Mhz >> crystal. Same behavior as last night. >> >> -mdg >> >> On Feb 13, 2014 12:34 AM, "Mikael Nordman" <mik...@pp... >> <mailto:mik...@pp...>> wrote: >> >> I just pushed a solution to the tmr1 and tm3 problem. >> > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- Our problems are mostly behind us, now all we have to do is fight the solutions. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X