Opinion poll, which WC8 feature set should be split into different firmware?

CAI_Support

Senior Member
Currently, the RAM on WC8 board is low, to continue developing additional features for WC8, we need to develop few different firmware sets for users to pick and choose which one is the best for him.  In this way, users can use update bootloader to load up different function and feature sets, we can add more functions and features for supporting different applications of WC8 PLC boards in different firmware sets.
 
Now, what is your opinion that the feature should be placed in a different set firmware?  For example, 1-wire real time clock DS2417 support, 1-wire ds2450 support, 1-wire ds2438 support?  We think with I2C support, some of features provided by these chip can use I2C chips without using additional resources.
 
CAI_Support said:
Now, what is your opinion that the feature should be placed in a different set firmware?  For example, 1-wire real time clock DS2417 support, 1-wire ds2450 support, 1-wire ds2438 support?  We think with I2C support, some of features provided by these chip can use I2C chips without using additional resources.
 
Where is the greatest return for least loss of features?
Personally, I'd drop X10 in a heartbeat, but others may be using it.
 
I'd drop DS2417 first. There are plenty of I2C versions available with complete boards, crystals and batteries for around $1 on ebay. Bonus is that they not only do all the time and date stuff, they also offer 56 bytes of non-volatile user storage! That's certainly worth having.
 
Can you give us some indicative guide as to how much RAM will be freed up by removing which functions?
 
Another thing that may make a difference, is allowing a user to specify how much buffer space is required for network operations. For example, I've coded my most recent project such that it does not use any email (therefore, memory reserved for that is wasted), only does a single webset call - no stacking of calls (the result/reply from one call is what triggers the next) so additional memory reserved for other calls isn't of any benefit there either. Are these some easy places to recover some memory from?
 
Agree with ROSSW X10 is useless for me.
 
Since you have a boot loader now a days (my WCs FW predates that so have no direct experience) why not let it be a load option? When new firmware is loaded user sets some switches to select which portions of the code to load? If the code cannot be modularized just use brute force and distribute several feature versions as a single installable.
 
There is some risk creating lots of firmware versions will make it more complicated for customers and create a maintiance nightmare. What is the cost delta between WC and WC32?  If they are not too great I'd opt to minimize adding too many features, that customer has to select, and focus on enriching the feature content of WC32.
 
/tom
 
Ross, on this chip there are total 3808 bytes RAM, in that we must run a HTTP server, scheduler, email, webset, PLC engine, and remember all the IO states and their delays.  Microchip's network stack is already running at minimum memory space, although possible to tweak TCP stack, it is unlikely to gain any memory. Any user settable parameter will take a few bytes RAM.
 
I also wonder how many people using non-blocking delay on VARs.  Any byte counts when so many things packed in this. The Microchip compiler did a good job on reusing RAM for different purpose.  However, it does have its own limitations.
 
 
Tom, to your question comparing WC8 and WC32 cost, the manufacture cost is more than twice, because there are actually 3 processors on the WC32, main CPU, 1-wire bus controller, and a network controller.  WC32 does have a lot of room for adding functions.
 
Make a website where the user can select what features he wants, then a build script will be passed to the compiler with flags set, the firmware will be uploaded and cached so the user (and any future user requesting the same config) can download it.
 
If someone wants to remove email or webset or x10 or delays and instead add support for more 1-wire devices or RAM it should be possible.  Just requires smart use of preprocessor flags.  So what if you end up with 50 possible firmware configurations?
 
I like the idea of a bunch of pre-rolled (or custom-rolled-on-demand) firmware where we could select the features we need and trade off those we don't.
 
I just spied this small board on ebay:
http://www.ebay.com.au/itm/RTC-I2C-DS1307-AT24C32-Real-Time-Clock-Module-For-Arduino-AVR-ARM-PIC-51-ARM-hp-/161265099371?pt=AU_Electronics_Radio_Equipment&hash=item258c26226b&_uhb=1
 
For $1, a DS1307 RTC, complete with battery and crystal, plus an Atmel AT24C32 (4K bytes) read/write memory!
 
I'm thinking that with just a 4-pin connector, it could hook into my expansion board... be quite a bonus.
 
However an I2C RTC will be entirely useless if we can't set the WC8 date/time from it.
To this end, I propose making CTS a WRITABLE variable.
Does the WC8 have all the code built in to "fix" it's CTS from a supplied d/m/y h:m:s format? If it does, then perhaps there's good cause to also allow ALL of the time variables to be writable? Or at least:
CH, CM, CS,   CDAY,  CMONTH  and CYEAR  
CTS certainly.
CDW I'm flexible with, but would suggest it should be included for completeness.
(I prefer this because just a few lines of code could read and set the date/time from virtually any source, including a webset command - without requiring specific code by CAI to support a particular new chip)
 
Thanks for all the good feedback.  I think we get some idea how to move forward.
We think for anything that is supported by I2C bus and SPI bus, we should move out from 1-wire bus, like DS2417 realtime clock, DS2450 4x ananlog input, DS2438 battery monitoring chip, because there are I2C chip to do those functions, user can write few lines of PLC code to communicate with all those I2C devices.
 
