01:11 <mewt> Yeah I dunno, lack of full documentation is a dealbreaker and I know BBBs have generally good support by now

01:12 <mewt> Don't need so much power really

01:19 <zmatt> "full documentation" ? the rpi4 SoC doesn't even have a product page, or any evidence on broadcom's website that the SoC even exists: https://www.google.com/search?q=BCM2711+site%3Abroadcom.com&hl=en&tbs=li:1

01:22 <zmatt> but yeah, the 164-page document from the rpi foundation is obviously nothing compared to the thousands of pages of TI docs

01:26 <zmatt> wait wtf, the rpi4 SoC has the same data ordering bug that the original rpi soc had? they still haven't solved that problem?!? duuude

01:30 <zmatt> (performing a reads from a peripherals while a read from another peripheral is in progress can cause the data from those reads to get swapped)

01:30 <zmatt> *a read from a peripheral

14:37 <Guest32> Someone  knows where I can find a driver for spi communication?

21:23 <johanhenselmans> Anyone having RS485 running with MAX13487? I have a hard time getting it to work. UART1 (p9.24 and p9.26) connected to DI and RO, D+ and D- to a USB RS485 connector on a linux box, on side doing screen /dev/ttyUSB0 9600,E,8,1, other side a small python script. I can see on my scope that the traffic is coming to the MAX, but somehow it does not get through to the other side. I am at loss. I once seemed to have a connection, but now it seems

