Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31284 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2022-11-01 22:28 -0700 |
| Last post | 2022-11-05 00:13 +0000 |
| Articles | 20 on this page of 94 — 10 participants |
Back to article view | Back to comp.arch.embedded
Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-01 22:28 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 10:28 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-02 11:54 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 14:27 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 12:20 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 21:49 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 16:27 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-03 12:42 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-03 14:00 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-03 16:26 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-04 08:45 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 10:49 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-04 15:37 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 17:36 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 10:11 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 11:58 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 09:55 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:00 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-07 15:46 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:05 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-07 19:02 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 17:15 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-08 06:54 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-08 05:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Clifford Heath <no_spam@please.net> - 2022-11-09 10:45 +1100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-08 16:46 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Clifford Heath <no_spam@please.net> - 2022-11-09 22:32 +1100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-09 04:53 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-09 23:45 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-09 21:42 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 08:40 -0700
Re: Shared Communications Bus - RS-422 or RS-485 antispam@math.uni.wroc.pl - 2022-11-04 22:53 +0000
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 18:07 -0700
Re: Shared Communications Bus - RS-422 or RS-485 antispam@math.uni.wroc.pl - 2022-11-05 03:46 +0000
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 02:09 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 10:40 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 12:47 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 10:23 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 19:57 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 13:42 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-06 11:55 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-06 05:56 -0800
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-06 21:53 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 01:58 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:26 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:39 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 12:07 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:25 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 17:57 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 09:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 21:30 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 14:27 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-08 00:07 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 16:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-08 09:02 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-08 06:58 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-06 18:34 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-06 15:37 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-06 19:18 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:07 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:03 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:55 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:18 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 18:20 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 10:26 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 22:04 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 14:54 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-07 15:14 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 16:57 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 07:51 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 08:29 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 10:36 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 12:32 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 13:08 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:40 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 16:50 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 21:10 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 11:13 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 08:52 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-04 20:03 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 17:25 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 11:01 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-02 15:00 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 16:31 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-02 17:36 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 21:58 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 09:57 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 12:02 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 12:53 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:33 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Dave Nadler <drn@nadler.com> - 2022-11-03 15:37 -0400
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:32 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-04 22:47 -0400
Re: Shared Communications Bus - RS-422 or RS-485 chris <chris-nospam@tridac.net> - 2022-11-05 00:13 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-06 11:55 +0100 |
| Message-ID | <tk83ql$32rij$1@dont-email.me> |
| In reply to | #31351 |
On 05/11/2022 21:42, Rick C wrote: > On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: >> On 05/11/2022 18:23, Rick C wrote: >>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: >> The USB device is /not/ a processor - it is a converter between USB and >> UART. And it is the USB device that controls the transmit enable signal >> to the RS-485/RS-422 driver. There is no software on any processor >> handling the transmit enable signal - the driver is enabled precisely >> when the USB to UART device is sending data on the UART. > > Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. > No, I think you are mixing things up. FTDI make a fair number of devices, including some that /are/ processors or contain processors. (That would their display controller devices, their USB host controllers, amongst others.) The code for using chips like the FT232H as a JTAG interface runs on the host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other software). The chip has /hardware/ support for a few different serial interfaces - SPI, I²C, JTAG and UART. >> As I mentioned earlier, this thread is getting seriously mixed-up. The >> transmit enable discussion started with /RS-485/ - long before you >> decided to use a hybrid bus and a RS-422 cable. You were concerned >> about how the PC controlled the transmitter enable for the RS-485 >> driver, and I have been trying to explain how this works when you use a >> decent UART device. You only confuse yourself when you jump to >> discussing RS-422 here, in this bit of the conversation. > > Ok, I'll stop talking about what I am doing. > We don't need to stop talking about it - we (everyone) just need to be a bit clearer about the context. It's been fun to talk about, and its great that you have a solution you are happy with, but it's a shame if topic mixup leads to frustration. >> All communications have failures. Accept that as a principle, and >> understand how to deal with it. It's not hard to do - it is certainly >> much easier than trying to imagine and eliminate any possible cause of >> trouble. > > That's not a premise I have to deal with. I will also die. I'm not factoring that into the project either. > > I don't need to eliminate "any possible cause of trouble". I only have to reach an effective level of reliability. As I've said, error handling protocols are complex and subject to failure. It's much more likely I will have more trouble with the error handling protocol than I will with bit errors on the bus. So I choose the most reliable solution, no error handling. So without an error handling protocol in the software, I don't need to do anything further to deal with errors. > I agree that error handling procedures can be difficult - and very often, they are poorly tested and have their own bugs (hardware or software). Over-engineering can reduce overall reliability, rather than increase it. (A few years back, we had a project that had to be updated to SIL safety certification requirements. Most of the changes reduced the overall safety and reliability in order to fulfil the documentation and certification requirements.) For serial protocols, ensuring a brief pause between telegrams is extremely simple and makes recovery possible after many kinds of errors. That's why it is found in virtually every serial protocol in wide use. And like it or not, you have it already in your hybrid bus solution.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-06 05:56 -0800 |
| Message-ID | <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com> |
| In reply to | #31353 |
On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote: > On 05/11/2022 21:42, Rick C wrote: > > On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: > >> On 05/11/2022 18:23, Rick C wrote: > >>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: > > >> The USB device is /not/ a processor - it is a converter between USB and > >> UART. And it is the USB device that controls the transmit enable signal > >> to the RS-485/RS-422 driver. There is no software on any processor > >> handling the transmit enable signal - the driver is enabled precisely > >> when the USB to UART device is sending data on the UART. > > > > Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. > > > No, I think you are mixing things up. FTDI make a fair number of > devices, including some that /are/ processors or contain processors. > (That would their display controller devices, their USB host > controllers, amongst others.) > > The code for using chips like the FT232H as a JTAG interface runs on the > host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other > software). The chip has /hardware/ support for a few different serial > interfaces - SPI, I²C, JTAG and UART. They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle. > >> As I mentioned earlier, this thread is getting seriously mixed-up. The > >> transmit enable discussion started with /RS-485/ - long before you > >> decided to use a hybrid bus and a RS-422 cable. You were concerned > >> about how the PC controlled the transmitter enable for the RS-485 > >> driver, and I have been trying to explain how this works when you use a > >> decent UART device. You only confuse yourself when you jump to > >> discussing RS-422 here, in this bit of the conversation. > > > > Ok, I'll stop talking about what I am doing. > > > We don't need to stop talking about it - we (everyone) just need to be a > bit clearer about the context. It's been fun to talk about, and its > great that you have a solution you are happy with, but it's a shame if > topic mixup leads to frustration. > >> All communications have failures. Accept that as a principle, and > >> understand how to deal with it. It's not hard to do - it is certainly > >> much easier than trying to imagine and eliminate any possible cause of > >> trouble. > > > > That's not a premise I have to deal with. I will also die. I'm not factoring that into the project either. > > > > I don't need to eliminate "any possible cause of trouble". I only have to reach an effective level of reliability. As I've said, error handling protocols are complex and subject to failure. It's much more likely I will have more trouble with the error handling protocol than I will with bit errors on the bus. So I choose the most reliable solution, no error handling. So without an error handling protocol in the software, I don't need to do anything further to deal with errors. > > > I agree that error handling procedures can be difficult - and very > often, they are poorly tested and have their own bugs (hardware or > software). Over-engineering can reduce overall reliability, rather than > increase it. (A few years back, we had a project that had to be updated > to SIL safety certification requirements. Most of the changes reduced > the overall safety and reliability in order to fulfil the documentation > and certification requirements.) > > For serial protocols, ensuring a brief pause between telegrams is > extremely simple and makes recovery possible after many kinds of errors. > That's why it is found in virtually every serial protocol in wide use. > And like it or not, you have it already in your hybrid bus solution. There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. -- Rick C. -+-+ Get 1,000 miles of free Supercharging -+-+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-06 21:53 +0100 |
| Message-ID | <tk96t7$3abv7$2@dont-email.me> |
| In reply to | #31354 |
On 06/11/2022 14:56, Rick C wrote: > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote: >> On 05/11/2022 21:42, Rick C wrote: >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: >>>> On 05/11/2022 18:23, Rick C wrote: >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: >> >>>> The USB device is /not/ a processor - it is a converter between USB and >>>> UART. And it is the USB device that controls the transmit enable signal >>>> to the RS-485/RS-422 driver. There is no software on any processor >>>> handling the transmit enable signal - the driver is enabled precisely >>>> when the USB to UART device is sending data on the UART. >>> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. >>> >> No, I think you are mixing things up. FTDI make a fair number of >> devices, including some that /are/ processors or contain processors. >> (That would their display controller devices, their USB host >> controllers, amongst others.) >> >> The code for using chips like the FT232H as a JTAG interface runs on the >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other >> software). The chip has /hardware/ support for a few different serial >> interfaces - SPI, I²C, JTAG and UART. > > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle. > There is no reason to think that they /do/ have a processor there. I should imagine you would have no problem making the programmable logic needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave devices are rarely made in software (even on the XMOS they prefer hardware blocks for USB). Why would anyone use a /processor/ for some simple digital hardware? I am not privy to the details of the FTDI design beyond their published documents, but it seems pretty clear to me that there is no processor in sight. > >>>> As I mentioned earlier, this thread is getting seriously mixed-up. The >>>> transmit enable discussion started with /RS-485/ - long before you >>>> decided to use a hybrid bus and a RS-422 cable. You were concerned >>>> about how the PC controlled the transmitter enable for the RS-485 >>>> driver, and I have been trying to explain how this works when you use a >>>> decent UART device. You only confuse yourself when you jump to >>>> discussing RS-422 here, in this bit of the conversation. >>> >>> Ok, I'll stop talking about what I am doing. >>> >> We don't need to stop talking about it - we (everyone) just need to be a >> bit clearer about the context. It's been fun to talk about, and its >> great that you have a solution you are happy with, but it's a shame if >> topic mixup leads to frustration. >>>> All communications have failures. Accept that as a principle, and >>>> understand how to deal with it. It's not hard to do - it is certainly >>>> much easier than trying to imagine and eliminate any possible cause of >>>> trouble. >>> >>> That's not a premise I have to deal with. I will also die. I'm not factoring that into the project either. >>> >>> I don't need to eliminate "any possible cause of trouble". I only have to reach an effective level of reliability. As I've said, error handling protocols are complex and subject to failure. It's much more likely I will have more trouble with the error handling protocol than I will with bit errors on the bus. So I choose the most reliable solution, no error handling. So without an error handling protocol in the software, I don't need to do anything further to deal with errors. >>> >> I agree that error handling procedures can be difficult - and very >> often, they are poorly tested and have their own bugs (hardware or >> software). Over-engineering can reduce overall reliability, rather than >> increase it. (A few years back, we had a project that had to be updated >> to SIL safety certification requirements. Most of the changes reduced >> the overall safety and reliability in order to fulfil the documentation >> and certification requirements.) >> >> For serial protocols, ensuring a brief pause between telegrams is >> extremely simple and makes recovery possible after many kinds of errors. >> That's why it is found in virtually every serial protocol in wide use. >> And like it or not, you have it already in your hybrid bus solution. > > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. > That is one way to handle possible errors.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 01:58 -0800 |
| Message-ID | <bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com> |
| In reply to | #31355 |
On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote: > On 06/11/2022 14:56, Rick C wrote: > > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote: > >> On 05/11/2022 21:42, Rick C wrote: > >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: > >>>> On 05/11/2022 18:23, Rick C wrote: > >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: > >> > >>>> The USB device is /not/ a processor - it is a converter between USB and > >>>> UART. And it is the USB device that controls the transmit enable signal > >>>> to the RS-485/RS-422 driver. There is no software on any processor > >>>> handling the transmit enable signal - the driver is enabled precisely > >>>> when the USB to UART device is sending data on the UART. > >>> > >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. > >>> > >> No, I think you are mixing things up. FTDI make a fair number of > >> devices, including some that /are/ processors or contain processors. > >> (That would their display controller devices, their USB host > >> controllers, amongst others.) > >> > >> The code for using chips like the FT232H as a JTAG interface runs on the > >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other > >> software). The chip has /hardware/ support for a few different serial > >> interfaces - SPI, I²C, JTAG and UART. > > > > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle. > > > There is no reason to think that they /do/ have a processor there. I > should imagine you would have no problem making the programmable logic > needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave > devices are rarely made in software (even on the XMOS they prefer > hardware blocks for USB). Why would anyone use a /processor/ for some > simple digital hardware? I am not privy to the details of the FTDI > design beyond their published documents, but it seems pretty clear to me > that there is no processor in sight. I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store. -- Rick C. -++- Get 1,000 miles of free Supercharging -++- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 11:26 +0100 |
| Message-ID | <nnd$4bad0da4$14a9e7ec@210656c28878494e> |
| In reply to | #31360 |
On 2022-11-07 Rick C wrote in comp.arch.embedded: > On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote: >> On 06/11/2022 14:56, Rick C wrote: >> > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote: >> >> On 05/11/2022 21:42, Rick C wrote: >> >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: >> >>>> On 05/11/2022 18:23, Rick C wrote: >> >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: >> >> >> >>>> The USB device is /not/ a processor - it is a converter between USB and >> >>>> UART. And it is the USB device that controls the transmit enable signal >> >>>> to the RS-485/RS-422 driver. There is no software on any processor >> >>>> handling the transmit enable signal - the driver is enabled precisely >> >>>> when the USB to UART device is sending data on the UART. >> >>> >> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. >> >>> >> >> No, I think you are mixing things up. FTDI make a fair number of >> >> devices, including some that /are/ processors or contain processors. >> >> (That would their display controller devices, their USB host >> >> controllers, amongst others.) >> >> >> >> The code for using chips like the FT232H as a JTAG interface runs on the >> >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other >> >> software). The chip has /hardware/ support for a few different serial >> >> interfaces - SPI, I²C, JTAG and UART. >> > >> > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle. >> > >> There is no reason to think that they /do/ have a processor there. I >> should imagine you would have no problem making the programmable logic >> needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave >> devices are rarely made in software (even on the XMOS they prefer >> hardware blocks for USB). Why would anyone use a /processor/ for some >> simple digital hardware? I am not privy to the details of the FTDI >> design beyond their published documents, but it seems pretty clear to me >> that there is no processor in sight. > > I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store. Why are you discussing this? Out of academic curiosity? Then please continue. But what does it matter for your system implementation? There is just a UART/SPI/I²C/JTAG/GPIO peripheral and your software won't care how this peripheral is implemented, as long as it behaves as expected. -- Stef "Microwave oven? Whaddya mean, it's a microwave oven? I've been watching Channel 4 on the thing for two weeks."
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 02:39 -0800 |
| Message-ID | <54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com> |
| In reply to | #31364 |
On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote: > >> On 06/11/2022 14:56, Rick C wrote: > >> > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote: > >> >> On 05/11/2022 21:42, Rick C wrote: > >> >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: > >> >>>> On 05/11/2022 18:23, Rick C wrote: > >> >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: > >> >> > >> >>>> The USB device is /not/ a processor - it is a converter between USB and > >> >>>> UART. And it is the USB device that controls the transmit enable signal > >> >>>> to the RS-485/RS-422 driver. There is no software on any processor > >> >>>> handling the transmit enable signal - the driver is enabled precisely > >> >>>> when the USB to UART device is sending data on the UART. > >> >>> > >> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. > >> >>> > >> >> No, I think you are mixing things up. FTDI make a fair number of > >> >> devices, including some that /are/ processors or contain processors. > >> >> (That would their display controller devices, their USB host > >> >> controllers, amongst others.) > >> >> > >> >> The code for using chips like the FT232H as a JTAG interface runs on the > >> >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other > >> >> software). The chip has /hardware/ support for a few different serial > >> >> interfaces - SPI, I²C, JTAG and UART. > >> > > >> > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle. > >> > > >> There is no reason to think that they /do/ have a processor there. I > >> should imagine you would have no problem making the programmable logic > >> needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave > >> devices are rarely made in software (even on the XMOS they prefer > >> hardware blocks for USB). Why would anyone use a /processor/ for some > >> simple digital hardware? I am not privy to the details of the FTDI > >> design beyond their published documents, but it seems pretty clear to me > >> that there is no processor in sight. > > > > I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store. > Why are you discussing this? Out of academic curiosity? Then please > continue. But what does it matter for your system implementation? There > is just a UART/SPI/I²C/JTAG/GPIO peripheral and your software won't care > how this peripheral is implemented, as long as it behaves as expected. I care. Don't you? I remember when I came to the realization of why an MCU was so cost effective compared to programmable or even dedicated logic. It's because the MCU program is a FSM, using the instructions stored in the memory. These instruction are essentially logic, which is connected through the CPU logic, creating a very low cost solution to a wide variety of problems, because of the very low cost of memory compared to dedicated or programmable logic. -- Rick C. +--+ Get 1,000 miles of free Supercharging +--+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 12:07 +0100 |
| Message-ID | <nnd$365bd2e6$24582938@34ecb23b658f2b03> |
| In reply to | #31365 |
On 2022-11-07 Rick C wrote in comp.arch.embedded: > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote: >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> > On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote: >> >> On 06/11/2022 14:56, Rick C wrote: >> >> > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote: >> >> >> On 05/11/2022 21:42, Rick C wrote: >> >> >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: >> >> >>>> On 05/11/2022 18:23, Rick C wrote: >> >> >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: >> >> >> >> >> >>>> The USB device is /not/ a processor - it is a converter between USB and >> >> >>>> UART. And it is the USB device that controls the transmit enable signal >> >> >>>> to the RS-485/RS-422 driver. There is no software on any processor >> >> >>>> handling the transmit enable signal - the driver is enabled precisely >> >> >>>> when the USB to UART device is sending data on the UART. >> >> >>> >> >> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. >> >> >>> >> >> >> No, I think you are mixing things up. FTDI make a fair number of >> >> >> devices, including some that /are/ processors or contain processors. >> >> >> (That would their display controller devices, their USB host >> >> >> controllers, amongst others.) >> >> >> >> >> >> The code for using chips like the FT232H as a JTAG interface runs on the >> >> >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other >> >> >> software). The chip has /hardware/ support for a few different serial >> >> >> interfaces - SPI, I²C, JTAG and UART. >> >> > >> >> > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle. >> >> > >> >> There is no reason to think that they /do/ have a processor there. I >> >> should imagine you would have no problem making the programmable logic >> >> needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave >> >> devices are rarely made in software (even on the XMOS they prefer >> >> hardware blocks for USB). Why would anyone use a /processor/ for some >> >> simple digital hardware? I am not privy to the details of the FTDI >> >> design beyond their published documents, but it seems pretty clear to me >> >> that there is no processor in sight. >> > >> > I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store. >> Why are you discussing this? Out of academic curiosity? Then please >> continue. But what does it matter for your system implementation? There >> is just a UART/SPI/I²C/JTAG/GPIO peripheral and your software won't care >> how this peripheral is implemented, as long as it behaves as expected. > > I care. Don't you? No, I don't. We do use FTDI chips in our designs to interface a serial port to USB. And we also use ready made FTDI cables. We use these chips and cables based on their specifications in datasheets and user guides etc. I have never felt the need to invesitigate how the UART/USB functionality was actually implemented inside the chip. What would I do with this knowledge? In a design I must rely on the behaviour as specified in the datasheet. > I remember when I came to the realization of why an MCU was so cost effective compared to programmable or even dedicated logic. It's because the MCU program is a FSM, using the instructions stored in the memory. These instruction are essentially logic, which is connected through the CPU logic, creating a very low cost solution to a wide variety of problems, because of the very low cost of memory compared to dedicated or programmable logic. > This is what I would call 'academic interest', and that is perfectly fine. And this knowledge might help you think differently about solving a problem in your own design. But it will make no difference in how you will imlement this chip (or cable) in your design. -- Stef So many men, so many opinions; every one his own way. -- Publius Terentius Afer (Terence)
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 08:25 -0800 |
| Message-ID | <4df2d2d6-d520-439b-8504-4912f553351bn@googlegroups.com> |
| In reply to | #31367 |
On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote: > >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > > > > I care. Don't you? > No, I don't. We do use FTDI chips in our designs to interface a serial > port to USB. And we also use ready made FTDI cables. We use these chips > and cables based on their specifications in datasheets and user guides > etc. I have never felt the need to invesitigate how the UART/USB > functionality was actually implemented inside the chip. What would I do > with this knowledge? In a design I must rely on the behaviour as > specified in the datasheet. It's hard to imagine an engineer with no curiosity. > > I remember when I came to the realization of why an MCU was so cost effective compared to programmable or even dedicated logic. It's because the MCU program is a FSM, using the instructions stored in the memory. These instruction are essentially logic, which is connected through the CPU logic, creating a very low cost solution to a wide variety of problems, because of the very low cost of memory compared to dedicated or programmable logic. > > > This is what I would call 'academic interest', and that is perfectly > fine. And this knowledge might help you think differently about solving > a problem in your own design. But it will make no difference in how you > will imlement this chip (or cable) in your design. It is very much of practical interest to me, as I design FPGAs and knowing that I can use less resources by constructing a peripheral as a CPU, is important info. The FPGA design in the UUT was pushing the capacity of the chip it was in. I was on the cusp of changing the design to a CPU centric design when it was routed at 90% utilization. This time, I'm bumping the size of the FPGA significantly, about 3x. The Gowin FPGA devices are very cost effective. I'll be able to use the hard logic and the soft CPU, both. LOL -- Rick C. ++-+ Get 1,000 miles of free Supercharging ++-+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 17:57 +0100 |
| Message-ID | <nnd$437d2a7f$076c08cf@1f746f18e05c17f1> |
| In reply to | #31372 |
On 2022-11-07 Rick C wrote in comp.arch.embedded: > On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote: >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote: >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> > >> > I care. Don't you? >> No, I don't. We do use FTDI chips in our designs to interface a serial >> port to USB. And we also use ready made FTDI cables. We use these chips >> and cables based on their specifications in datasheets and user guides >> etc. I have never felt the need to invesitigate how the UART/USB >> functionality was actually implemented inside the chip. What would I do >> with this knowledge? In a design I must rely on the behaviour as >> specified in the datasheet. > > It's hard to imagine an engineer with no curiosity. Yes, that's hard. But imagining an engineer who does not care about the internal structure of every single chip he uses is a lot easier (for me). I tend to focus my curiiosity on things that matter to me, don't you? -- Stef One difference between a man and a machine is that a machine is quiet when well oiled.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 09:50 -0800 |
| Message-ID | <f8930684-c183-4270-ba6c-4a64adfd11a6n@googlegroups.com> |
| In reply to | #31373 |
On Monday, November 7, 2022 at 12:57:27 PM UTC-4, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote: > >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote: > >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> > > >> > I care. Don't you? > >> No, I don't. We do use FTDI chips in our designs to interface a serial > >> port to USB. And we also use ready made FTDI cables. We use these chips > >> and cables based on their specifications in datasheets and user guides > >> etc. I have never felt the need to invesitigate how the UART/USB > >> functionality was actually implemented inside the chip. What would I do > >> with this knowledge? In a design I must rely on the behaviour as > >> specified in the datasheet. > > > > It's hard to imagine an engineer with no curiosity. > Yes, that's hard. But imagining an engineer who does not care about the > internal structure of every single chip he uses is a lot easier (for > me). I tend to focus my curiiosity on things that matter to me, don't > you? By definition curiosity is, "an eager desire to know or learn about something". That's not limited to things I *need* to know about. In fact, I don't limit my curiosity at all. It's a desire, not an act. The knowledge can be very useful, if it opens new ideas for how to use these devices. In fact, I found that the majority of FTDI cables are full speed, which is much more limiting that the few Hi-speed USB cables they make. The Hi-speed cables seem to handle a lot more protocols. So now I'm back to wondering if they are implemented in a CPU based design. -- Rick C. +++- Get 1,000 miles of free Supercharging +++- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 21:30 +0100 |
| Message-ID | <nnd$47f3affc$02cb14ae@0b1845cd201d6465> |
| In reply to | #31375 |
On 2022-11-07 Rick C wrote in comp.arch.embedded: > On Monday, November 7, 2022 at 12:57:27 PM UTC-4, Stef wrote: >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> > On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote: >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> >> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote: >> >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> >> > >> >> > I care. Don't you? >> >> No, I don't. We do use FTDI chips in our designs to interface a serial >> >> port to USB. And we also use ready made FTDI cables. We use these chips >> >> and cables based on their specifications in datasheets and user guides >> >> etc. I have never felt the need to invesitigate how the UART/USB >> >> functionality was actually implemented inside the chip. What would I do >> >> with this knowledge? In a design I must rely on the behaviour as >> >> specified in the datasheet. >> > >> > It's hard to imagine an engineer with no curiosity. >> Yes, that's hard. But imagining an engineer who does not care about the >> internal structure of every single chip he uses is a lot easier (for >> me). I tend to focus my curiiosity on things that matter to me, don't >> you? > > By definition curiosity is, "an eager desire to know or learn about something". That's not limited to things I *need* to know about. In fact, I don't limit my curiosity at all. It's a desire, not an act. > Learn about something != learn about everything Matter to me != *need* to know about My not caring abbout the innards of a particular chip seems to let you think I don't care about anything. But we are not discussing my interests here, but your bus. -- Stef Old age is the most unexpected of things that can happen to a man. -- Trotsky
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 14:27 -0800 |
| Message-ID | <bc6d4cce-41f2-4522-9bf2-81a13d01dbfbn@googlegroups.com> |
| In reply to | #31377 |
On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Monday, November 7, 2022 at 12:57:27 PM UTC-4, Stef wrote: > >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> > On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote: > >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> >> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote: > >> >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> >> > > >> >> > I care. Don't you? > >> >> No, I don't. We do use FTDI chips in our designs to interface a serial > >> >> port to USB. And we also use ready made FTDI cables. We use these chips > >> >> and cables based on their specifications in datasheets and user guides > >> >> etc. I have never felt the need to invesitigate how the UART/USB > >> >> functionality was actually implemented inside the chip. What would I do > >> >> with this knowledge? In a design I must rely on the behaviour as > >> >> specified in the datasheet. > >> > > >> > It's hard to imagine an engineer with no curiosity. > >> Yes, that's hard. But imagining an engineer who does not care about the > >> internal structure of every single chip he uses is a lot easier (for > >> me). I tend to focus my curiiosity on things that matter to me, don't > >> you? > > > > By definition curiosity is, "an eager desire to know or learn about something". That's not limited to things I *need* to know about. In fact, I don't limit my curiosity at all. It's a desire, not an act. > > > Learn about something != learn about everything > Matter to me != *need* to know about > > My not caring abbout the innards of a particular chip seems to let you > think I don't care about anything. But we are not discussing my > interests here, but your bus. Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts. -- Rick C. ----- Get 1,000 miles of free Supercharging ----- Tesla referral code - https://ts.la/richard1120
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-08 00:07 +0100 |
| Message-ID | <nnd$7332a844$70e2176a@437989d81322ea50> |
| In reply to | #31379 |
On 2022-11-07 Rick C wrote in comp.arch.embedded: > On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote: ... >> My not caring abbout the innards of a particular chip seems to let you >> think I don't care about anything. But we are not discussing my >> interests here, but your bus. > > Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts. That was not my intention. It seemed to me that you cared about the internal implementation of the FTDI chip in relation to your bus problem. I just wanted to point out that is of no concern for your bus operation. And then I just got dragged in. ;-) -- Stef He's the kind of guy, that, well, if you were ever in a jam he'd be there... with two slices of bread and some chunky peanut butter.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 16:50 -0800 |
| Message-ID | <af41646a-9c95-4ae7-8e9b-b4fe8b781e4cn@googlegroups.com> |
| In reply to | #31381 |
On Monday, November 7, 2022 at 7:07:50 PM UTC-4, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote: > ... > >> My not caring abbout the innards of a particular chip seems to let you > >> think I don't care about anything. But we are not discussing my > >> interests here, but your bus. > > > > Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts. > That was not my intention. It seemed to me that you cared about the > internal implementation of the FTDI chip in relation to your bus > problem. I just wanted to point out that is of no concern for your bus > operation. And then I just got dragged in. ;-) I'm always curious about how things are implemented. I thought I had heard somewhere that the FTDI chip was a fast, but small processor. I design those for use in FPGA designs and they can be very effective. Often the code is very minimal. -- Rick C. ---+- Get 1,000 miles of free Supercharging ---+- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-08 09:02 +0100 |
| Message-ID | <tkd2eo$3s5av$1@dont-email.me> |
| In reply to | #31384 |
On 08/11/2022 01:50, Rick C wrote: > On Monday, November 7, 2022 at 7:07:50 PM UTC-4, Stef wrote: >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >>> On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote: >> ... >>>> My not caring abbout the innards of a particular chip seems to >>>> let you think I don't care about anything. But we are not >>>> discussing my interests here, but your bus. >>> >>> Seems to me you wanted to talk about my interests when you said, >>> "Why are you discussing this?" and then continued discussing that >>> issue for some half dozen more posts. >> That was not my intention. It seemed to me that you cared about >> the internal implementation of the FTDI chip in relation to your >> bus problem. I just wanted to point out that is of no concern for >> your bus operation. And then I just got dragged in. ;-) > > I'm always curious about how things are implemented. I thought I had > heard somewhere that the FTDI chip was a fast, but small processor. > I design those for use in FPGA designs and they can be very > effective. Often the code is very minimal. > There's nothing wrong with curiosity. However, I have no doubt that you heard wrong, or heard about different FTDI devices, or that your source heard wrong. FTDI have been making these things for a couple of decades, since the earliest days of USB. You can be sure they are hardware peripherals, not software. For /you/, and /your/ designs in FPGAs, adding a small processor can be a good solution. The balance is different for ASICs and for dedicated silicon, and it is different now than it was when FTDI made their MPSE block for use in their devices. Really, we are not talking about a peripheral that is much more advanced than common serial communication blocks. It multiplexes a UART, an SPI and an I²C on the same pins. That's it. You don't bother with a processor and software for that. FTDI /do/ make devices using embedded processors, with a few different types (I forget which - perhaps Tensila cores). But those are other chips.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-08 06:58 -0500 |
| Message-ID | <BvraL.2595$Z3L9.1067@fx41.iad> |
| In reply to | #31384 |
On 11/7/22 7:50 PM, Rick C wrote: > On Monday, November 7, 2022 at 7:07:50 PM UTC-4, Stef wrote: >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >>> On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote: >> ... >>>> My not caring abbout the innards of a particular chip seems to let you >>>> think I don't care about anything. But we are not discussing my >>>> interests here, but your bus. >>> >>> Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts. >> That was not my intention. It seemed to me that you cared about the >> internal implementation of the FTDI chip in relation to your bus >> problem. I just wanted to point out that is of no concern for your bus >> operation. And then I just got dragged in. ;-) > > I'm always curious about how things are implemented. I thought I had heard somewhere that the FTDI chip was a fast, but small processor. I design those for use in FPGA designs and they can be very effective. Often the code is very minimal. > The key is that if it is specified to have a quick Disable at end of transimition capability, then you can count on that, and not say it is up to the speed of the program to turn of the transmitter. Sometimes we hit a blurry line between what is really a general purpose computer and what is a FSM doing an operation. Ultimately, we need to look at the specifications of performance to decide what we need to do.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-06 18:34 -0500 |
| Message-ID | <xwX9L.33736$TUR8.17072@fx17.iad> |
| In reply to | #31354 |
On 11/6/22 8:56 AM, Rick C wrote: > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. If the only way to handle a missed message is to abort the whole software system, that seems to be a pretty bad system. Note, if the master sends out a message, and waits for a response, with a retry if the message is not replied to, that naturally puts a pause in the communication bus for inter-message synchronization. Based on your description, I can't imagine the master starting a message for another slave until after the first one answers, or you will interfere with the arbitration control of the reply bus. In a dedicated link, after the link is established, it might be possible that one side just starts streaming data continously to the other side, but most protocals will have some sort of at least occational handshaking back, so a loss of sync can stop the flow to re-establish the syncronization. And such handshaking is needed if you have need to handle noise in packets.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-06 15:37 -0800 |
| Message-ID | <87v8nr1wp6.fsf@nightsong.com> |
| In reply to | #31356 |
Richard Damon <Richard@Damon-Family.org> writes: > And such handshaking is needed if you have need to handle noise in > packets. Once you acknowledge that noise and errors are even possible, some kind of checksums or FEC seem appropriate in addition to a retry protocol.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-06 19:18 -0500 |
| Message-ID | <P9Y9L.71047$2Rs3.50835@fx12.iad> |
| In reply to | #31357 |
On 11/6/22 6:37 PM, Paul Rubin wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> And such handshaking is needed if you have need to handle noise in >> packets. > > Once you acknowledge that noise and errors are even possible, some kind > of checksums or FEC seem appropriate in addition to a retry protocol. Yes, the messages should have some form of checksum in them to identify bad packets. That should be part of the message definition.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 02:07 -0800 |
| Message-ID | <7dfde881-da25-4408-960a-cee283481ab9n@googlegroups.com> |
| In reply to | #31358 |
On Sunday, November 6, 2022 at 7:19:00 PM UTC-5, Richard Damon wrote: > On 11/6/22 6:37 PM, Paul Rubin wrote: > > Richard Damon <Ric...@Damon-Family.org> writes: > >> And such handshaking is needed if you have need to handle noise in > >> packets. > > > > Once you acknowledge that noise and errors are even possible, some kind > > of checksums or FEC seem appropriate in addition to a retry protocol. > Yes, the messages should have some form of checksum in them to identify > bad packets. That should be part of the message definition. Why? Does the processor checksum every value calculated and stored in memory? Not on my computer. This is not warranted because the data failure rate is very low. Same with an RS-422 bus in an electrically quiet environment. I could probably get away with TTL level signals, but I'd like to have the ESD protection these RS-422 chips give. That additional noise immunity means there is an extremely small chance of bit errors. If we have problems, the error handling can be added. -- Rick C. +--- Get 1,000 miles of free Supercharging +--- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web