We will keep the A5-A8 analog input value space, for users to use I2C four channel ADC storing 16bit signed value in that area, be that voltage or current, it will be more flexible in that way for users.  For example, DS1307 replace DS2417 real-time clock, DS2745 on I2C than DS2438 battery monitoring chip on one-wire bus, LT2309 8 channel ADC chip or LT2453 ADC chip all work well on I2C bus.
 
In this way, we probably do not need to remove any feature, but allow users to enable those same features using some PLC code on I2C bus or SPI bus.  That way, people can use those low cost I2C sensors or SPI IO devices.
 
IMHO this is a dead end street.
By doing so you you increase your own effort and that of the users. I would rather try to abandon WC8 and get some cheap WC32 replacements. look at the PCDuino and Raspberry Pi prices both for the cheaper versions having less RAM- they are as low as the WC8 price.
Functionality is key as long as there are no alternatives, but nowadays using Cortex M4 and A8 and higher cores you will see higher language programming at lower prices- thanks to Moores law..
 
Efried,
 
xDuino and Rx Pi both require users to do low level programming.  Sure, you can download project code and build them.  But if you want to make some of your special function, you still have to learn low level programming. WebControl is different by we done low level programming already, so that user don't need to worry about hardware registers and timing, or really need to learn a language.  PLC programming is like basic language, and it is totally isolate user from knowing hardware registers and timings.
 
By supporting I2C and SPI, WebControl users can access large amount low cost sensors, users can share how they use PLC code to communicate with those chips on this forum or anywhere else.   For example,  Ross is able to get AM2321 humidity and temperature sensor working on I2C bus with current firmware.  That sensor is similar like DHT sensor you wanted before, and PLC code is less than 10 lines to be able to read back, because WC8 firmware already taking care low level hardware handshaking and timing.  In addition, expert user can use external storage on I2C bus to expand memory space, to store non-volatile data.
 
Besides, these changes will not impact 1-wire temp sensors and humidity sensor already support.  It merely removes DS2417, DS2450, and move DS2438 support to a lot of MAXIM SMBus battery monitoring and charge controller ICs.    SMBus is a subset of I2C protocol.  By supporting I2C, it opened a wide door for a lot of sensors being used.
 
CAI_Support said:
xDuino and Rx Pi both require users to do low level programming.  Sure, you can download project code and build them.  But if you want to make some of your special function, you still have to learn low level programming. WebControl is different by we done low level programming already, so that user don't need to worry about hardware registers and timing, or really need to learn a language.  PLC programming is like basic language, and it is totally isolate user from knowing hardware registers and timings.
 
Also, the webcontrol is a single board with buffered inputs and outputs. If being used with just temperature/humidity inputs and outputs, it already has all the screw connectors etc there ready to use a single board, ethernet enabled, straight out of the box.  *duino requires at least some I/O shield, an ethernet shield and I don't know what else - which increases the cost and size and makes for a many-board stack that is IMHO far less robust.
 
 
CAI_Support said:
By supporting I2C and SPI, WebControl users can access large amount low cost sensors, users can share how they use PLC code to communicate with those chips on this forum or anywhere else.   For example,  Ross is able to get AM2321 humidity and temperature sensor working on I2C bus with current firmware.  That sensor is similar like DHT sensor you wanted before, and PLC code is less than 10 lines to be able to read back, because WC8 firmware already taking care low level hardware handshaking and timing.  In addition, expert user can use external storage on I2C bus to expand memory space, to store non-volatile data.
 
I would like to ask for an additional change too, in light of this new-found ability.
The AM2321 can read both temperature and humidity.
It would be really nice if we could have the humidity sensor (H1) as a writable variable if we are not using the 4th analog input for this purpose, so I can read the humidity register of AM2321 and WRITE H1 with the value; similarly at least one temperature sensor (T1?) so if no DS18B20 assigned to that channel, we can write to T1.
 
This would free up RAM/VAR for use elsewhere in the code, make more readable code, and perhaps make more flexible code since either DS18B20 and HIH4000 *OR* AM2321 could be supported for the same board/application/software.
 
For anyone else interested, here's the code to read both temperature and humidity. This code fragment does not check for valid answers, so a dead or missing sensor will return 65535 (which is easily tested for and ignored)
 

Code:
        i2cwrite 1 1 0xb8       ; wake-up chip
        delay 100 
        i2cwrite 1 0 0xb8       ; address chip for write
        i2cwrite 0 0 3          ; read command
        i2cwrite 0 0 0          ; start at register 0 (humidity MSB)
        i2cwrite 0 1 4          ; read 4 bytes
        delay 2                 ; let conversion complete
        i2cwrite 1 0 0xb9       ; address chip for read
        i2cread 0 0 RAM10       ; first 2 bytes are junk
        i2cread 0 0 RAM10      ; so discard them
        i2cread 0 0 RAM13       ; store humidity in ram1H
        i2cread 0 0 RAM12
        i2cread 0 0 RAM11       ; and temperature in ram1L
        i2cread 1 1 RAM10
 
