Remote timer variable

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

Hi,

 

Im trying to make a remote timer circuit for controlling the power state of a Raspberry Pi. For this I'm using a attiny24. The idea is that an input (PA1) on the ATtiny is connected to a GPIO pin on the raspberry. When the GPIO pin is high then the Raspberry is powered on. When the pin goes low, then the Raspberry is off. When the pin goes low an internal timer in the ATtiny should start and after XX amount of seconds it sets another pin high (PB1). This then turnes the Raspberry on again. Kinda simple. So here is the question:

 

I want to be able to configure the timeout variable XX remotely, without having to flash the entire device again. But as a non expert in this, I'm trying to understand how this could work. As far as I understand I can use avrdude (from the raspberry pi) to write a variable to the EEPROM and then setup your AVR program to read from the EEPROM variable, is this right? If this is right, how would the variable be written with avrdude and how would it be read from the avr program?

 

Hope you can help.

 

Cheers

This topic has a solution.
Last Edited: Wed. Oct 18, 2017 - 11:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So how much C or C++ programming have you done?  Any AVR programming?

 

A great place to start is with an Arduino UNO, once you have your sketch running there, you can find advice on how to port it to a tiny here.

 

Jim

 

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

 As far as I understand I can use avrdude (from the raspberry pi) to write a variable to the EEPROM and then setup your AVR program to read from the EEPROM variable, is this right?

I do not see the point of this maneuvre.

Instead you can simply write the (changed) value directly to the program and compile again. 

Last Edited: Wed. Oct 18, 2017 - 06:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The idea about the variable is that its a value that may change often, so I dont want recompile and flash everything just because some value changed. 

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

A Raspberry Pi is a Linux computer: simply pulling the power while it's running is not a great idea - especially if you're planning on doing it on a frequent basis!

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

lovepie wrote:
I dont want recompile and flash everything just because some value changed.

So why would you use the avrdude??

 

Wouldn't it make more sense for the RPi to send some command to the AVR - eg, via UART, SPI, I2C - to tell it the new value ... ?

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

awneil wrote:

A Raspberry Pi is a Linux computer: simply pulling the power while it's running is not a great idea - especially if you're planning on doing it on a frequent basis!

 

Thanks for the heads up. The external circuit is actually not powerering the raspberry off. Only on. The raspberry will make a controlled shutdown when needed. 

 

awneil wrote:

So why would you use the avrdude??

 

I dont necessarily want to use avrdude. With my knowledge on the subject, this was the way I could see it work.

 

awneil wrote:

Wouldn't it make more sense for the RPi to send some command to the AVR - eg, via UART, SPI, I2C - to tell it the new value ... ?

Great idea. Only problem is that all these ports are already in use on both the tiny and the raspberry. I could connect it to the I2C port on the raspberry, but I'm using the attiny24a, which (as far as I know) dont have any I2C pins.

 

Last Edited: Wed. Oct 18, 2017 - 08:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

So why would you use the avrdude??

 

 

May be because it is installed on RPi 's depos ... (and writing a value into the EEPROM was felt the easiest way to change a program's setting : an eeprom wears out 10 times slower than flash...). EEPROM can be read very easily with Arduino libraries; plain avr-libc http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html   has very easy to use documentation; a tutorial (with links to updated versions) can be found in this very site http://www.avrfreaks.net/forum/tut-c-using-eeprom-memory-avr-gcc?page=all

