In my Android Things project using a RPi3 I connect MCP3008 ADC to the SPI CS/MISO/MOSI/SCLK pins BCM8/BCM9/BCM10/BCM11 respectively, open them service.openGpio(<pin>) and scan periodically to read analog input from connected pots. Full source: https://github.com/tomaszrykala/MidiMixerAndroidThings/blob/master/things/src/main/java/com/tomaszrykala/midimixerandroidthings/control/adc/MCP3008.java
I am trying to achieve the same result with a Pico i.MX7D board but whether I try to opent the CS port for example with "SPI3 (SS0)" or "SPI3.0" or GPIO6_IO26 I get every time android.os.ServiceSpecificException: Unknown I/O name SPI3 (SS0) (code 19) (replace the name with any of the preceding examples).
Is there a way to reuse my logic for the Pi by opening the SPI gpio on the Pico at all?
In Android Things, a signal name is tied to a function. The RPi3 board uses dynamic pinmux support which allows Peripheral I/O to open the same pin for alternate functions at runtime. Each function, though, has a unique signal name (e.g. BCM8 and SPI0.SS0 are the same physical pin). This is why the pinout diagram has a table with multiple signal names for certain pins.
The Pico boards do not have internal pinmux support at the moment, so there are no alternate signals available for each pin. Each pin has a dedicated function, which is why the pinout diagram only shows one signal name for each.
Related
Are there any Wireshark gurus?
I am debugging an issue on my home Zigbee network. I have a sniffer dongle and I can catch all the packets transmitted. Since my network has ~40 devices, the air is quite cluttered with packets I am not really interested in. I am looking for a ways to filter uninteresting messages
Questions:
Is there a way to filter out messages related to IEEE protocol (various Data Requests, and Acks), while leaving only upper layer messages (Zigbee, Zigbee HA)?
Is there a way to assign human readable labels for the devices on the network? e.g. 'Coordinator' instead of 0x0000, or 'Light Switch' instead of '0xc83a'?
I would propose making your own filters (whoah, relax, we are not animals, we do this the smart way) ... go to Statistics > Protocol Hierarchy, the panel should show you all the traffic by protocols. Then just identify which protocols you do not want to see, mark them (one by one), right-click and Prepare as Filter > ...and not Selected (to prepare a filter to exclude the highlighted protocol). Sadly wireshark does not allow you to select multiple protocols to exclude at once. After this simply save your filter and reuse it as much as you like
What you are trying to do is Name resolution. This is done via configuration files, more specifically ethers and hosts
Got a general question regarding the GPIOs on P9 of the beaglebone black. For instance, I would like to use the UART1 (RX and TX) for a R232 communication and use the I2C2 (SDA and SCL) for a sensor, using a C language application running on Linux. The problem is that the UART1 (RTS and CTS) signals are on those pins, can these features be deactivated (software)? and therefore use the UART1 and I2C2 at the same time?
PIN 19 : UART1_rtsn - I2C2_SCL
PIN 20 : UART1_Ctsn - I2C2_SDA
Next question, the same applies for SPI1 (CS0 and CS1), these pins are also on I2C2 (SDA and SCL).
PIN 19 : I2C2_SCL - spi1_cs1
PIN 20 : I2C2_SDA - spi1_cs0
So the general question : Can all 3 units, UART1-SPI1-I2C2 all run at the same time with no conflict on pins using the P9 header of the bbb?
Thank you very much for your answers
JH
It is technically feasable although when you start foraging into custom pin assignements you have to deal with alot of complexities to get everything up and working. There are many tables around the internet with the references as to which pins can do what. My favorite so far are these two : http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP8Header.pdf, http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP9Header.pdf
If you read these, you can see that each pin can take multiple different functions depending on configuration. These are set to the defaults by the linux kernel at boot time but you can modify the defaults using device tree overlays. The whole process is a little envolved for a single answer here but in short, to do what you want, you would need to modify and recompile the device tree overlay that the kernel loads for the device you want to change the pin assignements off.
Although there are some limits, for example, the beaglebone images are all configured to use I2C2 for identifying capes. So you can theoretically change it's pin assignments but then you shouldn't expect capes to be identified and configured properly when you do. In your example above, the UART1 and I2C2 work without conflict using their default configuration (UART1 only has Rx & TX by default). The SPI1 is a little more work. It's default configuration shares pins with the sound card (HDMI) that must be disabled to get it to work athough it does not conflict with ether UART1 or I2C2 by default.
Notice that each of these pins can have multiple functions but can only by one at any one time. Therefore, if a pin is set to use a given module (say UART1) it will not be affected by another module that can theoretically output on that pin with a different function mode. The kernel will complain if you try to use a pin for 2 functions simultaneously so you can try to load the overlays and see if it conflicts by default. Basically, if the kernel accepts to load the tree overlay, you can generally assume that it does not conflict with any other that is already loaded.
I think the other answer misinterpreted the question, and addresses configuration of the pins to perform a function of the possible mappings available to that pin. Yes, this is easily possible and is largely the point of the design.
With regards to the actual question, the answer is that it's possible but it's going to be very difficult and is most likely not feasible. And only one communication protocol will be able to be used at a time. Additionally, the spi pins are chip select pins, which require either an asserted or de-asserted state, so any kind of i2c clock or data signal will render the chip select non functional.
For i2c/uart, it would require reconfiguration of the pins and software mappings on the fly, and it will only be able to perform one of the possible functions at a time. It will also require software on all sides of the busses to be able to understand what mode the pins are in ie i2c or uart, with mutually separate and smart protocols so that none of the devices on the bus react undesirably to the garbage that will be on the bus when the bus is being used for another operation mode.
I 'm using coremidi all right, but I want to also support an external USB function.
I 've tried an app called Midi Monitor which indeed finds my USB interface when connected.
The problem is how to enable this interface through my own app. As said in MIDIGetNumberOfExternalDevices documentation, "Their presence is completely optional, only when a UI (such as Audio MIDI Setup) adds them."
How am I supposed to add them?
Best Regards.
"External devices" are not what you want. Those are the things that a user can create in Audio MIDI Setup in OS X, to represent a synthesizer or keyboard or other device that is connected to the computer via a MIDI cable. The system does not automatically create them. (It can't, because MIDI is terribly primitive and has no device discovery protocol.)
External devices are only for the user's benefit in naming and arranging things. They can't be used to do MIDI input or output. They're especially useless in iOS, since there's no Audio MIDI Setup app.
Instead, use MIDIGetNumberOfSources and MIDIGetSource to find sources of MIDI data.
To actually get input, use MIDIInputPortCreate to create an input port, then MIDIPortConnectSource to connect one or more sources to that port. Then your port's MIDIReadProc will be called when MIDI comes in.
Similarly, for output, you would use MIDIGetNumberOfDestinations and MIDIGetDestination to find destinations, create an output port using MIDIOutputPortCreate, and MIDISend to send data through a port to a destination.
For reference, see the MIDIServices documentation.
This is a little off the beaten path. I've got a DLink DWL-G520 card I'm using under OpenBSD and it works fine. What I want to do is be able to access the radio part of it. Why? I want to use it in a radio telescope. It's a 2.4 GHz receiver with an external antenna connector. I want to connect some coax, some amplifiers, and an old TV dish and point the dish at the sky. It has an RSSI signal and variable RF gain (which it adjusts, from what I can find) so all I'd need to do is record those over time while pointed at a certain spot in the sky. I don't need to control the frequency really since most natural events are broadband.
I'm poking through the OpenBSD ath driver following nested structs but I don't want any of the normal network stuff, which is most of what the driver does. dmesg identifies it as an AR5212 which according to the Atheros PDF is always paired with an AR2112 radio. Is there any easier way than wading through PCI stuff to see what my options are? I need to turn the transmitter off so it doesn't fry my amps too. Trying to find low level documentation is about impossible from what I've seen. Ultimately I'd like to have this work with other WiFi cards too, but I'll start with this one. I've got a Cistron with an external antenna connector also.
Alan, ab1jx
I have a cash register of a Chinese manufacturer and I want to open its cash drawer using Delphi code.
The register and the drawer are connected by an RJ12 (6 pins) cable.
I've seen elsewhere mentioned "cash registers and POS system sends a 12V or 24V signal to the cash drawer to activate the solenoid to open the cash drawer."
sorry the web site of the manufacturer is here.
How can this be done in Delphi?
If you need just a 12V signal with low amperage, you can use a V24 RS232 classical serial line. The common voltage is +12V (ON) and for it you may use a control signal like DTR.
You have a lot of serial port libraries for Delphi.