Messages posted by: stevech

Yes, it's a struggle.

I have the a bootloader working on the mega328 and mega1284 with the Spansion SPI Flash chip. And other code I wrote writes to the flash the downloaded new firmware that was sent via RadioHead's stack on a gateway that connects via a RadioHead stack to a PC's serial port. Then that serial port link (datagram) goes on into a Python-coded version of RadioHead's stack, then into the applications which are GUI based Python. These apps manage all the radios and their configs and distribution of new firmware when needed. The end nodes send unsolicited status messages now and then and that includes what firmware version is in use - so the apps can know which ones need updates.

the entry to sleep doesn't command the radio to sleep, right? Its power stays on?
So the sleep mode is just the AVR microprocessor.

If these are true, then you might read the AVR specs and see if the SPI port needs to be reinitialized on wakeup

w1ll14m wrote:Hi Steve,

I have started playing around with the optiboot code. I have issues reading the SPI flash, I was hoping you could tell me how you read the SPI flash from within the bootloader?

Regards,
William

I have SPI code in the bootloader that does not use a library. It's small and tight.

I may soon have an agreement with Anarduino on this bootloader and possibly too, the more complex higher level protocols to send the firmware to network nodes using the RadioHead stack for the radio-hardware transparency under my application protocols and file transfer code. I still don't know how to prevent intellectual property theft when I choose not to make this open source. License agreements are not honored by most on our planet.

did you keep your receipt to show the part number ordered?

I've not used the radios of which you inquire, but the following applies to most all of HopeRF's modules/boards.

There are band-specific RF filter components (434,868,915) MHz bands on the board. The boards are marked as to which band these components are tuned. When soldered on to a board, this marking may be obscured, so you have to have otherwise marked them yourself, or you have purchasing documents/receipts that show which band you ordered.

The radios are tuned by software command; they're not tuned by internally fixed constants (e.g., firmware configuration).
If your software tunes a 915Mhz product to 868MHz, the penalty will be small, about 10%, so I've read.
Tuning this to 434MHz, or 315MHz, has a prohibitive degradation in transmitter power and receiver sensitivity - e.g., 20dB.
Vice-versa, tuning a 434MHz radio to 915Mhz.

In North America, the "915" MHz band refers to the ISM band spanning 902-928MHz, with 915Mhz being a default.

that's what I know.

Rick may have other insights.

steve

SadE wrote:Moreover I saw the 328P is not stated to work with 3.3V at 16Mhz.
It could work , maybe in 90% of cases, or could work at 25°C and not a 0° ...
An answer from the designer is widely expected !

328P does work for 16MHz at 3.3v but I've never tried it at the extremes of temperature specs. It may not work at 20MHz at 3.3 rather than 5V.

athtest800 wrote:Hello!
I use the RFM69HW Mini wireless.
I added an ST7735 LCD by using either the UTFT either the adafruit ST7735 library https://github.com/adafruit/Adafruit-ST7735-Library.
The result is 3-5 white(?) pixels that are shown on LCD. This is very ugly.
The problem appears with this function
if (radio.receiveDone()) with the LowPowerLabs https://github.com/LowPowerLab/RFM69 and
if (rf69.available()) with the RadioHead http://www.airspayce.com/mikem/arduino/RadioHead/.

What can i do to solve it?
Thank you.

The RadioHead driver, and probably also LowPowerLab's driver (independent software suites), the interrupt service routine (ISR) for the radio uses the SPI port. The ISR makes the assumption that it can use the SPI port at any time. When your LCD is using the SPI port, it can get interrupted by the radio's ISR and now we have a mess. The radio's ISR runs at the end of a transmitted or received packet.

The LCD software can disable interrupts while using the SPI port - that's brute force.
The LCD software can set the external interrupt mask bit for the radio's IRQ bit, while the LCD is using the SPI.
The LCD software can force the radio into its idle state (not receiving or transmitting cannot interrupt) - use the SPI port, then reenable the radio with a call to available()

ALso, there's an issue if the LCD and the radio want the SPI to be in different configurations, such as SPI clock frequency. Each device might initialize SPI at startup but do so differently.

This overall issue of SPI port-sharing, in the Arduino community, is known issue that arises because people develop drivers without think of SPI port sharing.

