RaspberryPi + AVR?

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, this is somewhat about AVR but more about RPi.

 

Thinking of a home project using a combination of RPi and an AVR. The AVR would handle the sensor interfaces and maybe interface to a LoRa module. The RPi would handle WiFi LAN connections, data display and system control. Yes, it can probably all be done in the  RPi, but that is not what I know about.

 

Not yet very familiar with RPi hardware interfacing, hence this question: of all the interface channels for the RPi (WiFi, USB, BT, SPI, I2C, etc), which ones represent low pain and good development success rate, considering both ends?

 

My initial thought is that WiFi and BT both represent aignificant challenges at the AVR end. SPI and I2C seem to require a lot of fiddling with obscure code modules at the RPi end. USB is native at the RPi end and easily implemented with an FT232R at the AVR end. Is this a reasonable assessment?

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Jul 9, 2019 - 10:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For small , low cost processing with wifi & IO, take a look at the rpi zero-w (with wireless)....This is only about $10 (non-W is $5).

 

https://en.wikipedia.org/wiki/Raspberry_Pi

 

You give up some of the speed, but retain a lot of capability

We have several project that use the "big brother" compute module.

 

SPI and I2C seem to require a lot of fiddling with obscure code modules at the RPi end

 

Have hooked up many run-of-the mill spi & I2C chips using various generic IIC/SPI libs...not too bad, but an analyzer is indeed handy (usually to figure out what I am doing wrong).    Some chips are popular enough that they  have their own libs which can be used rather, than you working to use a generic.

 

Getting used to Linux &  Python can be a challenge (if not used to that)...other languages are usable as well, though Python seems to be the "default".

I'd say the biggest hardship is creating precision timed outputs...There are so many layers of code that when you raise pin vs when it actually raises may be much slower or randomly timed than the typical compiled AVR response.   So turning on a pump or alarm LED is perfectly fine...creating some hard disk write head waveform would take more exacting effort than equivalent C programming an AVR.   That's not to say it's not possible, it's not the "baseline" rpi I/O usage. 

I save myself grief by generally picturing pin control as PLC-like.

My buddy always thinks I'm programming an AVR (even though we are using an rpi) and says "when this pin goes high, 2 us later pulse this other pin with five 1us pulses"....nah, I tell him.   Not that it can't be done, just not with the I/O control setup I'm using. 

 

On the other hand you can import some  MP3 libs &  some graphics libs & have a touchscreen jukebox up and running pretty quickly. 

 

 

We use some of the advanced vision processing libs like OPENCV ansd can do real-time object searching & tracking (& turn on an led when we see it!!!)

 

WiFi and BT both represent significant challenges at the AVR end

Well, you can get plenty of WiFi/BT add-on modules for AVR projects. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My goal is to concentrate on the user interface on the RPi and sensor interfaces on the AVR (probably an M4809, just for gaining some familiarity). 

 

Have some experience with Python 2.4, less with linux, none with Python 3.x. Need to spin up on BOTH of these.

 

It would be nice to be able to push a new program into the AVR board from the RPi. Thinking more and more that it will be USB.

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Getting used to Linux &  Python can be a challenge (if not used to that)...other languages are usable as well, though Python seems to be the "default".
Python is available for Windows 10 IoT Core though one might prefer C#.

Only quad-core Raspberry Pi in Windows 10 IoT Core and only one window on the display; UART to and from the AVR.

GitHub - ms-iot/python

Suggested Prototype Boards - Windows IoT | Microsoft Docs via Overview of Windows 10 IoT Core - Windows IoT | Microsoft Docs

What is new with Serial in Windows 10 - Microsoft Tech Community - 270855

...

 

2. A Windows Runtime API for communication with Serial devices

...

  1. UARTs inside embedded  systems like MinnowBoard Max or Raspberry Pi v2 running Windows IoT SKU

 

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seemed like a good idea to me, too.  RPi apparently does serial and I2C pretty well, via its IO connector.

 

I designed a board that's supposed to be a "hat" for an RPi-zero, while providing Arduino Nano compatible connectors for those sensors and stuff (but with at 328pb!)  (Serial port between the PB and the RPi.)

I never got around actually building the thing (or even getting my RPi running), but you're welcome to use it as a starting point if your want...  (Sigh.  Pay particular attention to which board/connectors are "on top" and which way they're facing.  I got pretty wishy-washy about everything other than "the RPi main chip ought to be "up" in case it needs a heatsink, and I'm not sure that it's currently consistent.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahh, forgot about async serial. Your little hat looks like it might be useful. I take it that ISP1 is the programming connector?

 

Dare I ask for an EAGLE file, if that is what you used?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I take it that ISP1 is the programming connector?

Yep.  I'm especially uncertain whether it's on a useful side of the board...

 

Dare I ask for an EAGLE file, if that is what you used?

https://drive.google.com/open?id=1KVm3kncxs_DieD4-spqKHUoBOjNJS4RM

There are two versions in there.  I don't remember exactly how they're different (Hmm.  The edit history says I was fiddling with the board layering in the "2" version...)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Pi Zero has some clock stretching issues with I2C; it caused me some pain, but then I had an idea to try an interleaving buffer on the TWI driver that I had high graded. This link shows the bug.

 

http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html

 

This link is to the driver I am using (the line # is the interleaving buffers, today anyway).

 

https://github.com/epccs/RPUpi/blob/master/lib/twi1.c#L66

 

So I have managed to get I2C, SPI, and the UART working between the R-Pi and AVR. What I like most is that I can SSH into the R-Pi then build and bootload (or isp) without having to involve anything outside. I can also pull or push with Github when I like as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had not considered a hat of the kind westfw was working on. That changes the game, somewhat, and linking to the host RPi via UART is also quite attractive. That sort of shuts the door on reprogramming insitu though a bootloader could solve that. I really like the idea of being able to SSH into an RPi.

 

westfw - If its OK with you, I'd like to use one of your layouts mostly for mechanicals and change the circuit somewhat (maybe a Mega4809 for all the bells and whistles).

 

Ideas greatly appreciated.

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a board that shows how I have been interfacing between the UART and SPI with an IOFF buffer. The target side supplies the power to the IOFF buffer, so push spring probes to the target board and then power up the target (well that is what I should do, but I have offset the probes a little, to appease the hotplug gods).

 

https://github.com/epccs/Driver/tree/master/ICSP

 

I have not tested ^3, but the only change was to fix a node name issue (MIS0 & MISO). I am using the ^2 board with a jumper and some python scripts. Just "cd" into the working folder with a Makefile and run the python; then it spins up a Makefile rule every time I push the proper button. The ^3 Eagle file will be found here (soon).

 

https://github.com/epccs/Eagle/tree/master/ICSP

 

If avrdude had a driver that used linuxgpio for the Mega4809 programming interface (PDI if I recall), then I may want to add it to my board.