Remains avrdude configure to "only" send a byte into the EEPROM, without altering flash  : I always used avrdude as an Arduino blackbox, and giving an untested help would be more than miss Leading... (maybe specifying device should not be erased  and EEPROM should be written  -U eeprom:w:<fileWhereYouStoredValue is enough, from http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions

Last Edited: Wed. Oct 18, 2017 - 09:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lovepie wrote:
Only problem is that all these ports are already in use on both the tiny and the raspberry

You're not making any sense now..

 

You started out saying that you where going to utilize a connection between the AVR and the RPi to have them communicate. Now you argue that you can not have them communicate because there are no pins available.

 

Seems to me you are either stuck in some "thought-trap" or you're expressing yourself very unclear about the situation and what you want to achieve.

 

Heres one idea: Use the for bit-banged communication from the RPi to the AVR. The very simple thing communicated is the "timeout" before the AVR restarts the RPi. The RPi sends this timeout repeatedly, e.g. every second (or every ten seconds, or 30 seconds...).

 

Whenever the AVR has not heard such communication for certain period of time, e.g. one minute, it restarts the RPi.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

so I dont want recompile and flash everything just because some value changed.

Then you need an Intel hex editor in which you create a *.eep file and write (rewrite) the wanted value say to adr 2.

Then you write this file into eeprom using Avrdude.

 

In the code you read the eeprom value with

(uint8_t) value_on_eeadr_2 = eeprom_read_byte((const uint8_t*) 2);

 

Last Edited: Wed. Oct 18, 2017 - 09:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the *.eep file format (if it ASCII format, it might be trivial to generate one  with GNUlinux RPis tools/ a 10 liner C program)?

Edited : read https://en.wikipedia.org/wiki/Intel_HEX

Last Edited: Wed. Oct 18, 2017 - 09:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

.eep is an Intel hex file.

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

cross posted : sorry... It may be generated with awk or a 10 liner C/python program....

Remains something I do not understand : Has OP 's RPi enough lines-and the right ones... unless he uses a USB programmer : RPI have 4 USB plugs-to program his avr?

 

Edited :

USB programmers give all their sense to

 

You're not making any sense now..

RPi has 4 USB plugs ... -> can program AVR|AVR's EEPROM when it is needed (not always) .

For normal use, only one pin on the avr size and one (1*1; 1+0...) pin on the RPI connector are necessary.... No need to make things complicated

Last Edited: Wed. Oct 18, 2017 - 09:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The raspberry will make a controlled shutdown when needed. 

The trouble with your idea is that "controlled shutdown" does not mean "electrical shutdown"  : RPi keep on eating mAmps when shutdown, unlike PCs (if you add batteries, this might be annoying) and "disks" -cheap SD cards, on a SMD plug..- keep on being sync-ed after shutdown message -which is very annoying- . Automatigally waiting for 60-120 seconds after software shutdown would be interesting (though it is out of topic)

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

JohanEkdahl wrote:

You're not making any sense now..

 

You started out saying that you where going to utilize a connection between the AVR and the RPi to have them communicate. Now you argue that you can not have them communicate because there are no pins available.

 

Its probably me not being able to explain it correctly. When programming the ATtiny, the raspberry uses the linuxgpio programmer (bitbang). So its a software SPI. The reason for this is that its the only GPIO pins I have available. The SPI pins on the RPi are used for other things. 

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

dbrion0606 wrote:

awneil wrote:

 

So why would you use the avrdude??

 

 

May be because it is installed on RPi 's depos ... (and writing a value into the EEPROM was felt the easiest way to change a program's setting : an eeprom wears out 10 times slower than flash...). EEPROM can be read very easily with Arduino libraries; plain avr-libc http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html   has very easy to use documentation; a tutorial (with links to updated versions) can be found in this very site http://www.avrfreaks.net/forum/tut-c-using-eeprom-memory-avr-gcc?page=all

Remains avrdude configure to "only" send a byte into the EEPROM, without altering flash  : I always used avrdude as an Arduino blackbox, and giving an untested help would be more than miss Leading... (maybe specifying device should not be erased  and EEPROM should be written  -U eeprom:w:<fileWhereYouStoredValue is enough, from http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions

 

This was exactly what I had in mind to start with. Simply using the -U eeprom function in avrdude to write the value. And the have the attiny flash program read from the eeprom. 

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

dbrion0606 wrote:

The raspberry will make a controlled shutdown when needed. 

The trouble with your idea is that "controlled shutdown" does not mean "electrical shutdown"  : RPi keep on eating mAmps when shutdown, unlike PCs (if you add batteries, this might be annoying) and "disks" -cheap SD cards, on a SMD plug..- keep on being sync-ed after shutdown message -which is very annoying- . Automatigally waiting for 60-120 seconds after software shutdown would be interesting (though it is out of topic)

 

Well, when the RPi is shut down, the Attiny will send a signal to an external circuit cutting all power the RPi. So there is no shut down power usage.

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

Well, if it works, it is a great idea -and useful one : waiting for 1|2 min for disks to be -maybe-  synced is uncomfortable- if it works (i.e there are no SW bugs, wires + transistor and relay do not break...)

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I first read this thread I thought "this idea sounds mad" but given the limitations you outlined it actually seems quite clever.

 

So you say:

lovepie wrote:
If this is right, how would the variable be written with avrdude and how would it be read from the avr program?

Starting with the last (easy bit!) first can we assume that the use of Rpi+Linux for development means you are using the avr-gcc compiler to write AVR code? if so then the EEPROM functionality available is documented here:

 

http://www.nongnu.org/avr-libc/u...

 

By way of an example:

#include <avr/io.h>
#include <avr/eeprom.h>

int somevar;

int main(void) {
    somevar = eeprom_read_word(0);
}

That will simply read the 2 bytes ("word") at EEPROM location 0 and put it into a RAM variable called "somevar" to be used.

 

So that's how the program might read from the EEPROM. Now there is a question of how you get the value you want into the EEPROM and located at address 0.

 

My example used eeprom_read_word() to read an "int" value to demonstrate using multi-byte variables. Now say the value you want to convey to the AVR is 12345. What you might do is write a second C program:

#include <avr/eeprom.h>

int theValue EEMEM = 12345;

(nothing more, just that). Now build this as:

C:\SysGCC\avr\bin>type eedata.c
#include <avr/eeprom.h>

int theValue EEMEM = 12345;
C:\SysGCC\avr\bin>avr-gcc -c -mmcu=atmega16 -Os eedata.c -o eedata.o

C:\SysGCC\avr\bin>avr-objdump -s eedata.o

eedata.o:     file format elf32-avr

Contents of section .eeprom:
 0000 3930                                 90
Contents of section .comment:
 0000 00474343 3a202847 4e552920 352e332e  .GCC: (GNU) 5.3.
 0010 3000                                 0.

So I have managed to create a file called eedata.o that has just two sections in it. You can ignore ".comment" (literally that) so the "meat" here is simply:

Contents of section .eeprom:
 0000 3930                                 90

The value that is showing is 0x3039 which is 12345 in hex. So I have a file with a section called .eeprom that contains 0x3039 - the data I want to convey. So all that remains is to extract this as a .hex (or more usually .eep) file that the programmer can use to put into the AVR. I do that as follows:

C:\SysGCC\avr\bin>avr-objcopy -O ihex -j .eeprom eedata.o eedata.eep

C:\SysGCC\avr\bin>type eedata.eep
:02000000393095
:00000001FF

The objcopy says "just pick up section .eeprom (that is -j)", the "-O ihex" says "write out in Intel Hex format". eedata.o is the file I just got from compiling eedata.c and eedata.eep is the file I created.

 

In Intel Hex all files end with:

:00000001FF

which is just a "type 01" record to say "end of data" so the actual data in this file is:

:02000000393095

which is easier to read if you split it into sections:

:02 0000 00 3930 95
 |  |    |  |    |
 |  |    |  |    checksum
 |  |    |  the data (0x3039)
 |  |    record type 00 = data
 |  destination address
 number of data bytes

So I have created an Intel Hex file you can pass to your programmer and tell it to put it into the EEPROM of the AVR.

 

Ultimately the programmer will put 0x39 in EEPROM location 0x0000 and 0x30 in EEPROM location 0x01.

 

Finally when you run the code generated from:

    somevar = eeprom_read_word(0);

the read word will read 2 bytes. One from EEPROM location 0x0000 (low byte) and one from 0x0001 (high) and combine them as a single int with the value 0x3039 = 12345

 

Things could be simpler still if it's just some 0..255 value you want to convey. In that case use "uint8_t" instead of "int" and read with eeprom_read_byte() instead of eeprom_read_word().

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

"This was exactly what I had in mind to start with. Simply using the -U eeprom function in avrdude to write the value. And the have the attiny flash program read from the eeprom. "

 

Well, avrdude seems to be very conservative (writes only if signature are detected) and user friendly (in a very weird, verbose  way), from what I saw on arduino... if something goes wrong, you are likely to get a diagnostic /a lot of diagnostics without irreversibly breaking avrs.... Its documentation is most likely to be consistent with real working .

 

But was/is  the object of your post:

 

a) having avrdude work on your RPi for "only" EEPROM writing (only solution  is to check the -U option, or to wait until someone swore (s)he already tested it /found a better one)?

 

b) reading a EEPROM byte from avr -Visovian gave the answer, consistent with documentation and tutorials-?

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

@clawson

 

Excellent answer. It was something like this I original had in mind (without have the technical details in place). Thank you for this.

Last Edited: Wed. Oct 18, 2017 - 11:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson wrote :

the use of Rpi+Linux for development means you are using the avr-gcc compiler to write AVR code?

Rpi use an old -4.8- version of avr-gcc (it can be upgraded, but I did not dare yet: once it is upgraded, how can I test it).

This has no influence on OP's needs.

 

This idea is not a mad idea at all : some RPi are used to take photos; awaking them every 10 minutes (or when sun is set) is useful. People can find out tens of other users... and I am glad it is solved (and having understood how avrdude can work for parts of a program).

 

Having powers shut properly *after* lousy disks are synced (would need an extra pin) is very useful (solutions involving capacitor discharge exist: as capacitors age, I felt they were worse than what they were intended to correct)...

 

I wrote RPi "disks" are lousy : to be fair, compiling small pieces of code (avr; opencv examples -not libopencv itself - ; R -30 M, every 6 months-) does not break them, as far as I could see... but I try not to wear them out/shut down wildly.

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

The "mad" bit was using ISP (and then EEPROM) as the "communications channel" when more normal choices for PC (effectively what Rpi is) to AVR communication would be UART or USB or something. But if the ISP lines are there and pretty much all there is then using them for this secondary purpose is "interesting".

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

I actually had another thought. 

 

So I'm using the SPI lines (on the Attiny) to program the device from the Raspberry. This is done by bitbanging through avrdude (linuxgpio). But the device software does not need to be "flashed" very often, only on changes in the software code, which should not happen often. Could I use the SPI lines to make the attiny a SPI slave? I would then have to make a SPI master on the Raspberry, using the bitbanged lines to communicate with the Attiny. So the lines would be used for flashing with avrdude and then also SPI communication during normal operation. Then I dont have to use the EEPROM to write data, but simply handle everything in the code. 

 

Would this be possible as an alternative?

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

When I first read the OP, my thought was "alarm clock operation".  If a finite set of allowed values, a single button on the AVR device could cycle through the allowed values.  Or use two buttons.  Or put the buttons on an add-on device that you attach to the ISP pins when you actually reconfigure the device.

 

But, yeah--if you have a comms link put the value on every message packet just like a checksum.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

lovepie wrote:
Would this be possible as an alternative?

Yes. And note my previous comment. Let the RPi send a heartbeat to let the AVR know if it is alive or not. Rather than letting the heartbeat be a fixed value, just let it be the timeout the AVR should use to deem the RPi no longer alive. 

 

I didn't get that the SPI/ISP where steadily connected, so in my previous post I was thinking "of bit-banged UART". Now, if you already have SPI comms up and working then that's the obvious choice.

 

Note: If you want to make the whole setup more fails-safe when it comes to power failures, then you might still want to write the timeout value to the EEPROM of the AVR, so that it can pick the initial value up from there at startup, rather than waiting for something that might come from the RPi. The AVR application can do that writing whenever it sees a value from the RPi that is different from the one in EEPROM. In fact, aavrlibc has EEPROM update functions that do just that - actually write the value only if the new value is different from the present. Minimizes EEPROM wear.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Oct 18, 2017 - 01:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tnx @JohanEkdahl

 

