Gpio Ibus
A Java API is provided for dealing with SPI, GPIO, Commodore 64 hardware, and more. 980811 507k 0 iBus - The 'Pure Java' Multicast Object Bus. You know that the iBus enabled PDC module can give you the measurement data from each sensor over the. Also one mor GPIO for the LED inside the PDC Switch to show.
I want to read with Raspberry GPIO from car's lines that have 12V logic. Also I need to controls some of these lines. For example to ground lines or raise the line to 12V. I can make switching from 12v - 3V and 3V - 12V with simple NPN. Attached is what I'm using. DOes it look okay?
Actual question is: I have these 12v lines quite many and I want to minimize space in the board. For example 10 NPN:s would take quite a lot of space. Is there any readily available chip that could take for example 8 inputs and switch them to 12V. On the other hand is there any chip that could control 12V based on Rpi GPIO output? Attachments 12Vlogic.jpg (48.08 KiB) Viewed 5889 times. Michaell wrote: I can make switching from 12v - 3V and 3V - 12V with simple NPN. Attached is what I'm using.
DOes it look okay? Yes, it would work, but to convert 12V to a suitable 3V3 compatible signal you could also use a simple resistor divider, say a 10K + a 2K7 resistor.
As for your drawings, I would say that Zener Z1 serves no useful purpose, the base-emitter diode is that, a diode, and wont allow more than about 0.7V over it, making the zener irrelevant. Also for the right drawing, the two diodes D1 and D2 are already incorporated into the GPIO, their existence is the reason its not possible to put 5V on the GPIO pin, as the top diode would conduct the 5V to the 3V3 supply. Michaell wrote:I want to read with Raspberry GPIO from car's lines that have 12V logic.I personally would consider looking at RS232 converter chips as automotive work is rarely exactly 12V. The battery supply is generally considered as being between 10V and 18V, depending on charge level, engine revs and other factors, also considered very noisy and spikey, so you may have to filter your inputs for reliable operation. RS232 converters can dela with +/- 12V nominal inputs, and most receivers can cope with +/-25V levels (check the datasheets). Most newer devices like MAX3222 series can provide 3V ouput levels and only need 2 to 4 100nF capacitorsto create a low current +12V and -12V rail, which may be able to bypass the ned for with 12V supply available. Also I need to controls some of these lines.
For example to ground lines or raise the line to 12V. Well this is more tricky as you have not said what they are driving current wise or how in circuit with existing wiring they will be. Most parts of a car (lights, wipers, windows, indicators etc) are driven by relays some with high coil currents. The ULN2803 mentioned earlier is a good place to start as it has the snubber diode built in, but watch how much current each circuit needs and if each drive will be the only item driving the car part or with existing circuit. Actual question is: I have these 12v lines quite many and I want to minimize space in the board. For example 10 NPN:s would take quite a lot of space. Is there any readily available chip that could take for example 8 inputs and switch them to 12V.
On the other hand is there any chip that could control 12V based on Rpi GPIO output? See ULN2803 for this but CHECK what current drive is required for each output. As for inputs even consider resistor dividers with caps, inductors at car side and low voltage zeners at the Pi side. Basically when doing a car automotive signal from another part of the car always consider it might be 18V with lots of noise and higher voltage spikes. Michaell wrote:Also I need to controls some of these lines. For example to ground lines or raise the line to 12V.
Well this is more tricky as you have not said what they are driving current wise or how in circuit with existing wiring they will be. Thanks for the answers mahjongg and techpaul!
The +12V in the picture should actually be B+, cars battery voltage taken from some control modules constant +12V. Didn't know the line would be that noisy. Good to know! The actual lines I'm dealing with are very low current lines. For example one of them delivers UART data at 9600Bps coming from various control modules in the car. In one case a single 'data' line is shared among a few modules. And there is another 'status' line indicating if the data line is busy or not.
If data line is high my application can reserve it by pulling the 'status' line to ground and then write to the data line. After that it should free status and data lines so that others can use those. Outputs should be open collector like they are in my sketch. I came across SN5407 which seems to have open collector outputs.
Would this be better alternative? Another question what kind of leds and what resistors I could use in the GPIO 3.3V line without messing the TTL logic? And there is another 'status' line indicating if the data line is busy or not. If data line is high my application can reserve it by pulling the 'status' line to ground and then write to the data line. After that it should free status and data lines so that others can use those. Outputs should be open collector like they are in my sketch.
Depending on where it is in the car just pulling the line low and not handling according to the comms spec and protocols could do damage to your car, stall it or put it into other dangerous conditions. I came across SN5407 which seems to have open collector outputs. Would this be better alternative?Whilst this is a 30V drive device, you do not need a MILITARY spec device (temp range -55 to +125 deg C), this is denoted by the '54' in the SN5407, automotive parts are specced using the range -40 to +85 deg C range. Personally with correct sfeguards you could use a SN7407 (0 to +70 deg C) for driving outputs but without more details on the bus and other signals you are tapping into I would not guarantee anything more. Car makers are very secretive about their control systems. Another question what kind of leds and what resistors I could use in the GPIO 3.3V line without messing the TTL logic?The same as any other circuit that drives LEDs from 3V3, depends how many you want to drive.
My impression is that you are trying something beyond your current knowledge level. I would suggest get your LEDs going, get some serial comms to a PC going, then do more research on exact voltage, timing, protocol and other factors on what happens in the car. All this BEFORE messing with the car electrics. And there is another 'status' line indicating if the data line is busy or not. If data line is high my application can reserve it by pulling the 'status' line to ground and then write to the data line.
After that it should free status and data lines so that others can use those. Outputs should be open collector like they are in my sketch. Depending on where it is in the car just pulling the line low and not handling according to the comms spec and protocols could do damage to your car, stall it or put it into other dangerous conditions.
My impression is that you are trying something beyond your current knowledge level. I would suggest get your LEDs going, get some serial comms to a PC going, then do more research on exact voltage, timing, protocol and other factors on what happens in the car. All this BEFORE messing with the car electrics. You're right - although I have M.Sc. All electronics related is quite new to me and I know the basic stuff.
But I'm pretty excited about this and learning every day something new In attached picture I'm watching the 12V status line I told in previous post. Please notice that logic is inverted (my bad for mixing + and -) but you can see every 100ms some module in the car is reserving the line momentarily. Protocol for data line is really UART.
I don't have any scope picture for you about that. Attachments 12100037.jpg (58.26 KiB) Viewed 5823 times. Techpaul wrote:You will need to put safeguards in to stop collisions on the data network. I would only start by monitoring the bus and status signal.
You might find it is 9bit UART data with or without additional parity as word of warning. Depending on what network you need to put safeguards in so that no matter what happens to your hardware or software, the bus reservation signal never stays permanently on and screw things up for other modules.
Thanks techpaul! I learned many new and probably very important things today. Could you tell a bit more if SN7407N would be suitable in my case?
I understand that output can be left as open collector or ground/high if I want to. Techpaul wrote:You will need to put safeguards in to stop collisions on the data network. Depending on what network you need to put safeguards in so that no matter what happens to your hardware or software, the bus reservation signal never stays permanently on and screw things up for other modules. Thanks techpaul! I learned many new and probably very important things today.
Gpo Business
Could you tell a bit more if SN7407N would be suitable in my case? I understand that output can be left as open collector or ground/high if I want to. It could be depends on what other aspects there are for the circuit you are linking into.
Gpio Buttons Driver Windows 10
You might have to monitor the bus output and determine if the bus signal is being held in error state. There is always a possibility of ANY open collector/drain shorting to ground.
Techpaul wrote: It could be depends on what other aspects there are for the circuit you are linking into. You might have to monitor the bus output and determine if the bus signal is being held in error state. There is always a possibility of ANY open collector/drain shorting to ground.
Ok, thanks again. So it looks like for sensing 12V line I could use voltage divider line to provide 5V input for the SN74074N. Output could be connected to RPi GPIO input with pull-up enabled. About other case: If I configure GPIO as INPUT will the output be then left as open circuit? Michaell wrote:Ok, thanks again. So it looks like for sensing 12V line I could use voltage divider line to provide 5V input for the SN74074N. Output could be connected to RPi GPIO input with pull-up enabled.
Using the 7407 or 7417 would work, with internal pullup enabled, also means your 7407 or 7417 will act as cheaper sacrificial buffer in case of faults from outside. Make sure your divider range will allow for 18V divide to 5V and at 12V will provide more than enough to be above the input high threshold of the 7407 or 7417.
Michaell wrote:About other case: If I configure GPIO as INPUT will the output be then left as open circuit?Not quite sure what you mean.there but if configured for input the output stage is normally set to a tri-state condition (not driving high or low), inside the chip it is not totally open circuit, but close to. Thanks again. In this case the output would be connected to single 'status' line. Which needs to be either grounded or left as open circuit.
So to set 'status' line to ground I'd have to configure GPIO as output and set it LOW. For leaving 'status' line as open circuit I'd have to configure GPIO as input. Michaell wrote:About other case: If I configure GPIO as INPUT will the output be then left as open circuit?Not quite sure what you mean.there but if configured for input the output stage is normally set to a tri-state condition (not driving high or low), inside the chip it is not totally open circuit, but close to. Thanks again. In this case the output would be connected to single 'status' line.
Which needs to be either grounded or left as open circuit. So to set 'status' line to ground I'd have to configure GPIO as output and set it LOW. For leaving 'status' line as open circuit I'd have to configure GPIO as input. That requires more complex buffer circuits for what you are suggesting and is classed as a bi-directional line, as compared to most GPIO modes being uni-directional. What we discussed previously was how to get a 12V (nominal) signal into a Pi input. As you need to monitor and drive what actually is happening beyond any buffers you have I would suggest using two GPIO one to constantly monitor the outside world and one to drive the signal when needed. This way you can drive the outside line and monitor what you are driving.
For these types oif busses it is often not safe to rely on one pin and its mode of operation to disbale your driving. Also you may change mode at wrong time and try to drive the signal at same time as something else is driving the signal, causing a collision. So you need to be aware of what is happening and make changes as quickly as possible. Techpaul wrote: That requires more complex buffer circuits for what you are suggesting and is classed as a bi-directional line, as compared to most GPIO modes being uni-directional. What we discussed previously was how to get a 12V (nominal) signal into a Pi input. As you need to monitor and drive what actually is happening beyond any buffers you have I would suggest using two GPIO one to constantly monitor the outside world and one to drive the signal when needed.
This way you can drive the outside line and monitor what you are driving. For these types oif busses it is often not safe to rely on one pin and its mode of operation to disbale your driving. Also you may change mode at wrong time and try to drive the signal at same time as something else is driving the signal, causing a collision. So you need to be aware of what is happening and make changes as quickly as possible. Yes, the original idea was to use two separate GPIO's for monitoring and driving. Much simpler.
Sorry for the confusing message. Michaell wrote:For serial communication I found this chip: Will this work with 3.3V logic level? Not directly as its output high voltage is a minimum of 4V and can be something much higher as a function of the supply voltage to the chip. It is a chip used in automotive for some ECUs comms different to simple UART comms. Has this chip been specified by someone elese for that car or that function? Have you found out what the comms method is in use for what you want to monitor? One of my projects is to implement interface that can communicate with E32/E34 cluster.
I just found this link. So far the info about this I've gathered over the bmw forums. Here it is quite well described. Comms is 9600 8E1. If someone made a ready chip that had logic to control the lines and send data to cluster it'd be success.
So the plan would be to use some non-inverting buffer uln2803 or sn7407n to interface with these two 12V lines. I want to keep design as simple as possible.
Original plan was to use NPN:s to control the lines and think about data sending later. But I now can see the possibility to use uln2803 or sn7407n also for sending UART data to data line. Because logic is not inverted. Input pin is attached to Rpi's UART tx pin and output attached to data line. I'd be interested to hear what kind of other solutions you can think of?