in reply to Re: Device::BCM2835, hardware access on a pi, SIGSEGV
in thread Device::BCM2835, hardware access on a pi, SIGSEGV

Thanks - I do realise the pi & raspian is not 'real time' and I will get glitches - which I am observing, exactly as you say, when log files are written mostly. My hardware responds to pulsed signals and has a time constant of around 20 pulses before it flips state, so the idea is to smooth out the glitches with the hardware slow response. The reason to pulse the output of the micro is to do my best to make sure the hardware does not crash in a logic high state which would destroy the things its controlling within a few seconds (mainly a marine reef tank chemical addition pumps). The use of pulses which are converted in hardware to on / off controls seems to me to greatly reduce the chance of a software caused 'fail to on state' (thats the idea anyway!). My hardware requires a specific frequency for several pulses before it will turn on - higher or lower frequency will not cause the change.

Im really interested in the PIC approach but have zero experience with it - I had to look up what a AVR is - I guess youre implying that its real time capable which is interesting. But the gear and work involved in starting out seems significant whereas the pi and linux is comfortable territory for me hence the current project. But I might spend a bit of time today looking into the most simple way to start out in that area with the most basic setup.

Thanks, Pete
  • Comment on Re^2: Device::BCM2835, hardware access on a pi, SIGSEGV

Replies are listed 'Best First'.
Re^3: Device::BCM2835, hardware access on a pi, SIGSEGV
by hardburn (Abbot) on Aug 26, 2014 at 17:29 UTC

    If you're interested in AVRs, Arduino might be the best place to start. It's around $10 for a Nano version, which can do a lot, and you'll only need to add a USB cable to get started. The libraries are technically C++, but they tend to hide the complexities of the language until you get really deep into it.

    Raw AVRs are more verbose, but have the advantage that you can use a single chip for buck or two. You can get programmers for around $15-30.

    They're not necessarily hard real time systems, with a bunch of rigorous guarantees about latency. But as microcontrollers, nothing is running except your code, which is usually good enough.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]

      Thanks - I ordered a few bits and pieces last night actually! Got a very cheap programmer, handful of avrs, breadboard etc, and I will have a tinker when I get a chance. I decided to get the bare chip because it dosent seem much harder to put the bootloader on yourself from what I read yesterday and its cheaper for multiple chips so if I break them when breadboarding I wont be too annoyed. One thing I noticed though was that adding network support seems tricky / has reliability problems (what with the IRQs required etc) so I wonder for a network attached control and monitoring device, perhaps the pi is still the better way to go? Would be interested in opinions.

      Thanks, Pete
[reply]
        One thing I noticed though was that adding network support seems tricky

        Yes, indeed. Programming 8 bit AVRs (ATtiny, ATmega, ATxmega) is comparable to programming the old home computers, but in C (and perhaps some Assembler) instead of BASIC (and almost always Assembler). Your code runs on the bare hardware, there is no operating system, you have to implement everything by yourself (or find good libraries).

        Networking can be easy, for some kind of networks. Many AVRs have hardware support for I²C (called two-wire interface), SPI, the "better" ones also have a hardware UART capable of implementing RS232 and RS485 (except for the line level inverters), the "big" ones also have a CAN bus controller.

        But the UART lacks a FIFO that you are used to from "big" computers, so you need a fast interrupt routine to buffer incoming data and another one to send buffered outgoing data. This is also true for I²C, SPI, and probably even CAN. And due to the low clock frequency (typically much less than 50 MHz), your code runs slow compared to any PC you might use today, even with a highly optimizing compiler and a RISC instruction set. You simply won't be able to handle data coming in at Gigabit Ethernet speeds, no matter what interface you use. Probably not even at 10 MBit/s. And you don't have the memory to do so, not even enough address lines.

        So, what does work?

        • As written above, I²C, SPI, RS232, RS485, CAN to communicate with other microcontrollers or a network gateway.
        • You can use old ISA Ethernet cards (10 MBit/s), and implement a low level ethernet driver and some kind of minimal TCP/IP (IPX, whatever) on top of that. There are libraries out there, so you don't have to implement all by yourself. Don't expect to be able to handle full TCP/IP, and don't expect to be able to handle it at full speed.
        • There is at least one ethernet chip (ENC28J60, 10 MBit/s I guess) that can be controlled via SPI and needs just a few passive components, so you don't have to implement a minimal ISA bus. The chip can deliver a clock signal to the AVR, and it also has a Wake-on-LAN signal output. So, you need fewer pins than for the ISA solution, but on the software side, there is little difference. You need a low level driver and a TCP/IP or IPX stack, and it won't be fancy.
        • If you can use RS232, either bit-banged or using a hardware UART, you can use one of the old modem protocols for file uploads / downloads (XModem, YModem, ZModem). Or you implement PPP and get TCP/IP. You "just" need some gateway that routes your PPP connection to your ethernet. Old cheap routers flashed with a custom firmware (OpenWRT) can do that. Plus, most of them have a CMOS/TTL level RS232 interface, so you can omit the line level inverters. A raspi could do that, too.
        • Even the smallest ATtiny can implement a low-speed USB device completely in software (plus three resistors, two zener diodes, one electrolyte capacitor, one ceramic capacitor, no crystal). The V-USB library consumes almost all of its resources, but leaves enough room for a little bit of I/O, powered by the USB host. You can implement USB HID devices (fake a keyboard, mouse, joystick), USB CDC ACM (RS232 emulation), and perhaps other devices. That's also my current pet project (based on CDC-IO), an ATtiny85 connecting a Linux USB Host to three solid state relais to switch peripherals on and off. Linux sees a low speed USB CDC ACM device (USB spec says those devices must not exist, CDC ACM is reserved for full speed and faster), just writing to /dev/ttyACM0 is sufficient to control the relais. No one prevents you from talking PPP over USB CDC ACM. It will be slow, due to the USB bit-banging overhead.
        • There is also USB CDC Ethernet, simulating two Ethernet cards and a cross-over cable. Never tested that with V-USB, and no clue how to implement that. And there is Microsoft's RNDIS, NDIS over USB. Never tested that, no clue how to implement it. But in both cases, you need a router to get into the "real" ethernet. As above, this could be a raspi or an OpenWRT box with a USB host controller.

        Note that the really big AVRs contain USB controller hardware, so you don't need bit-banging to communicate with the USB host. But those AVRs come only in SMD packages.

        AVRs are cheap. Consider using two AVRs, one for the real-time task and one for the communication with the outer world. Use I²C, SPI or similar for a simple, fast protocol in between those two AVRs. Or use I²C, SPI, or RS232 between an AVR and a raspi.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

        I haven't done networking with raw AVRs, but I know the cost of the Arduino WiFi and Ethernet shields are high enough that it makes more sense to use the Pi for networking.

        I used a hybrid Arduino/Pi approach for the WumpusRover. This used the Pi to take commands over WiFi and then pass those to the Arduino over I2C, which controls the servo and speed controller.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
[reply]

In Section Seekers of Perl Wisdom