Paul at PJRC.com (teensy 3) has a library to manage SPI port sharing. But SPI-based devices have to use that library instead of the generic SPI library. The new library "SPI Transactions" is availble but slow to be adopted. It brings problems, too, such as: If some SPI-based device uses SPI Transactions to "own the SPI port" for a while, real-time devices like the data radios can on occasion miss an incoming message - if the port is "Hogged" too long. This happens at low SPI clock frequencies and/or large SPI transfer loops such as in an SD card.

So the 3 hacks, above, are all I can suggest.
This presumes that you do have a conflict with the radio's ISR as described above. If the LCD driver is already disabling interrupts while using the SPI, every time, everywhere, then there could be an issue with the two devices wanting the SPI bit rate or byte format to differ, and they don't reestablish the SPI port prior to each use. RadioHead only configures once.

jrbenito wrote:

stevech wrote:I don't now know of a way to control non-commercial use of such code - as there are commercial uses now.

suggestions welcomed.

By control you mean avoid the use or forbid it?

Regards,
Benito.

Control the use of code for commercial purposes - because in much of the world today, licensing agreements are ignored.

I don't now know of a way to control non-commercial use of such code - as there are commercial uses now.

suggestions welcomed.

the latests major addition is
Use the GUI on the PC to "ping all" in-range nodes.
They all reply in a time-orderly manner (rather than just mash-up collisions)
Now we have a list of radio/MCU nodes out there, the RSSI of each, the code version of each, etc.

