Dave Casazza
TVWBB Fan
I've posted a thread with the Mega2560 concept, and after letting it perk for a few days, I have a question for everyone:
Is the problem with the approach the Mega2560, or is it the fact that there is a Motherboard/Daughterboard combination? We've got a couple of respondents on the thread, but not an overwhelming response with 580 views as of today http://tvwbb.com/showthread.php?43312-Heatermeter-on-Mega2650.
Let me pose an alternate approach that doesn't involve the Mega2560 for the sake of a healthy/constructive argument:
What if we used the 328P chip instead of the Mega, and move to a motherboard/daughterboard architecture? This would permit us to segregate functions between a main motherboard (MB) HM4 and a daughterboard (DB) HM4.
The Main HM4 would benefit by no longer having to interface with any ancillary equipment. No more probes or fans, freeing up some IO for other things, like a second rfm12b for another pit, etc. Power consumption goes down as well. I really like this - especially the possibility of a completely wireless HM. The code in this module would do several things:
The DB HM4 would benefit by no longer having to support the LCD, button or alarm. This additional IO could be used for servos, thermocouples, etc. The logic here could be customized, depending on how clearly it was coded and documented - we could move towards a code base here that was easily modified for customized needs. For example, we could handle HI temp digital probes in this codebase, leaving the MB codebase untouched.
The code in this module would do several things:
As an added bonus designing cheap, purpose-built daughterboards for specific applications would be easy, so long as they follow a set of common pinout rules.
We could offer two different configurations - a MB/DB combination that you could stack in one package/case, and/or one that was connected via RJ45 or wireless connection.
The downside: to be completely honest, it's a complete re-write of Bryan's 328P code. The question is - are the benefits large enough to justify this change? I totally understand if Bryan just does a complete thumbs down to the discussion, but I'm putting it out for that public exposure.
Anyhow, I'm posting this for argument's sake, in the hopes of trying to figure out what would make the HM4 group happy.
Let me know your thoughts? I understand if this seems outlandish to group members, but i wanted to stimulate a good group discussion.
Cheers,
Dave
Is the problem with the approach the Mega2560, or is it the fact that there is a Motherboard/Daughterboard combination? We've got a couple of respondents on the thread, but not an overwhelming response with 580 views as of today http://tvwbb.com/showthread.php?43312-Heatermeter-on-Mega2650.
Let me pose an alternate approach that doesn't involve the Mega2560 for the sake of a healthy/constructive argument:
What if we used the 328P chip instead of the Mega, and move to a motherboard/daughterboard architecture? This would permit us to segregate functions between a main motherboard (MB) HM4 and a daughterboard (DB) HM4.
The Main HM4 would benefit by no longer having to interface with any ancillary equipment. No more probes or fans, freeing up some IO for other things, like a second rfm12b for another pit, etc. Power consumption goes down as well. I really like this - especially the possibility of a completely wireless HM. The code in this module would do several things:
- Interact with rPI
- Drive menu operations
- Figure out "what to do"
- Communicate "what to do" to the daughterboard
- Get status of what is happening from daughterboard
The DB HM4 would benefit by no longer having to support the LCD, button or alarm. This additional IO could be used for servos, thermocouples, etc. The logic here could be customized, depending on how clearly it was coded and documented - we could move towards a code base here that was easily modified for customized needs. For example, we could handle HI temp digital probes in this codebase, leaving the MB codebase untouched.
The code in this module would do several things:
- get commands "what to do" from the MB
- interpret and do those commands "how to do it -> doing it"
- get feedback (temperature from Maverick, or high temp thermocouples, or hell, IR temps (lets dream).
- Communicate "what is happening" back to the MB
As an added bonus designing cheap, purpose-built daughterboards for specific applications would be easy, so long as they follow a set of common pinout rules.
We could offer two different configurations - a MB/DB combination that you could stack in one package/case, and/or one that was connected via RJ45 or wireless connection.
The downside: to be completely honest, it's a complete re-write of Bryan's 328P code. The question is - are the benefits large enough to justify this change? I totally understand if Bryan just does a complete thumbs down to the discussion, but I'm putting it out for that public exposure.
Anyhow, I'm posting this for argument's sake, in the hopes of trying to figure out what would make the HM4 group happy.
Let me know your thoughts? I understand if this seems outlandish to group members, but i wanted to stimulate a good group discussion.
Cheers,
Dave