I have a heating control device in my home that has two inputs marked NC and M (or COM?), which I read in the documentation I can use to control/switch the state of the device (it also says the input accepts 10V..). I think it means it would accept a switch between those two terminals. It also mentions it is isolated from the mains.
Being only a mediocre RPi3 user/developer, with little hardware hacking experience, I was wondering if the RPi3 GPIOs could be directly connected to those input terminals and make me able to change the state of the device. In which case, what GPIO numbers are best, how would they connect and what is the principle of programming this as I would prefer to use node-red and its GPIO nodes or the command line.
Related
We saw this answer: Direct communication between two PCI devices
Which goes a long way towards answering the question. But we wanted to poke a bit at it, to see if there's any wiggle room.
So, we are making custom PCIe cards, with custom drivers. The only thing outside our control is the chipset in the Server that the cards are plugged into. if we control which two boards we plug in, and both are programmed to talk to each other, such that "raw" data is fine.. and the device drivers are aware of the desire for direct communication.. can you see a way for direct data transfer? Getting creative?
If it is one root complex with multiple ports, then it's possible to have direct endpoint to endpoint communication.
If it's a multi-rooted root complex, then it's not covered by the PCIe specification and vendor-dependent if that feature is implemented. So notice multi-rooted PCIe subsystems in many cases if the bus IDs aren't consecutively numbered. It also depends on the implementation of the enumeration procedures if additional root complexes start their first bus ID by multiples of e.g. 64.
I am new to programming and FPGA. I like to run a program on my windows 10 PC and like to send input to the FPGA and when processing is done I like to receive output to the same program. Is it possible and how it can be achieved. I need some direction to start finding a way.
Thank you.
I recommend you to buy a Digilent Arty A7 board. It is low cost and very nice to work with.
To communicate with a PC/Windows you can use the USB to UART that you have on that board. However I think the best and easiest way to do it is to use an IP core that has support for Ethernet and TCP/IP. Using TCP/IP is very simple on the PC side using Python, Matlab, Telnet or any programming tool.
The best IP for the Xilinx FPGA that I have found so far is the ones from fpga-cores.com. There you only have to implement an AXI4 Stream to communicate with the client. I don't think it gets easier than that.
That core also include remote programming of the FPGA over Ethernet and a logic analyzer. All that is for free.
Good question. A lot of people ask about data processing on FPGA but never think about how to get the data to and from it. (Until it is too late)
The best way is to find an FPGA which has also has an SOC. That is: a processor, DDR interface and one or more high speed interfaces. Ethernet, USB, PCIe. Make sure they come with complete working example code, often some RTOS.
As to which FPGA to choose greatly depends on what you want it to do. You also need to have enough programmable gates to implement the function you want.
Nowadays all vendors have free HDL compilers up to a certain size FPGA.
Every FPGA manufacturer also has one or more prototyping boards, but the price of those varies a lot.
If you have some FPGA code which is capable of very high data throughput your interface is likely to become the bottleneck.
A PCIe board offers the highest data throughput, but for that you need to have matching drivers on both the FPGA board and the PC. In that case check that it has example drivers for the PC side too.
Yes, I fell into that trap a few years back
I know that we convert the GPIO to irq, but want to understand what is the advantage of doing so ?
If we need interrupt why can't we have interrupt line only in first place and use it directly as interrupt ?
What is the advantage of using GPIO as IRQ?
If I get your question, you are asking why even bother having a GPIO? The other answers show that someone may not even want the IRQ feature of an interrupt. Typical GPIO controllers can configure an I/O as either an input or an output.
Many GPIO pads have the flexibility to be open drain. With an open drain configuration, you may have a bi-direction 'BUS' and data can be both sent and received. Here you need to change from an input to an output. You can imagine this if you bit-bash I2C communications. This type of use maybe fine if the I2C is only used to initialize some other interface at boot.
Even if the interface is not bi-directional, you might wish to capture on each edge. Various peripherals use zero crossing and a timer to decode a signal. For example a laser bar code reader, a magnetic stripe reader, or a bit-bashed UART might look at the time between zero crossings. Is the time double a bit width? Is the line high or low; then shift previous value and add two bits. In these cases you have to look at the signal to see whether the line is high or low. This can happen even if polarity shouldn't matter as short noise pulses can cause confusion.
So even for the case where you have only the input as an interrupt, the current level of the signal is often very useful. If this GPIO interrupt happens to be connected to an Ethernet controller and active high means data is ready, then you don't need to have the 'I/O' feature. However, this case is using the GPIO interrupt feature as glue logic. Often this signalling will be integrated into a dedicated module. The case where you only need the interrupt is typically some custom hardware to detect a signal (case open, power disconnect, etc) which is not industry standard.
The ARM SOC vendor has no idea which case above the OEM might use. The SOC vendor gives lots of flexibility as the transistors on the die are cheap compared to the wire bond/pins on the package. It means that you, who only use the interrupt feature, gets economies of scale (and a cheaper part) because other might be using these features and the ARM SOC vendor gets to distribute the NRE cost between more people.
In a perfect world, there is maybe no need for this. Not so long ago when tranistors where more expensive, some lines did only behave as interrupts (some M68k CPUs have this). Historically the ARM only has a single interrupt line with one common routine (the Cortex-M are different). So the interrupt source has to be determined by reading another register. As the hardware needs to capture the state of the line on the ARM, it is almost free to add the 'input controller' portion.
Also, for this reason, all of the ARM Linux GPIO drivers have a macro to convert from a GPIO pin to an interrupt number as they are usually one-to-one mapped. There is usually a single 'GIC' interrupt for the GPIO controller. There is a 'GPIO' interrupt controller which forms a tree of interrupt controllers with the GIC as the root. Typically, the GPIO irq numbers are Max GIC IRQ + port *32 + pin; so the GPIO irq numbers are just appended to the 'GIC' irq numbers.
If you were designing a bespoke ASIC for one specific system you could indeed do precisely that - only implement exactly what you need.
However, most processors/SoCs are produced as commodity products, so more flexibility allows them to be integrated in a wider variety of systems (and thus sell more). Given modern silicon processes, chip size tends to be constrained by the physical packaging, so pin count is at an absolute premium. Therefore, allowing pins to double up as either I/O or interrupt sources depending on the needs of the user offers more functionality in a given space, or the same functionality in less space, depending on which way you look at it.
It is not about "converting" anything - on a typical processor or microcontroller, a number of peripherals are connected to an interrupt controller; GPIO is just one of those peripherals. It is also by no means universally true; different devices have different capabilities, but in any case you are simply configuring a GPIO pin to generate an interrupt - that's a normal function of the GPIO not a "conversion".
Prior to ARM Cortex, ARM did not define an interrupt controller, and the core itself had only two interrupt sources (IRQ and FIQ). A vendor defined interrupt controller was required to multiplex the single IRQ over multiple peripherals. ARM Cortex defines an interrupt controller and a more flexible interrupt architecture; it is possible to achieve zero-latency interrupt from a GPIO, so there is no real advantage in accessing a dedicated interrupt? Doing that might mean the addition of external signal conditioning circuitry that is often incorporated in GPIO on the die.
I am looking to write an Arduino script that uses whatever audio signal is going to the speakers to create a physical visualization.
The Arduino is connected to the windows machine only through USB, so I need to use USB to find out what is being sent to the speakers. How would I access this information?
As of right now, the Arduino can only communicate with the computer via serial over USB. Things have changed with the new Arduino Uno, but the examples have not yet been released to show how to have the new Arduino act as other USB devices.
You would have to write something for the Windows box that monitor's the system audio and sends the info about it over serial to the Arduino, as long as you want it to only connect via USB.
There isn't a very good way to interface an audio signal to an Arduino without some external hardware.
One way to do it though would be to connect the audio line to a biased pin with a capacitor, then you could use the ADC directly. There will be pretty terrible dynamic range, but it only takes 3 passive parts. Running that through an opamp before going to the ADC pin could significantly improve dynamic range and provide a filtering opportunity (see below). Alternatively, you could switch on an on-chip voltage reference to use (typically 1-1.5 V) instead of the main supply.
It doesn't matter that much for a straight visualization, but the sample rate will not be good enough to capture the full spectral content of the audio (in addition to the poor dynamic range resolution). The default Arduino sample rate is 10 kHz(-ish...possibly asynchronous), so you will only get valid data if your signal is below 5 kHz, otherwise aliasing will muck it up. (If you write your own analog driver for the ATmega32P you could get up to 76 kHz sample rate with 8-bit samples)
Then to actually communicate that data to a computer, you can fairly easily throw all those ADC values onto the UART for the computer to pick up and process as it sees fit. An ATmega will not have the power to compute FFTs on the fly (what you'd do almost always do for a viz anyways).
Or to skip all that, connect the audio signal to your computer's sound card (or USB sound card...they're pretty nice) and use some audio driver.
There is a Java library for processing called ESS that lets you access audio out.
We have a small embedded system without any video or serial ports (i.e. we can't output text via printf).
We would like to track the progress of our code through the initialization sequence.
Is there some simple things we can do to help with this.
It is not running any OS, and the hardware platform is somewhat customizable.
The simplest most scalable solution are state LEDs. Toggle LEDs based on actions, either in binary form or when certain actions occur if you can narrow your focus.
The most powerful will be a hardware JTAG device. You don't even need to set breakpoints - simply being able to stop the application and inspect the state of memory may be enough. Note that some hardware platforms do not support "fancy" options such as memory watches or hardware breakpoints. The former is usually worked around with constantly stopping the processor and reading memory (turns your 10MHz system into a 1kHz system), while the latter is sometimes performed using code replacement (replace the targeted instruction with a different jump), which sometimes masks other problems. Be aware of these issues and which embedded processors they apply to.
There are a few strategies you can employ to help with debugging:
If you have Output Pins available, you can hook them up to LEDs (or an oscilloscope) and toggle the output pins high/low to indicate that certain points have been reached in the code.
For example, 1 blink might be program loaded, 2 blink is foozbar initialized, 3 blink is accepting inputs...
If you have multiple output lines available, you can use a 7 segment LED to convey more information (numbers/letters instead of blinks).
If you have the capabilities to read memory and have some RAM available, you can use the sprint function to do printf-like debugging, but instead of going to a screen/serial port, it is written in memory.
It depends on the type of debugging that you're trying to do - in particular if you're after a temporary method of tracing or if you are trying to provide a tool that can be used as an indication of status during the life of the project (or product).
For one off, in depth source tracing and debugging an in-circuit debugger (eg. jtag) can be very helpful. However, they are most helpful where your debugging requires setting breakpoints and investigating memory and registers - which makes it of little benefit where you are dealing time critical problems.
Where you need to determine program state without having a significant impact on the execution of your system the use of LEDs connected to spare I/O pins will be helpful. These can also be used as the input to a digital storage oscilloscope (DSO) or logic analyzer.
This technique can be made more powerful by selecting unique patterns of pulses that will be identifiable on the DSO.
For a more versatile debugging tool, though, a serial port is a good solution. To save cost and PCB real-estate you may find it useful to use an plug-in module that contains the RS232 converters.
If you are trying to provide a longer term indication of status as part of the normal operation of your product, LEDs are again a cheap an simple method. However in this situation it is best to choose patterns of pulses that are slow enough to be easily identified by visual inspection. This will all you over time you will learn a particular pattern that represents "normal" behavior.
You can easily emulate serial communications (UARTs) using bit-banging from the IO pins of the system. Hook it to one of the card's pins and attach to a RS232 converter there (TTL to RS232 converters are easy to either buy or build), which goes to your PC's serial port.
A JTAG debugger is also an option, though cumbersome to set up.
If you don't have JTAG, the LEDs suggested by the others are a great idea - although you do tend to end up in a test/rebuild cycle to try to track down the issue.
If you've got more time, and spare hardware pins, and memory to spare, you could always bit-bash a low speed serial interface. I've found that pretty useful in the past.
Others have suggested some pretty good ideas using output pins, so I won't suggest that, although it can be a very good solution, and is very cost effective. If your budget and target processor support it, a hardware trace system, (either an old fashioned emulator, or a fancy BDM with bus snooping trace support) can be great for this type of thing. It's very expensive though.
The idea of using a bit-banged software UART is nice, but there's some effort required in writing one and also you need some free timers and interrupts. If your hardware has any other unused serial interface (SPI, I2C, ..), using them would be easier. With a small microcontroller you could convert the interface to RS-232.
If you have to go for the bit-banging, making a synchronous serial might be a simpler alternative as it wouldn't be critical to timing.