This largely depends on the library and IDE provided. Take the discussion above. Some are asking for a web based firmware configuration. Compare that to a web based python compiler for µC. Adding a few libraries for sensors using A7 and higher cores, we get a decent open platform for high level programming. The existing WC system lacks a couple of things for a professional roll out, like easy replicability.
CAI_Support said:
Efried,
 
xDuino and Rx Pi both require users to do low level programming. 
 
WC32 board has a lot more RAM and IO. If there is a feature won't fit WC8, we can easily add to WC32 board.  WC8 is a lower cost and reliable platform, complement WC32 on our offerings. We do not plan to use any other processor, because Microchip processors are powerful enough. For easy replication of configuration from one board to another, Lars provided a FREE configuration duplicate utility on this forum.  If simply upload over network is not easy enough, you can find that thread and explain why in details.  Be specific will help resolve the problem for you.
 
For any professional use, we do not recommend continuing integration BRE board with newer PLC firmware, because  we no longer develop BRE firmware for its limited features. We only ship BRE for users replacing older boards. 
 
Through this discussion, we are clear now what should be the direction for WC8. We will work to get better firmware for our customers.
 
Hello,
 
thanks for explaining. I won't lure you into upgrading the WC8, you already have the compatible and more powerful WC32. My guess is that the WC8 will be obsolete in some years and it will not pay off investing much. But I think a migration tool would be fine transferring all the settings and PLC from WC8 to WC32 with one click. I will check out Lars' tool, but would prefer a solution bundled with the firmware update software which would be another more frequent case if the setting is destroyed, is it?
 
On the other hand I may point you to the activities of the big players. thingworx now acquired by PTC may roll out a solution which is even less demanding for non programmes in terms of set up of distributed solutions.
 
thanks
regards
 
CAI_Support said:
WC32 board has a lot more RAM and IO. If there is a feature won't fit WC8, we can easily add to WC32 board.  WC8 is a lower cost and reliable platform, complement WC32 on our offerings. We do not plan to use any other processor, because Microchip processors are powerful enough. For easy replication of configuration from one board to another, Lars provided a FREE configuration duplicate utility on this forum.  If simply upload over network is not easy enough, you can find that thread and explain why in details.  Be specific will help resolve the problem for you.
 
For any professional use, we do not recommend continuing integration BRE board with newer PLC firmware, because  we no longer develop BRE firmware for its limited features. We only ship BRE for users replacing older boards. 
 
Through this discussion, we are clear now what should be the direction for WC8. We will work to get better firmware for our customers.
 
rossw said:
Also, the webcontrol is a single board with buffered inputs and outputs. If being used with just temperature/humidity inputs and outputs, it already has all the screw connectors etc there ready to use a single board, ethernet enabled, straight out of the box.  *duino requires at least some I/O shield, an ethernet shield and I don't know what else - which increases the cost and size and makes for a many-board stack that is IMHO far less robust.
 
true, therefore I search only for boards having all on board including WiFi. Regarding I/O the mechanical 1-wire solution with the webcontrol has been improved by yourself not without a reason- it is not possible easily without your piggy back boards  connecting up to 16 sensors (WC32)...
 
Regarding your second paragraph I fully disagree, don't introduce hack arounds - make available 99 variables on the WC32 and full stop. In a few months the WC32 will get cheaper, replacing the WC8 or you will find plenty alternatives...
 
rossw said:
I would like to ask for an additional change too, in light of this new-found ability.
The AM2321 can read both temperature and humidity.
It would be really nice if we could have the humidity sensor (H1) as a writable variable if we are not using the 4th analog input for this purpose, so I can read the humidity register of AM2321 and WRITE H1 with the value; similarly at least one temperature sensor (T1?) so if no DS18B20 assigned to that channel, we can write to T1.
 
This would free up RAM/VAR for use elsewhere in the code, make more readable code, and perhaps make more flexible code since either DS18B20 and HIH4000 *OR* AM2321 could be supported for the same board/application/software.
 
 
Efried,
 
If you want wifi only board, this forum other section may have it, WC boards are not them. Although there are some low cost wifi boards out there online, those boards are not FCC certified, can not be operated in US or EU legally, and you will not find any reputable company selling them.  We are a US company following US law that can not skip FCC certification process if we ever plan to have any transmitter included in any of our product.  That cost is high.  If you are willing to shoulder that cost, we can help you custom design a board specially for you with wifi and anything you want on it.
 
If you ever developed a product like WC32, you will know the cost, and you will probably sell it for much higher price.  We are in business for many years.  We have seen many companies jumped in and not making money then get out in a hurry.  Those companies made products and expect to sell million boars in short period of time, so that they could pocket profit and went away.  You will not find those products on market long, nor any support or firmware updates. We are pretty sure your wifi ideal board is one of them.  We have different philosophy, we do development for providing a reliable solution, even that does not bring us any profit, or million boards sales in a long period of time.  WC8 and WC32 are two products we will continue develop and manufacture.
 
Back
Top