Re: [Flashforth-devel] USB-UART bridge puzzle

[Tristan W. <ho...@tj...>]

Solved.

Puzzle the result of a self-inflicted hardware issue. Most likely
culprit, insufficient quality capacitance between Vusb3V3 and ground.

Thank you to all. 

Best wishes,
Tristan

On 21Nov21 09:32, Colin Tree wrote:
> Hi Tristan,
> 
> using a ch340 based usb<>serial, no buffer and doesn't need flow control
> 
> FTDI232 and cu with flow control
> 
> colin@treehome:~$ cu -f -l /dev/ttyUSB0 -s 1000000
> Connected.
> (cr)  ok
> ~.
> Disconnected.
> 
> with no flow control
> 
> colin@treehome:~$ cu -l /dev/ttyUSB0 -s 1000000
> Connected.
> (cr) ~.
> (cr) ~.
> (cr) ~.
> (cr) ~.
> (cr) ~.
> (cr) ~
> Disconnected.
> 
> so between the buffer and flow control ...
> 
> Colin
> 
> On 20/11/21 5:59 pm, Tristan Williams wrote:
> > Hello Mikael,
> > 
> > Thank you. I tried adding pause to the bridge word but to no
> > avail. Still no data received if the serial data is sent
> > infrequently. No data received after a good long wait. I have just
> > moved my winter project to the PIC18F25K50 (to get more flash storage)
> > from the PIC18F14K50. I didn't recall anything similar happening with
> > that chip, so I tried the bridge back on my PIC18F14K50 setup and - it
> > worked (without pause). It would seem to me that the two chips are
> > responding differently to what I think is the same code. A puzzle.
> > 
> > Best wishes,
> > Tristan
> > 
> > 
> > On 20Nov21 06:23, Mikael Nordman wrote:
> > > Hi,
> > > 
> > > TXU collects up to 8 characters before it sends the buffer to the
> > > USB line.
> > > 
> > > There is a timeout 2+TICK_TIME milliseconds to send the buffer if no
> > > data arrives to TXU. TICK_TIME is defined in the config file.
> > > 
> > > That timeout is handled by PAUSE.
> > > 
> > > So you should have seen data on the USB line after 8 seconds.
> > > If not then there is some other problem.
> > > 
> > > Try this
> > > 
> > > : bridge
> > >      u1-
> > >      begin
> > >          pause rx1? if rx1 txu then
> > >      again
> > > ;
> > > 
> > > BR Mikael
> > > 
> > > 
> > > On 2021-11-19 21:09, Tristan Williams wrote:
> > > > Hello,
> > > > 
> > > > I have a small mcu, sending serial data over its hardware uart
> > > > (38400-8N1) to the RX1 port of a PIC18F25K50 running FlashForth over
> > > > USB. I am trying to see/capture that serial data using FlashForth as a
> > > > USB-UART bridge
> > > > 
> > > > : bridge
> > > >      u1-
> > > >      begin
> > > >          rx1? if rx1 txu then
> > > >      again
> > > > ;
> > > > 
> > > > as per https://sourceforge.net/p/flashforth/wiki/USB-UART%20bridge/
> > > > 
> > > > If the serial data is sent as a continuous stream then it arrives as I
> > > > expect. If the data is subject to a delay in transmission - i.e. I put
> > > > a 1 second delay between each data byte, the data does not arrive. It
> > > > seems, perhaps, that the bridge has stalled in some way whilst waiting?
> > > > 
> > > > I hooked up a second usb-serial adaptor (FTDI) to the small mcu TX and
> > > > the delayed data is definitely there, arriving with a one second delay
> > > > between each data byte. If the data is streamed continuously, both the
> > > > bridge and the FTDI see it; if I introduce a delay, only the FTDI sees
> > > > it.
> > > > 
> > > > Any light on what I might be doing wrong would be very gratefully
> > > > received.
> > > > 
> > > > Best wishes,
> > > > 
> > > > Tristan
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Flashforth-devel mailing list
> > > > Fla...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> > > -- 
> > > --
> > > Mikael
> > > 
> > > 
> > > _______________________________________________
> > > Flashforth-devel mailing list
> > > Fla...@li...
> > > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> > > 
> > 
> > _______________________________________________
> > Flashforth-devel mailing list
> > Fla...@li...
> > https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> > 
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel