I can program the moteino with stock fuse settings no problem via Arduino IDE.
I've uploaded fuse settings using rasperry pi GPIO pins and avrdude to use the 8Mhz internal oscillator.
Fuse settings:
l:d2
h:dc
e:fd
I've added a section to boards.txt:
Moteino8m.name=Moteino8m
Moteino8m.upload.tool=arduino:avrdude
Moteino8m.upload.protocol=arduino
Moteino8m.upload.maximum_size=31744
Moteino8m.upload.speed=57600
Moteino8m.bootloader.low_fuses=0xD2
Moteino8m.bootloader.high_fuses=0xDC
Moteino8m.bootloader.extended_fuses=0xFD
Moteino8m.bootloader.path=Moteino/DualOptiboot_V5.0_atmega328_BlinkD9.hex
Moteino8m.bootloader.unlock_bits=0x3F
Moteino8m.bootloader.lock_bits=0xCF
Moteino8m.build.mcu=atmega328p
Moteino8m.build.f_cpu=8000000L
Moteino8m.build.core=arduino:arduino
Moteino8m.build.variant=arduino:standard
Moteino8m.build.board=AVR_MOTEINO
##############################################################
When i try to upload the same sketch using the Moteino8m board via Arduino IDE and FTDI adapter on /dev/ttyUSB0 I get
avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/usr/share/arduino/hardware/tools/avrdude.conf"
User configuration file is "/root/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB0
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: S [53]
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x53
avrdude: Send: 0 [30] [20]
avrdude: Recv: t [74]
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x74
avrdude: Send: 0 [30] [20]
avrdude: Recv: a [61]
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x61
avrdude: Send: 0 [30] [20]
avrdude: Recv: r [72]
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x72
avrdude: Send: 0 [30] [20]
avrdude: Recv: t [74]
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x74
avrdude: Send: 0 [30] [20]
avrdude: Recv: [20]
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x20
avrdude: Send: 0 [30] [20]
avrdude: Recv: n [6e]
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x6e
avrdude: Send: 0 [30] [20]
avrdude: Recv: o [6f]
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x6f
avrdude: Send: 0 [30] [20]
avrdude: Recv: d [64]
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x64
avrdude: Send: 0 [30] [20]
avrdude: Recv: e [65]
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x65
Something I'm missing?
Has the bootloader been compiled for 8mhz and 57600 baud? The default is likely 16mhz and 115200 baud.
Joe
Quote from: joelucid on April 27, 2016, 02:51:12 PM
Has the bootloader been compiled for 8mhz and 57600 baud? The default is likely 16mhz and 115200 baud.
Joe
The dual OptiBootloader will autoswitch baud rate. You don't need to rebuild it for 8MHz or a specific baud rate.
The settings look good to me, but I'll post my boards.txt file tomorrow when I get back to my office.
Tom
This round goes to joelucid.
make AVR_FREQ=8000000L BAUD_RATE=57600 atmel328p
...did the trick. Wonder why auto-switch baud rate didn't work?
QuoteThe dual OptiBootloader will autoswitch baud rate. You don't need to rebuild it for 8MHz or a specific baud rate.
Looking at the source code I don't think that's correct. There are several references to F_CPU and BAUDRATE. Now running a 115200 / 16 MHz binary on a 8 MHz Moteino might actually give you something that works with 57600 because both changes counteract each other. But one would have to look more closely than I have to see if that causes bad side effects.
If it's using delay functions, like _delay_ms(), these are pre-compliled using F_CPU so the delays would be a factor of 2 out.
Mark.
Quote from: joelucid on April 28, 2016, 12:27:55 AM
QuoteThe dual OptiBootloader will autoswitch baud rate. You don't need to rebuild it for 8MHz or a specific baud rate.
Looking at the source code I don't think that's correct. There are several references to F_CPU and BAUDRATE. Now running a 115200 / 16 MHz binary on a 8 MHz Moteino might actually give you something that works with 57600 because both changes counteract each other. But one would have to look more closely than I have to see if that causes bad side effects.
Curious. Almost ALL of my motes are re-fused for 8MHz and I still use the out of the box bootloader.
Here is the entry in boards.txt:
##############################################################
MoteinoLP.name=Moteino8MHz
MoteinoLP.upload.tool=avrdude
MoteinoLP.upload.protocol=arduino
MoteinoLP.upload.maximum_size=31744
MoteinoLP.upload.maximum_data_size=2048
MoteinoLP.upload.speed=57600
MoteinoLP.bootloader.low_fuses=0xE2
MoteinoLP.bootloader.high_fuses=0xDA
MoteinoLP.bootloader.extended_fuses=0x05
MoteinoLP.bootloader.path=Moteino
MoteinoLP.bootloader.file=DualOptiboot_V5.0_atmega328_BlinkD9.hex
MoteinoLP.bootloader.unlock_bits=0x3F
MoteinoLP.bootloader.lock_bits=0xCF
MoteinoLP.build.mcu=atmega328p
MoteinoLP.build.f_cpu=8000000L
MoteinoLP.build.core=arduino:arduino
MoteinoLP.build.variant=arduino:standard
MoteinoLP.build.board=AVR_MOTEINO
##############################################################
Just to put this in context, Felix's advice on September 20, 2014 was:
Quote from: Felix on September 20, 2014, 04:42:12 PM
If you change the resonator to 8mhz your code will run half as fast (or 50% slower). You would need to recompile the bootloader and then compile your sketches for 8mhz.
https://lowpowerlab.com/forum/index.php/topic,650.msg3821.html#msg3821
Looking at github, the last commit for dualoptiboot was September 3, 2014. So, presumably (?), Felix's same advice would hold today.
Unfortunately, it's a hassle.
@Tom From what you're saying, it sounds as though you've somehow managed to avoid that hassle, so it would be great if you could perhaps run through an example, in detail, of your own particular conversion process so that everyone else can also avoid the hassle too.
I took Tom's MoteinoLP definition and put it into my boards.txt file. When I used that board definition to upload a blink sketch I received a programmer not responding error, similar to what @davegravy posted. I then changed the MoteinoLP.upload.speed to 115200 and that worked. The led blinked every 2 seconds. In the sketch I used delay(1000), so that seems to make sense since it's running at 1/2 speed. Is this one way to deal with the slower speed if you use some delay() calls in your code? http://playground.arduino.cc/Code/Prescaler
Quote from: ssmall on May 01, 2016, 06:30:15 PM
I took Tom's MoteinoLP definition and put it into my boards.txt file. When I used that board definition to upload a blink sketch I received a programmer not responding error, similar to what @davegravy posted. I then changed the MoteinoLP.upload.speed to 115200 and that worked. The led blinked every 2 seconds. In the sketch I used delay(1000), so that seems to make sense since it's running at 1/2 speed. Is this one way to deal with the slower speed if you use some delay() calls in your code? http://playground.arduino.cc/Code/Prescaler
You didn't say that you also changed the fuses to 8MHz internal clock. Did you? With the fuses as I've cited and the boards.txt file I've posted I haven't had to change anything to get accurate delay() times and my uploads work reliably (other than the occasional failure when I forget to attach the battery ::)
The prescaler library you've posted is useful as I do sometimes drop the 8MHz to 1MHz to minimize processor current (mostly when running from a coin cell). Thanks!
Tom
@Tom: I just copied the entry you posted for MoteinoLP. I assumed that changed the fuses. What do I need to do to change the fuses?
Quote from: ssmall on May 01, 2016, 06:58:44 PM
@Tom: I just copied the entry you posted for MoteinoLP. I assumed that changed the fuses. What do I need to do to change the fuses?
Ah, ok, makes total sense now. Your Moteino is still running at 16MHz external crsytal so the boards.txt section will be incorrect settings.
To 'burn' the fuses, you will need to hook up a device that uses the 'ISP' interface (this uses the SPI pins in a special way). I use a Pocket AVR Programmer from Sparkfun: https://www.sparkfun.com/products/9825 Others don't think this is 'reliable' enough, but I've never had a problem (you do need pullup resistors on all the native SPI device CS pins). I've made a pogo pin adapter for a Moteino card (it requires about six real pins and a couple of corner pins for physical support). Sparkfun has a pretty good tutorial on using the board and how to hook it up under a variety of situations.
Tom
Thanks for the help Tom. I knew it couldn't be that easy. I will look over documentation on the programmer.
I purchased the Pocket AVR Programmer from Sparkfun: https://www.sparkfun.com/products/9825. Using an Arduino Uno I have, I was able to follow the tutorial and program the Arduino with a sketch and read the fuses with the AVR Programmer. :)
For my next step I would like to try and read the fuses on a Moteino. After reading different posts in the forum, I know I should not use the AVR Programmer to power the Moteino and I need a 10K pullup resistor on D10. How should I power the Moteino? I am assuming that the AVR Programmer is 5v so I need to do logic level conversion? :o
Quote from: ssmall on May 15, 2016, 04:21:51 PM
I purchased the Pocket AVR Programmer from Sparkfun: https://www.sparkfun.com/products/9825. Using an Arduino Uno I have, I was able to follow the tutorial and program the Arduino with a sketch and read the fuses with the AVR Programmer. :)
For my next step I would like to try and read the fuses on a Moteino. After reading different posts in the forum, I know I should not use the AVR Programmer to power the Moteino and I need a 10K pullup resistor on D10. How should I power the Moteino? I am assuming that the AVR Programmer is 5v so I need to do logic level conversion? :o
You will find that there is a switch on the pocket programmer that selects 'PWR/No Power'. Set it to 'No Power' meaning that the device being programmed supplies its own power.
I would recommend supplying some voltage > 3.4V to Vin on the Moteino so that you have a nominal 3.3V supply AT the processor.
In this case, when the ISP pins are wired correctly to a Moteino, the 3.3V pin should be connected to the Pocket Programmer's '5V' signal (it should be named PWR, not 5V) and the level translator on the Pocket Programmer will supply 3.3V signaling to the 328P on the Moteino. The 10K pullup should be tied to 3.3V also.
Makes sense?
Tom
Tom, it all makes sense. When I have time in the next few days I will try it out. Thanks for helping out a n00b. ;D
Tom, I hooked up my voltmeter to the 5V pin and ground on the programmer. When the switch is in the No Power position I read 3.87 volts. When I move the switch to Power Target I get the expected 5v. Does that sound correct? I'm trying to go slow here and not fry anything.
Never mind. I did a few more tests and I was able to hook up the programmer to the Moteino and I was able to read the fuses:
lfuse:DE
hfuse:DC
effuse:05
Looks like avrdude reverses the hfuse and efuse when it prints them out after exit.
Are these the proper fuse settings to switch to the internal oscillator:
l:d2
h:dc
e:fd
Quote from: ssmall on May 17, 2016, 08:19:34 PM
Tom, I hooked up my voltmeter to the 5V pin and ground on the programmer. When the switch is in the No Power position I read 3.87 volts. When I move the switch to Power Target I get the expected 5v. Does that sound correct? I'm trying to go slow here and not fry anything.
Never mind. I did a few more tests and I was able to hook up the programmer to the Moteino and I was able to read the fuses:
lfuse:DE
hfuse:DC
effuse:05
Looks like avrdude reverses the hfuse and efuse when it prints them out after exit.
Yes, good conclusion. This took me by surprise the first time I saw it as well.
Quote
Are these the proper fuse settings to switch to the internal oscillator:
l:d2
h:dc
e:fd
Use the AVR Fuse calculator to determine your correct fuse settings: http://www.engbedded.com/fusecalc/
Tom
Tom, I took a look at the AVR Fuse calculator and was immediately overwhelmed after I selected ATmega328P. :o
I saw at the bottom of the page there are the fuse settings. I was able to type in the current Moteino fuse settings: L:DE, H:DC, E:05. After hitting "Apply Values" I went to Features and chose the default: Int. RC Osc. 8Mhz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65ms; [CKSEL=0010 SUT=10];
This resulted L:E2 H:DC E:FD
This is a stock R4 Moteino. Does that look reasonable?
Looks reasonable to me.
One last question. Do the fuses I set via the AVR programmer need to match what I set up for a 8Mhz Moteino in the boards.txt. Thanks
Quote from: ssmall on May 18, 2016, 02:21:30 PM
One last question. Do the fuses I set via the AVR programmer need to match what I set up for a 8Mhz Moteino in the boards.txt. Thanks
More like the other way around, but if you're not burning the fuses via the IDE, it probably doesn't matter what's in the boards.txt file.
Tom
Sorry for reviving such an old thread, but I don't seem to find the consensus here and I want to do the same: using the internal 8 MHz clock with the Moteino and DualOptiBoot.
So far I assume:
- fuses need to be set properly for internal osc.
- DOB needs to be recompiled with 8 MHz settings <-- this is the point that is not clear as it apparently worked for Tom without recompiling but not for others
- Arduino picks up settings anc compiles everything for the pre-set clock rate
If the second point is "recompiling needed", would anyone be kind and share their .hex file? Would be most appreciated.
Quote from: kobuki on June 15, 2017, 04:41:05 PM
Sorry for reviving such an old thread, but I don't seem to find the consensus here and I want to do the same: using the internal 8 MHz clock with the Moteino and DualOptiBoot.
So far I assume:
- fuses need to be set properly for internal osc.
- DOB needs to be recompiled with 8 MHz settings <-- this is the point that is not clear as it apparently worked for Tom without recompiling but not for others
- Arduino picks up settings anc compiles everything for the pre-set clock rate
If the second point is "recompiling needed", would anyone be kind and share their .hex file? Would be most appreciated.
I'll stand by my claim. I've never built the bootloader and ALL of my Motes run at 8MHz.
However, for full disclosure, I'm not using that bootloader any more... Not because of issues with it, but features found elsewhere.
Tom
OK, thanks, I'll test it without recompiling first.
May I ask, what bootloader you use instead of DOB and what features they provide?
Quote from: kobuki on June 15, 2017, 08:13:00 PM
OK, thanks, I'll test it without recompiling first.
May I ask, what bootloader you use instead of DOB and what features they provide?
I'm not at liberty to say, but, if you think about it, you might be able to guess. And I still run at 8MHz because I don't need an external timing element if I do. It's not about about parts count as much as it is space and power savings.
Tom
OK, I understand. I can guess, but would prolly miss.
I'm more interested in the features and the possibility to use them in the future (if they sound useful). That is, if you're at liberty to say.
I would imagine that he has a copy of joelucid's unsupported and unavailable bootloader which does seem to have quite the feature set.
Yeah, it was mentioned several times but that's admittedly hard to use properly for a stable setup and only about 2 people were able to use it succesfully. That's what I recall at least. So I guess it's not some personal experimental project bootloader but an actual stable, full-blown bootloader under some kind of NDA, judging from the answers. A good stable OTA loader - without requiring extra components like a flash chip - would be nice. That's what I'm interested in, should one exist somewhere.
But we're starting to drift from the main topic a bit.
I did not need to recompile the bootloader. I used the fuse settings referenced earlier in the thread and the Moteino8Mhz that Tom, I think, specified to use in boards.txt. If you are using an older version of avrdude the High and Extended fuses are reversed in the print out. The latest version of avrdude fixed the issue.
When I use dualoptiboot derived bootloaders I do recompile them for 8mhz. The reason is that the serial baud rate clock is generated internally based on the system clock and the UBBR register which is programmed according to F_CPU. If you don't recompile it should still work but at half the baud rate specified at build time.
Timeouts are generated by the WDT so for them no recompile is necessary.
Joe
OK, thanks, so you mean to say I need to set half of the BR for programming with 8 MHz compared to 16 MHz to be able to use the same real BR. That sounds reasonable. Well, if I rely on the OTA functionality it would be alright I guess but otherwise it still is recommended to recompile so an initial FW for testing is uploadable via serial. Is that right?
Also any delays like delay_ms() will also be dependent on F_CPU, so timeouts might not be as accurate. Blocking bit-banged interfaces that are timed with those delays will be out as well.
Mark.
Well, I think it's only relevant in the bootloader, since the sketches are a separate compile phase, using settings for 8 MHz operation so no change is expected in timing constants there. Or do you mean to look out for the relative inaccuracy of the internal RC osc?
Quote from: joelucid on June 17, 2017, 12:50:57 AM
...The reason is that the serial baud rate clock is generated internally based on the system clock and the UBBR register which is programmed according to F_CPU.
F_CPU tracks the fuse settings. Without changing the bootloader, F_CPU reads 8000000 on my Motes. I know this because I used to print F_CPU when I was first testing battery operated Motes just to confirm that I had set the fuses correctly (Don't ask me why I needed to do this... ;)
Tom
Quote from: TomWS on June 17, 2017, 08:59:37 AM
F_CPU tracks the fuse settings. Without changing the bootloader, F_CPU reads 8000000 on my Motes.
That is expected in a sketch but in the bootloader F_CPU is a #define provided in the Makefile so indeed, to fix it a recompile is needed. Or one can live with the fact that serial speeds need to be adjusted but the rest of the bootloader works as expected. I think I'll just compile a variant for 8MHz.
EDIT: well, for normal sketches F_CPU is most probably also a define in the build environment but considers the target settings which should use a 8 MHz clock setting for this kind of usage - bootloader was compiled with F_CPU=16MHz, sketch is compiled with F_CPU=8MHz.
F_CPU is normally either a #define in the source, or set in the IDE and ultimately sent as a -D parameter to the compiler. In any case I don't know how this can be set by fuses as the final F_CPU may depend on run-time settings like prescalers.
Mark.
Just finished compiling the 8MHz variant. I'm attaching the .hex, someone might find it useful.
Info:
- used https://github.com/Optiboot/optiboot as devenv, replacing optiboot.c with Dualoptiboot.c
- atmega328 target change: --section-start=.text=0x7c00
- command line: make atmega328 -e BAUD_RATE=57600 -e AVR_FREQ=8000000L
- used Arduino 1.8.1 and mingw tools on windows
I set the BR to 57600 to be safe.
Quote from: perky on June 17, 2017, 12:53:12 PM
F_CPU is normally either a #define in the source, or set in the IDE and ultimately sent as a -D parameter to the compiler. In any case I don't know how this can be set by fuses as the final F_CPU may depend on run-time settings like prescalers.
Mark.
Whoops. You're right, it is in the BOARDS file for the MoteinoLP (8MHz) I have: MoteinoLP.build.f_cpu=8000000L
Sorry about the misdirection.
Tom
Ha, don't worry about it 8)
Sorry for reviving such an old thread (©Kobuki)
I want to run moteino (and moteino like) from LifePo4 without LDO, so between 3.6V and somewhere below 3V, and have to run at 8MHz.
If I run with internal 8MHz clock, could I save some place and remove 16MHz crystal ? (crystal pins should be unconnected or connected to ground or something else ?)
Internal clock is less precise, do you have an idea how much ?
Is it possible to use an external 8MHz crystal like with the 16MHz to keep relative precision on clock instead of the internal one in low voltage condition ?
Quote from: Uncle Buzz on July 27, 2018, 12:28:45 PM
Sorry for reviving such an old thread (©Kobuki)
I want to run moteino (and moteino like) from LifePo4 without LDO, so between 3.6V and somewhere below 3V, and have to run at 8MHz.
My standard configuration uses Lithium/Iron Disulfide (Li/FeS2) batteries (Eveready Ultimate Lithium) with fuses set to 8MHz internal, No BOD, and no external crystal (oscillator pins left unattached), and no VR - run directly off the battery for processor & radio.
UPDATE: The problem you'll have with LifePo4 is if you want to charge it while installed. In this case the voltage could exceed the maximum specified for the radio. While the Li/FeS2 batteries are not rechargeable, they last so long that they'll probably only need to be replaced once in the life of your mote (this is based on my well founded pessimism about mote lifespan primarily governed by corrosion or obsolescence).
Quote
If I run with internal 8MHz clock, could I save some place and remove 16MHz crystal ? (crystal pins should be unconnected or connected to ground or something else ?)
you can leave the crystal installed or removed, it doesn't matter - leave the pins disconnected if you have no crystal.
Quote
Internal clock is less precise, do you have an idea how much ?
Is it possible to use an external 8MHz crystal like with the 16MHz to keep relative precision on clock instead of the internal one in low voltage condition ?
It's good enough to run serial port reliably at 57.6K and certainly far better than the WDT. I don't rely on the processor clock for critical timing.
Tom
Thank you for your reply.
For LiFePo4, for low power board, I don't need to charge battery on the node, and for those with high power consumption, battery is isolated from the board while charging.
I need to use some SPI devices (at least the radio), is the internal RC oscillator accuracy sufficient in this case ? I could use an 8MHz resonator instead of the 16MHz, but those I found are with 30pF, it exceeds the 12-22pF from the datasheet, should I use a crystal + 2 capacitors instead (not possible on moteino) ?
Uncle Buzz,
Do you have specific SPI speeds of 4mhz or 8mhz? Or are you just "worried" the RC won't be precise enough?
I think you're fine with the internal RC, the library divides the SPI clock so at 8mhz it will be half that at 16Mhz.
I'm just worried.
I wonder how accurate is the timing from internal RC, for fast communication like SPI (but the moteino is driving the clock, so there's no problem with synchronisation), and for synchronisation between moteino, if I plan to reserve a window for each moteino to communicate with the gateway, how often will I have to resync the moteino with gateway to avoid collision.
Quote from: Uncle Buzz on July 31, 2018, 05:52:08 AM
I'm just worried.
I wonder how accurate is the timing from internal RC, for fast communication like SPI (but the moteino is driving the clock, so there's no problem with synchronisation), and for synchronisation between moteino, if I plan to reserve a window for each moteino to communicate with the gateway, how often will I have to resync the moteino with gateway to avoid collision.
SPI doesn't need to be accurate timing, it is totally synchronous so the clock edges can vary widely even between pulses.
IMO, the collision avoidance mechanism in the radio, combined with sendWithRetry(), is good enough to
avoid deal with collisions, but, of course, it depends on how you design your communication protocol. Make it very stiff and brittle, something will break it. Make it flexible and adaptable, you'll have more success with systems that tend to be somewhat stochastic.
Tom
UPDATE: Changed 'avoid' to 'deal with'.