I think I get it now, sorry for not fully understanding your idea when you posted it. Initially I just figured I couldn't use the SPI pins as they where "occupied" by the ISP (avrdude).

 

Tnx all for your help :-)

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

The downside of using SPI between Pi and AVR is that unlike avrdude (that already has linuxgpio) you are going to have to write some brand new Pi software to do something very similar to linuxgpio.

 

I actually still like the ISP to the EEPROM idea as long as you don't envisage extremely regular changes (like 100,000 over the lifetime of the AVR). If it was to be changed that regularly there is a possibility to "wear out" the EEPROM in the AVR.

 

But otherwise your original idea is probably the simplest to implement. As I showed, you Rpi already has all the tools you need to create the EEP data you might want to send.

 

You could even put a Python script around the whole thing with some pretty Tkinter input/output so the user gets to drag a slider or something to set the time. They click a "burn to AVR" button and the Python now auto-generates an eedata.c file, invokes avr-gcc and then avr-objcopy on it and then even invokes avrdude to burn it to the AVR. The user is never aware that it is doing ISP or anything like that.

 

BTW in Python it would be possible to generate Intel Hex directly and cut out the C compiler and objcopy. (I've done the same for Motorola SRecord). Looking around it appears there is this: https://pythonhosted.org/IntelHe...

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

Huge advantage of using EEPROM is that settings are not lost when avr is powered off (and it takes "only" one line of extra code, reading a byte from (a) serial /I2C stuff/SPI -used by cheap RPi screens and ADC -  line(s) and storing it into eeprom -to keep it at power off-  is way longer )...

 

Edited : read posts w/r SPI; added italics (there is amaximum 2 SPI ports on the RPi, unless things become very complex- -> using SPI if not needed :{screens must refresh quickly and are often felt useful; ADC should be read quickly, if one needs it}  looks like a bad idea in the general case).

Edited : Thanks Clawson for the link to autocreation of Intel files.

Last Edited: Wed. Oct 18, 2017 - 02:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I sort of assumed that however the selection was delivered OP would be storing it away with an eeprom_update_XXX() anyway.

 

The ISP mechanism has the advantage that "it's already there" without having to do anything specific to get it written.

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

clawson wrote:
I sort of assumed that however the selection was delivered OP would be storing it away with an eeprom_update_XXX() anyway.

Me too (see last paragraph in my #26.)

 

clawson wrote:
you are going to have to write some brand new Pi software to do something very similar to linuxgpio.

Are you referring to SPI as such? Then: https://www.raspberrypi.org/docu...

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
Are you referring to SPI as such?
Yes but you are still going to have to write code to drive that.

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

Are you referring to SPI as such? Then: https://www.raspberrypi.org/docu...

One should be careful with documentation: the link is not uptodate (refers to BCM2835 as processors; one cannot find new RPIs, except RPI3  -BCM2837, released in feb 2016 - and bet they are compatible). This was found on the page you linked to :.

The following information was valid 2014-07-05.

 

 

OTOH, if one worries on the avr EEPROM wear. Suppose one changes timer settings every 10 minutes -this is not an unrealistic value : it takes maybe 1 minute for a RPi to start- . EEPROM can be written 100 000 times, IIRC : leads to 1E6 minutes, about two years. (and updating flash, ten times less write cycles,  at the same lapse would only last 2 months).

If one thinks two years are not long enough, what would happen if one

 

read EEPROM until it is the "init" value (becomes a forbidden one)  -255-  before any operation

 

and either

keeps the last authorized value  if one wants to read

write into the first forbidden value (if flash is full; erase it and write at the first place).

 

I suppose flash would last somewhat longer (may be, if it is 100 bytes wides, it would last ... 200 years: one -and the rpi...-  should manage to live long enough to see whether this idea is wrong)....