Then you can click once to send new code to them all (assuming that's the right thing to do). Each has saved it's unique config in EEPROM.
The PC/Mac/Linux Python program then pushes the new code to each node in succession, with extensive error checking. Each node saves the downloaded code to SPI flash storage as in the MiniWireless boards.
The user then clicks "reboot all", and a command is sent over the air.
All reboot and the bootloader (mine) uses the SPI flash storage to rewrite AVR program memory with the new code. Then boot to run that.

Now the user on the computer clicks "ping all" and see all did come up OK and all have the correct code version.

Over the air reprogramming with automated gang programming, I guess you'd say.

I should make a demo video. But I'm such a dweeb at videos.

A mini variation with a U.FL antenna connector might be appealing due to size size, low cost.
Maybe the PCB could accommodate either. Some boards also have a hole for soldering in a loose wire, no connector.

Where needed, there are U.FL to SMA and N and others, of varying gender.
http://www.adafruit.com/product/851
http://www.balticnetworks.com/mikrotik-u-fl-to-n-female-pigtail-14-inch-36-cm.html?gclid=CLSEv_3wqMECFROTfgodSy8Ahg
http://www.l-com.com/coaxial-ufl-to-n-male-pigtail-20cm-113-mini-coax
In all these SMA connectors, mind the RP (reverse polarity) options.

There would be folks who don't want U.FL, because an onboard SMA might be used in a hole in an enclosure, as is.

Perhaps the "C" means pin-Compatible with RFM12

Miniwireless boards - RFM69 radio affixed.
Any way to visually identify for which band the radio is manufactured? The marking for such is not in view.

(other than running the radio and observing signal strength with a different radio).

Charly86 wrote:Steve,

Excellent idea, I never think it could work, only one in sync response, what a nice trick and idea

By the way I received these 7 ports USB hub with switch on each port. works amazing !!!!! even better of all I tested that do some disconnect on FTDI very often, never happened with this one, so happy, thank for the tip.

I do notice on my 7 port switched hub, the USB 5V line out on each port, light load, is 4.8V, not 5V. This does affect some things... like the JTAGICE3. So you can apply an additional 5V source and it will override USB 5V.

I've been using the gang bootloader and it works fine. Even with one of ten that mistakenly had the FUSES set to clock/8, so it had the 115200 baud rate for bootloading despite the fuse mistake.

I haven't read of this done before, but enclosed is a picture of 10 mega328P AVRs.
They are wired such that one run of the downloader updates all at once.
Almost silly, but the handshake responses in the stk500-like protocol are sent by just one of the 10. The other 9 serial TX pins are not connected.
But the timing works since all run the same clock and bootloader code.
The RX and DTR pins are daisychained.

I'm using this to speed development, while I'm improving my bootloader which does over the air (OTA) wireless remote reprogramming of the mega328s. That bootloader now does one at a time OTA reprogramming but not gang programming. I'm adding gang wireless remote reprogramming - because it takes too long to do these sequentially (non-gang). The tricky part is dealing with modules that get an error on wireless.

Anyway, the wired version of the gang reprogramming is simple.

Steve
photo:
https://plus.google.com/photos/102219196072599124106/albums/6068673010047626401?hl=en_US

I use these mostly, due to their convenient small size, but have used other FTDI boards with no issues.

http://www.anarduino.com/details.jsp?pid=149

w1ll14m wrote:Hi Steve,

This sounds very amazing, I was trying to mod dualoptiboot to work with the Mini-Wireless but in the process I might have killed my 2 nodes (issues with flashing a bootloader) and waiting for my next order to arrive.
Also I would love to hear some updates about this or if there's anything I can do to help, I would love to!

Thanks!

It's all working with the Miniwireless boards and RadioHead reliable datagrams, and using the connection PORTs in DXRP (see above video demo).
Python program for PC/Mac/Linux/RPi with GUI works well. It initiates the over the air reprogramming and exchange of other kinds of data e.g. logs.
The code to download the new program and store it in the SPI flash chip - works - I have yet to make it a class or module or something like that so it's easy to add to a user's app.

No radio on the board? It has to be configured to sleep.

at
https://groups.google.com/forum/#!topic/radiohead-arduino/macMGhURKQE

Testing high speeds with low cost HopeRF radios... FYI

http://forum.pjrc.com/threads/26688-Speeds-using-4-FM-FSK-data-radios-at-high-rates-with-Teensy3-and-AVR?p=55067#post55067

I very much like the cost and size of this FTDI USB/Serial which mates with the Mini-Wireless boards and has the standard pin arrangement.

http://www.anarduino.com/details.jsp?pid=149

I see, in RH_ASK.cpp, the default speed is 2000 bps and the RFM85 is supported using the MCUs timers.

"Baud rate" really doesn't apply here; that applies to a UART based serial mechanism with start/stop bits, etc.
A common use of UARTs is 8N1 meaning there are a little more than 10 bit times per 8 bit byte sent.

In all these radios, FSK, ASK/OOK, the data has no start/stop bits.
ASK in RH does code data to control the number of successive 1's and 0's.

As to KHz v.s. Kbps... KHz in your context is either the receiver bandwidth configuration or the transmitter's deviation setting.

So if you use the constructor's defaults, you'll see something like 2000 bps minus overhead of preamble and coding. This is a burst rate, not a sustained rate of course. And if you use reliable datagrams, there's the overhead of ACK responses.

I was out of town last week. Back at it now!

Anarduino.com was down for a while... maintenance or delayed reboot. So Rick must be loitering around here.

In the US, unlicensed 433MHz band is supposed to have severe transmitter-on duty cycle restrictions. Due to the myriad of one-way transmissions from wireless thermometers and the like.
But I'm a licensed Ham radio guy so I can go up a few MHz to the ham band and do what I please. Run hundreds of watts if I wanted to.

902-928MHz is the unlicensed band in the US and Canada; maybe Mexico (do they have an FCC?) It too has duty cycle restrictions - less severe that 433MHz.

In both unlicensed bands, with freq. hopping you can have a higher duty cycle. These radios can hop. But perhaps most radios like this have infrequent transmissions.

868MHz in most of the EU is unlicensed but far fewer MHz than the US 900MHz band.
And somewhere in the 900MHz band are the uplink/downlink for the EU's 2G cellular (GSM), licensed.

315MHz in the US is unlicensed and widely used for garage door openers with rolling code encryption.

There's a band in the US called MURS (multi-use radio service or some such). It's around 154MHz. Limited to 5KHz FM deviation, and for data only. I wish there were HopeRF or other cheap radio modules for MURS - as is, they are pricey. That band propagates better by far than 433 and up. I wonder of other countries allow 154Mhz to be used. that's just above the 2m ham band.

Here's a new Arduino program to test/demo the MCP7940RTC real time clock chip on the Anarduino Mini-wireless boards.
The program displays the millis() counts vs. elapsed seconds from the clock chip. It also sets clock interrupt alarms for 1, 2, 4, 8... seconds and prints elapsed millis on that too.

A gotcha I've not fixed is that an alarm in 1.0 second is not yet possible. The chip won't alarm unless the alarm time is in the NEXT second or later. So the millis for the first 1 second alarm is not exact. The millis for the other alarms is off by 2-3 mSec due to overhead in the MCP7940RTC library. That library needs a re-write, I think - has too much overhead and conversions - that take lots of CPU time and memory space.

I didn't change the MCP7940 library. But as described in the code near setup(), it needs a change so that one can declare a static instance of the class as is usually done for small RAM microprocoessors. As written, one must use new() and that uses malloc() which is more code and is not friendly to a 2KB RAM micro. See the comments for recommendations. Easy change.

Steve

screen grab of output from program

Port open
Startup...
Begin loop()
RTC time set to: 2014-01-02 03:04:00 (YY-MO-DD HH:MM:SEC
RTC read-backs for n secs:

mSec=1000 RTC:2014-01-02 03:04:01 5
mSec=2000 RTC:2014-01-02 03:04:02 5
mSec=3000 RTC:2014-01-02 03:04:03 5
mSec=4000 RTC:2014-01-02 03:04:04 5
mSec=5000 RTC:2014-01-02 03:04:05 5
mSec=6000 RTC:2014-01-02 03:04:06 5
mSec=7000 RTC:2014-01-02 03:04:07 5
mSec=8000 RTC:2014-01-02 03:04:08 5
mSec=9000 RTC:2014-01-02 03:04:09 5
mSec=10000 RTC:2014-01-02 03:04:10 5

Begin Alarm interrupt tests. Waiting for first interrupt in 1 second. Note the seconds part of the below...

Interrupt: 10 mSec elapsed. RTC:2014-01-02 03:04:02 5
Next Interrupt should be in 2 seconds

Interrupt: 2006 mSec elapsed. RTC:2014-01-02 03:04:04 5
Next Interrupt should be in 4 seconds

Interrupt: 4001 mSec elapsed. RTC:2014-01-02 03:04:08 5
Next Interrupt should be in 8 seconds

Interrupt: 8003 mSec elapsed. RTC:2014-01-02 03:04:16 5
Next Interrupt should be in 16 seconds

Interrupt: 16005 mSec elapsed. RTC:2014-01-02 03:04:32 5
2014-01-02 03:04:32 5

FINISHED BOTH TESTS. Loop() is returning

the code

/*
 * Anardino library use example for MCP7940N RTC using in Anarduino MiniWireless class products.
 * Steve Childress. Open source.
 * This code is mostly new. About 10% is from an Anarduino demo. The MCP7940 library needs a change as noted below.
*/ 
#include <avr/pgmspace.h>
#include <elapsedMillis.h>
#include <Time.h>
#include <Wire.h>
#include <MCP7940RTC.h>

#define LED_BUILTIN 9 // mini-wireless board LED pin #
#define LED_ON digitalWrite(LED_BUILTIN,1)
#define LED_OFF digitalWrite(LED_BUILTIN,0)

#define RTC_INTERRUPT_PIN 3                     // arduino hardware interrupt pin, (i.e, D3 for miniWireless)

#define YY 2014  // no need to change these; they're just used for testing. 
#define MO 1	//Note the number sequences for easy reading screens
#define DD 2
#define HH 3
#define MM 4
#define SEC 0

/* WARNING: the below one line of code tries to declare the usual static instance of the library class.
 * Because the library code for the constructor has a lot of I/O calls to the I2C library,
 * and these should not be made from a constructor, the static class instance is not used. Indeed, it hangs if you do.
 * Instead, a pointer is declared below (*RTCchip), and the class is created as non-static,
 * as a run time call to new(). This is not good on a 2KB RAM MCU as new() uses the heap and malloc().
 * The library should be changed to have an init() method and move the code out of the constructor and to the init().
 * The constructor also calls Serial.print which cannot be used in the constructor for a static class.
*/
//MCP7940RTC RTCchip; // static instance of class from Arduino Library cannot work; see above

MCP7940RTC *RTCchip; // see the call to new() and the comments above.

elapsedMillis elapsedms; // relatively new in Arduino

volatile boolean rtcInterruptFlag=0; // volatile:stevech
char buf[100]; // for printf

void setup() {
  pinMode(RTC_INTERRUPT_PIN, INPUT_PULLUP);     // INPUT also sufficient, if we have our own on-board discrete pullup
  pinMode(LED_BUILTIN,  OUTPUT);
  LED_ON;

Serial.begin(115200);
  while (!Serial)
	; // wait for OS if USB is on-CPU.

Serial.println(F("Startup..."));

RTCchip = new MCP7940RTC();  // see the comment block in setup() on this non-static class

attachInterrupt(1, ISRrtc, FALLING);
  
  setTime(HH,MM,SEC,DD,MO,YY);       // Set Arduino library system time (not RTC chip)
  
  delay(250);
  LED_OFF;
}

void loop() {
  int pass;
  int nextIntr;
  int n;
  uint32_t millisStart, mark;

Serial.println(F("Begin loop()"));
  
  setNewTimeRTC(YY, MO, DD, HH, MM, SEC);  // Set RTC chip time, (year, month, day, hour, minute, second)
  setTime(HH,MM,SEC,DD,MO,YY);       // Set system time (not RTC chip)
  
  sprintf_P(buf, PSTR("RTC time set to: %04d-%02d-%02d %02d:%02d:%02d (YY-MO-DD HH:MM:SEC\nRTC read-backs for n secs:\n"), YY,MO,DD,HH,MM,SEC);
  Serial.println(buf);
  millisStart = millis();
  elapsedms = 0;
  pass = 0;
  
  // read and display RTC every 1000 mSec, using CPU msec timer.
  for (pass = 0; pass < 10; )  {
    if (elapsedms >= 1000)  { // note >= in case of lost time
      ++pass;
      elapsedms -= 1000; // don't set to 0 so we can see any cumulative errors
      sprintf_P(buf, PSTR( "mSec=%04ld RTC:"), millis() - millisStart); Serial.print(buf);
      RTCchip->getDateStr(buf); Serial.println(buf);
    } // if
  } // for
  
  //return;
  
  Serial.println(F("\nBegin Alarm interrupt tests. Waiting for first interrupt in 1 second\n"));
  setNewTimeRTC(YY, MO, DD, HH, MM, SEC);  // Set RTC chip time, (year, month, day, hour, minute, second)
  setTime(HH,MM,SEC,DD,MO,YY);       // Set system time (not RTC chip)
  
  nextIntr = 1;
  setAlarmNextSecond(nextIntr);
  elapsedms = 0;
  
  // display elapsed CPU msec for each alarm interval 1, 2, 4, 8... seconds
  for (int i = 5; i > 0;  )  {
    if(rtcInterruptFlag) { // ISR's flag
        --i;
        mark = elapsedms; // make note before compute overhead below
        elapsedms = 0;
        setAlarmNextSecond(nextIntr *= 2); // set alarm then do printf work concurrently
        rtcInterruptFlag = false;  // reset flag 
        // Alarms will be 2-3 mSec late. Perhaps due to the high overhead in library setAlarm0() processing.
        sprintf_P(buf, PSTR("Interrupt: %d mSec elapsed. RTC:"), mark); Serial.print(buf);
        RTCchip->getDateStr(buf); Serial.println(buf); 
        if (i > 0)
          { sprintf_P(buf, PSTR("Next Interrupt should be in %d seconds\n"), nextIntr); Serial.println(buf); }
     }
     delay(10); // delay isn't essential
   } 
   Serial.println(F("\nFINISHED BOTH TESTS. Loop() is returning"));
   delay(5000);
}

void ISRrtc() {  // interrupt service routine, just set flag
  rtcInterruptFlag = true;
}

void setAlarmNextSecond(int seconds)  {
  uint8_t s = RTCchip->getSecond();   //get current second 0..59

if (seconds > 1)
    while (s == RTCchip->getSecond()) // for the sake of this test program, alarm on start of a second
      delay(1); // don't pound the RTC with I2C commands
  RTCchip->setAlarm0(now() + seconds);  // set next alarm time  
}

void setNewTimeRTC(int yr, int mo, int dy, int hr, int mn, int sec) {
  tmElements_t tm1;
  tm1.Year     =(yr-1970);
  tm1.Month     =mo;
  tm1.Day       =dy;
  tm1.Hour      =hr;
  tm1.Minute    =mn;
  tm1.Second    =sec;
  time_t t = makeTime(tm1);
  RTCchip->setTimeRTC(t);
}