Electron Carrier Board

@dkryder,

Thank you for taking a look at what is becoming the worlds longest thread.

At this point, if initialization fails it goes to ERROR_STATE and then resets in 30 seconds. Whenever the device is reset, the state is reset to INITIALIZING_STATE. The REPORTING_STATE is only for sending the data to Ubidots via a Webhook. But, if initialization fails, there is nothing to send.

One issue your comment brings out, perhaps I should publish some information on why initialization failed…

Is this what you are getting at or did I miss your point?

Thanks,

Chip

yes chip, that was my concern. the way you have the diagram it looks as if all errors are auto accepted as reset success that get sent to idle. what happens to if init fails & subsequent reset fails, it would end up infinite loop of reset-fail

@chipmc So do you think the FSM layout is good or do you think it’s painful and somewhat confusing to implement regardless of it being a recommended method of formatting?

@RWB, FSMs are not a method of formatting. They are a method of coding for a systems with definable, mutually exclusive states. This covers 90+% of microcontroller applications IMO. Most programmers implement FSMs without realizing it, using a (often convoluted) arrangement of if/else statements and a bunch of variables!

2 Likes

@dkryder,

Right, at this point, if the initialization failed the system would reboot until it succeeded. Putting the finite state machine aside for a minute, what should the behavior be? If the soil moisture sensor fails to initialize, then how will the system know whether to water? I need to think about this as I know the current approach is not optimal.

Chip

@RWB,

I think this has been a very useful exercise and one I plan to use in other projects. There are a few particular benefits:

  1. When troubleshooting, if you know the state of the machine, you can narrow your search for the problem to a specific piece of code where the problem will be.
  2. The exercise of creating the state diagram forced me to think about exactly what I wanted the code to do and provided structure that made coding easier. I simply wrote the code for each state once the overall flow was set
  3. When I want to add more functionality, it can be done cleanly as a new state or a modification of an existing state. This should keep the code from getting too complex over time.

I think it has been worth it and I suspect this will be even more true over time.

Thanks,

Chip

1 Like

@chipmc, glad to hear your impressions!

As for the ERROR state, I believe you need to now think about the user experience, whether it’s your own or for a product owner. If the water sensor has failed, ideally the user is made aware of this, either visually (flashing LED with color or blinking codes or a small OLED) or digitally via SMS, email, etc.

Hardware faults, whether temporary (a reset fixes the problem) or permanent (true hardware failure) is one of THE sources of concerns in commercial and industrial systems. Other failure modes include intermittent or unreliable values. All this to say that you need to think about how a sensor/device can fail, what the likelihood of that failure is (MTBF), how you could recover from the failure (power off/power on, reset, etc) and what is feasible for your product. Then, design your hardware and software accordingly. Your board already has some great resiliency protection for the Electron.

In the case of the soil moisture sensor, besides rebooting, your only other option for recovery may be powering the sensor off then on using a MOSFET or other power control device. If that doesn’t work, then put the system in a safe mode (turn off the water) and enunciate the error to the user, perhaps on a daily interval, until the unit is attended to.

I doubt MTBF is available for that moisture sensor so you will need to assume. In the end, if you design the product to be user serviceable then you could offer replacement parts ($$). Or offer a whole-unit swap (again $$). In either case, the user needs to know of the failure.

1 Like

chip, i’m guessing if there was a error state you would want to know so if you had a method for tabulating errors, and decide after a set number of errors there should be a notice sent, like after 5 reset sequences, then the owner of the system would know something was amiss. my concern was that there was no notification process in place for multiple resets.

By formatting, I meant a method of laying out your code into a structure. As you said most people are already doing this in some fashion without knowing it.

I was getting the impression from his post that he was a bit confused / frustrated on what exactly to do so that it was correctly laid out.

It’s good to hear that he finds it beneficial and worth the time invested. We are programming mini computers here so I guess we shouldn’t expect everything to be simple and easy to understand the first time around.

I’m learning by following along and it’s interesting.

1 Like

@RWB, @chipmc, you may want to read through this five part series on FSMs. I haven’t had time to look at their state chart drawing tool (Yakindu) yet. :wink:

2 Likes

@peekay123,

Thank you for the link. I like the way that this tool links the state diagram to code-generation. I will see if I can get a copy and give it a try.

Thanks,

Chip

1 Like

The overall concept of FSM makes sense to me but I can also say that I can relate to this guys comment at the bottom of that article :slight_smile:

excellent observations!

Couple more:
4) when transitioning from state X to state Y you can publish an event or log a message, so you know exactly when (and perhaps why) a transition is triggered.

  1. if you use an FSM library, like this one ported from Arduino, you have access to state enter and exit functions that can be useful to set things up while entering/leaving a state. It also tells you how much time the FSM has been in that state,

  2. when you start coding with FSMs in mind you don't really know what you are doing but you try it and most probably you'll stick with it since you'll like it so much

  3. if your code has a variable called state or status then is very probable that you are using an FSM but you did not know.

  4. the two links I had fun reading and finally got me into using FSMs:

this one:

and this one:

I'd say try one once and see, you won't regret :wink:

4 Likes

@gusgonnet, great comments and links! I’m a big proponent of FSM’s especially when working with FPGA design. Maybe it’s worth starting a new topic with just this FSM stuff.

2 Likes

good idea, done!

2 Likes

All,

I have finished documenting this carrier board and publishing it on HAckster.io. You can see it here: https://www.hackster.io/chipmc/particle-electron-carrier-for-outdoor-iot-applications-40ed52

Hope this is helpful.

Chip

3 Likes

Traffic data for the parks seems like a great idea and very useful to them.

How did you approach them about doing this? What has their feedback been about this new data resource?

1 Like

Hi @chipmc,
I’m going to get a board or two, is there a resource you know of that will make and populate these?
I’m not sure I’m up to the task of the SMT assembly
J

@jimbol,

Great news. I can help you with the assembly or get a friend of mine to do it. Because I am doing these one at a time, it takes me about an hour to assemble and test a board. Send me a DM and we can see if we can agree to a fair deal.

Thanks,

Chip

@peekay123 and @Suprazz, do you happen to have any sample code you wouldn’t mind sharing with me for SPIFFS beyond what’s in https://github.com/Suprazz/downloadFile?

I have Micron SPI NAND flash which says its interface is the same as for SPI NOR; maybe that’s already the answer to my problem described below but I am hopeful that I can use SPIFFS or another Particle-ported SPI Flash library. Do you think I stand a chance at getting SPIFFS (or anything) to work on SPI NAND with my Electron? I really like the idea of using embedded FRAM, flash, EEPROM for mechanical resilience as you’ve pointed out before, @peekay123, but need something in the 100+ MB range.

Following this thread and your response to my post a few weeks ago here, I have tried heading down that route but can’t yet get anything other than “Flash init error”. I set my chip select pin in the application.ino using if (flash.begin(D2)) as I’m not using the default CS; all other SPI defaults remain (SCK => A3, MISO => A4, MOSI => A5 for my Electron).

Thanks in advance for any pointers you’re able to offer!