Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re^3: Device::BCM2835, hardware access on a pi, SIGSEGV

by hardburn (Abbot)
on Aug 26, 2014 at 17:29 UTC ( #1098638=note: print w/replies, xml ) Need Help??

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

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.

  • Comment on Re^3: Device::BCM2835, hardware access on a pi, SIGSEGV

Replies are listed 'Best First'.
Re^4: Device::BCM2835, hardware access on a pi, SIGSEGV
by Peterpion (Acolyte) on Aug 27, 2014 at 10:19 UTC

    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
      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 IC (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 IC, 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, IC, 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 IC, SPI or similar for a simple, fast protocol in between those two AVRs. Or use IC, SPI, or RS232 between an AVR and a raspi.


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

      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1098638]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (8)
As of 2019-09-23 11:57 GMT
Find Nodes?
    Voting Booth?
    The room is dark, and your next move is ...

    Results (279 votes). Check out past polls.