21:23 <johanhenselmans> completely dead. I noticed in a message of zmatt (https://groups.google.com/g/beagleboard/c/_DfLM_XBb7I/m/y83pU-poCwAJ), that using config-pin does not go together with uboot_overlays. Is that correct? Should I comment “disable_uboot_overlay_video=1” etc even if I do not want to use video, or adc and audio?

21:24 <johanhenselmans> (4.19.94-ti-rt-r68 #1buster)

21:25 <zmatt> uhh, those variables have nothing to do with what I said there

21:25 <zmatt> disabling video/audio via those variables is required to use those pins regardless of whether you do so using an overlay or using cape-universal/config-pin

21:26 <zmatt> I also never said "config-pin does not go together with uboot_overlays", in fact cape-universal (which enables the use of config-pin) is itself an overlay

21:27 <johanhenselmans> Ah, misunderstanding then. What did you mean there with “No cape overlay is loaded (as a result of cape autodetection or by setting one of the uboot_overlay-variables in /boot/uEnv.txt)”

21:28 <johanhenselmans> for the prerequisites to use config-pin?

21:29 <zmatt> hmm, I presumably meant to say "No cape overlay is loaded... that uses those pins" but forgot to write that last bit

21:30 <johanhenselmans> I understood that “disable_uboot_overlay_video=1” would be a uboot-overlay-variable.

21:30 <zmatt> no

21:31 <zmatt> I meant uboot_overlay_addr4 etc

21:31 <johanhenselmans> Ah, OK. So disable_uboot_overlay_ will not interfere with config-pin. Good. On to the next problem.

21:32 <zmatt> or well, the disable_uboot_overlay_* variables matter too in the sense that if you want to use pins occupied by e.g. the hdmi overlay, you'll need to disable that overlay by uncommenting disable_uboot_overlay_video=1

21:34 <zmatt> if a pin is in use by any overlay, config-pin will fail for that pin (with "No such file or directory")

21:36 <zmatt> so you're not receiving anything? is the nRE input to the MAX13487E (pin 2) high?

21:38 <zmatt> both DI and nRE need to be high to be enable to receive anything

21:39 <johanhenselmans> OK. It seems that I need a pin to do a RE signal for RS485, which should switch the MAX13487 from sending to receiving (although it should function automatically), I tried to define that pin in a sample python program i found, but I did not see the pin (p9.15, known as GPIO48) give any signal to change from sending to receiving.

21:39 <zmatt> nRE does not affect transmission, you can keep it high all the time

21:40 <johanhenselmans> Found that program here: https://gist.github.com/Bouni/49a292798e88a7a0956c308b3c9d1190

21:40 <zmatt> uhhh

21:40 <zmatt> also

21:41 <zmatt> the MAX13487E uses 5V I/O and cannot be connected directly to the BBB

21:42 <zmatt> (or if you have been, you may have damaged the BBB)

21:44 <zmatt> the kernel's RS485 mode is not needed/relevant for an RS485 transceiver with auto-direction control

21:45 <zmatt> also the python code you linked to is for old kernels

21:46 <zmatt> (and there's no reason to manually do that ioctl, pyserial has nice methods for it)

21:48 <zmatt> anyway, step 1 is to either get a different transceiver that uses 3.3V I/O or use a level shifter between the BBB and the MAX13487E, and pray you haven't already destroyed the P9.26 I/O cell

21:49 <johanhenselmans> F*ck, misunderstood the datasheet. I thought that 5V VCC was only used for the communication side to D+ and D-, and that DI and RO would be 3.3V. OK, so I need a 3.3V to 5V logic level shifter?

21:51 <zmatt> it looks like it will accept a 3.3V on its DI input (since VIH = 2V)

21:52 <zmatt> and it says it tolerates continuous short-circuit on RO, so you could use a resistor to ground to lower the RO voltage to 3.0-3.3V or so

21:52 <johanhenselmans> Any recommendations for a 3.3V RS485 tranceiver?

21:53 <zmatt> I mean, that's very much dependent on your needs, RS485 transceivers come in all sorts of specs and variations

21:53 <zmatt> availablility may also be an important factor, especially these days

21:56 <zmatt> rs485 transceivers vary in robustness/protection, bandwidth and slew-limiting, supply voltage, termination, direction control (manual or automatic), probably more things I missed

21:58 <johanhenselmans> I chose the 13487 because of the high avaiability at Mouser and Farnell and the simple configuration. I’ll have a look if they have a comparable 3.3V version.

21:59 <zmatt> ah, the datasheet actually has a V/I diagram for the RO output when high, middle graph on the top row under Typical Operating Characteristics (page 5)

22:01 <zmatt> looks like to pull it down to 3.3V would require.. 22-23 mA or so? so that would require a 140-150 Ω resistor to ground and dissipate 0.47-0.5 W into that resistor... not ideal

22:02 <zmatt> so yeah, finding a transceiver with 3.3V I/O would be better if possible

22:03 <zmatt> also, I'd suggest doing a test of P9.26 in gpio mode to check if it's okay... e.g. use config-pin to switch it betweem gpio_pd and gpio_pu and confirm the gpio input reads as low and high respectively

22:03 <zmatt> (with nothing connected)

22:05 <johanhenselmans> I see, but I don’t understand. What does this mean? That, if the current is less than 21 mA, the Voltage would be above 3.3V?

22:05 <zmatt> yes, since the RO output, when high, is 5V if you don't pull any current from it, but if you draw connect from an output it will start to sag down

22:05 <johanhenselmans> Ah, you were already stating what I tried to understand. Fair enough.

22:08 <zmatt> until either some kind of limiting happens or the output is destroyed... in this case the datasheet says it tolerates indefinite short-circuit (0V output) with the output current limited to max 95 mA.... although that would dissipate a lot of energy in the MAX13487E and that will exceed its thermal limits probably

22:11 <zmatt> wait I miscalculated the power... it's only 73-76 mW into the resistor (3.3V * 22-23 mA)

22:12 <johanhenselmans> That sounds better.

22:12 <zmatt> and 37-39 mW of heat in the transceiver

22:15 <zmatt> you could also use a resistor divider to lower the voltage without drawing as much current from the transceiver

22:18 <zmatt> .. which is actually a much better idea, and I'm not sure why it wasn't my first suggestion (apart from getting a more suitable transceiver)

22:18 <johanhenselmans> I’d prefer 1 component. As somebody said: less components means less chanches of a component breaking down.

22:19 <johanhenselmans> I still need a 120 Ohm between D+ and D- anyway...

22:19 <zmatt> resistors are not particularly known to break down, unless you dissipate a lot of heat into one, and using a resistor divider allows for using much larger resistor values and hence dissipating negligible heat

22:20 <zmatt> you do indeed need termination (unless you have a transceiver with integrated termination, which is not the case with the MAX13487E), though I'm not sure what that has to do with the problem at hand

22:23 <johanhenselmans> One more component ;_

22:23 <johanhenselmans> ;)

22:24 <zmatt> get a breakout board with integrated termination?

22:25 <zmatt> the bare IC needs more supporting components anyway, like power supply decoupling caps

22:25 <zmatt> and instead of a single termination resistor you may need 3 resistors to make a line biasing network

22:27 <zmatt> (there are transceivers which tolerate missing line-biasing, but this is not one of them I think)

22:31 <johanhenselmans> Nah, I am trying to integrate everything on 1 PCB. I could use some help though. Some of the stuff is way over my current knowledge. Aren’t you located in NL?

22:34 <zmatt> if you're designing a pcb, needing one or two more resistors really shouldn't matter... although using a resistor divider was more meant as a quick hack to be able to continue prototyping, for a final design it's obviously better to get a more suitable transceiver

22:35 <zmatt> (and where I'm located doesn't matter since I'm not available for 1-on-1 consulting or whatever)

22:36 <zmatt> what's your application here anyway? the BBB needs to be the master of some RS485-based bus?

22:39 <johanhenselmans> It’s the control of a tiny house. The RS485 is the modbus connection to the power and water meter. There is also some i2c-canbus communication for a CO2 sensor, some relais (heating and doors), other sensors (fire, open windows), and PWM for some LED strings. That kind of stuff.

22:42 <zmatt> based on a quick glance at the modbus spec, it looks like it normally does not use integrated termination, not even in the master

22:43 <johanhenselmans> And these houses should communicate to one another to optimize power usage.

22:43 <zmatt> since their example diagram (page 21 of https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf ) shows the master being in the middle of the bus

22:44 <zmatt> having said that, you can of course choose to integrate termination in the master if you know it'll always be at one of the ends of the bus

22:46 <johanhenselmans> That is exactly the point. The control unit will be on the end of the bus.

22:49 <zmatt> sections 3.4 of the pdf (pages 27-28) are useful, they describe requirements on grounding, line termination, and line biasing (which modbus calls "line polarization" apparently)

22:56 <zmatt> e.g. the MAX13487E needs line biasing, so if you use it as master then it would make sense to integrate line biasing into the master. we use the LTC2862 which doesn't require line biasing

22:57 <johanhenselmans> Well, the length will not be longer than 2 m max. So some of the limitations (max 1000m) is the same. I misread the termination. Apparently it is 150 ohms. Thought it was the same as CANBUS, which is 120 ohms, at least, that was my understanding.

22:57 <zmatt> (but as a consequence, it use a higher differential input signal threshold)

23:00 <zmatt> heh, at 2m you might even be able to get away with neglecting termination entirely, or terminating only the end of the bus

23:02 <johanhenselmans> For the moment I’l just make sure that I use a level shifter, to see if I can this thing working. Thanks for lighting up some of my blind spots.

23:03 <zmatt> a level shifter seems like the worst solution... it's overkill for quick prototyping (just use a resistor divider on RO), and nonsense for a final design (since there are plenty of RS485 transceivers that support 3.3V I/O)

23:12 <zmatt> unless you really need the extra line level I guess, although there are also transceivers with separate I/O and driver supplies

23:12 <zmatt> anyway, you do you, there's plenty of solutions in the solution space

23:13 <zmatt> don't forget to test P9.26 survived okay