 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Multi-drop TTL
  Page 3 of 4   |
|||||
| Author | Message | ||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
MODBUS was designed to be friendly to those who thought in relay logic terms - not computers. Hence Coils (relay coils) as output devices. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3309 |
I will have to provide the CRC outgoing to the Renogy device, since that's what it expects, but plan to ignore it incoming, since nothing will be smashed or harmed if there are uncaught errors, since this will simply be for data reporting and logging. If I start setting parameters (registers) with this method, then I may have to do the CRC checking. Speed is of no importance here--I thought I'd start off getting the data (State Of Charge, Battery Voltage, Solar Panel Voltage, Panel Current, etc. every 10 seconds or so). This device knows nothing about the load other than through seeing the State of Charge decline. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
Actually I think that statement refers to the MODICON documentation for MODBUS. It is the worst enemy of MODBUS. MODBUS is a simple, reliable protocol and if you can get over the references to coils, register addresses holding registers etc it can be very easy to understand. If one of the C gurus could write a CFunction for the CRC the "unacceptable" few mS to calculate the CRC in BASIC would be gone (not for all of course). There are many examples of the MODBUS CRC available on the web. Bill Keep safe. Live long and prosper. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
@Turbo46  I am the absolute worst for this and I realise that I'm being ridiculous. I sometimes use an online Tone Generator, input 100Hz square wave and listen to it to remind myself of what 10ms is The really, really ridiculous thing? I drive lots of hydraulic valves and the MMBasic PULSE command works well for me BUT I have to establish a minimum pulse of 150ms. Anything less and the valve can't respond. I even count clocks on the Propeller and nothing I'm capable of would make that thing break a sweat. I guess I have programmer's OCD Craig |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
It's not the time it takes to do CRC that bothers me - it's the fact that it seems to be a black art (no matter how many examples I look at). On top of that, the more I look at it the dafter it appears to be for a standard - that's what's so good about standards, you can have any number of them and all incompatible. Checksums I can understand. :) Then again, I'm not much of a programmer in any language and I'm very easily confused by this stuff. Although I've seen CRC used in MODBUS stuff, it's not something I've ever had to actually use myself. The firmware handled all that. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
@Tinine  I did say (not for all) you have explained what you do before and I get the gist of it. The following rant is not for you.But those who are transmitting data over some medium or other should use a CRC if they value the integrity of that data. It's not difficult to do, it's there in Fruit of the Shed and you don't have to understand how it works, just use it. The MODBUS CRC is NOT restricted to MODBUS. It's just the CRC of a string of data. XMODEM CRC is similar and could be used in exactly the same manner. I just don't understand the reluctance. Bill Keep safe. Live long and prosper. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
That made me But we all want to further the MMBasic cause so I like the idea of a fast CRC. As much native/almost-native stuff for MMBasic the better as opposed to the Arduino world of "oh,don't worry about it there's a library"  It's about time that Pimoroni and The Pi Hut recognised MMBasic, BTW  |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
All's fine, Bill, using pre-packaged CRC while everything is working. The problem comes in fault-finding it when you try to talk to something that's using a different initialising value or something like that. Without some understanding of how it works you're in the wet and smelly as even a logic analyser won't tell you what's wrong. Don't get me wrong - CRC is a great system from what I can understand of it. Far better than a checksum, but it does have its negative points too - one being that manufacturer A's gear won't necessarily work with manufacturer B's gear. If it's your own stuff then fine, no problem. The variations seem t have been largely commercial driven - to lock people into a product. There's no need for them. CRC was, apparently, designed to be calculated and checked using logic gates, not software. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
True to a point Mick, too many 'standards' look at an on-line CRC calculator and it's hard to find the one you need. A MODBUS device uses the MODBUS CRC or it's not MODBUS. It has been used by a few members on this forum to communicate with MODBUS compatible gear. TassyJim wrote the first one in MMBASIC for one such member. Using a CRC in your own system is not a problem because you will use the same routine in both ends. That's the main point I'm trying to make. Bill Keep safe. Live long and prosper. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3996 |
It sort of is. It's based on logic gates (as has been posted) with feedback, so the software tends to look ugly. I've looked at the logic gate circuits and gone OUCH, WTF!? And pretty much the same with the software version of them. Doesn't matter, just use it because it works. The different CRCs tend to reflect real world issues e.g. that the first byte of a message might quite likely be a specific value (or missing) which a particular CRC would not detect but a different CRC would. (This can by why one CRC might start with an initial value, say hex FFFF, whereas another might be zero.) (I expect the hardware guys, given the logic gates circuit, could see why a given circuit could fail in the above situation. Occasionally I have, studying the software.) It doesn't take long to calculate a CRC even in MMBasic, though - and if it seems too long you're probably either wrong (sorry) or doing the CRC over a whole message rather than byte by byte as it comes in. In that latter case, just do it byte by byte! John |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
Surely byte by byte CRC is even slower than on the complete message? You can't signal NAK until you've got the entire thing anyway - there isn't time and it's quite possible the TX end isn't listening on a half duplex system. Byte by byte restricts the byte rate, message CRC causes longer pauses between messages but keeps the byte rate high. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3996 |
Overall time taken, yes. You'd use it when the time taken to do the CRC on the whole message is too long. On many systems you've plenty of time to do the CRC byte by byte without missing data coming in or breaking other real-time constraints. John Edited 2022-03-16 19:53 by JohnS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4853 |
Well, when you add 2 bytes CRC for every byte you send, you force the byte rate up. You are sending 3x as many bytes... PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
good point. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Been rock-solid for many days now. Bombarding two PicoMites from the Propeller @460KBaud. I'm using Schottky diodes. Feeling a bit guilty, relegating this awesome device to I/O expander but it's really cool. They are running watchdogs and are able to shut down the machine should anything go awry. Craig |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Ref: "Gemini" thread. Seems like this discussion from a few months ago has been forgotten. |
||||
| pwillard Guru Joined: 07/06/2022 Location: United StatesPosts: 307 |
That solution looks more complicated than I remember... RS485 is not so bad... I played with it WAY back... as I managed to find a bag of Texas Instruments 485 chips and toyed with SNAP protocol instead of MODBUS (Which I found confusing back in the 90s). SNAP Protocol |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3996 |
Er, why add 2 bytes CRC for every (as in: each) byte? John |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1636 |
No protocol that I know of does that? It's one or two CRC bytes per message or block of data Bill Keep safe. Live long and prosper. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
It's working really well. Been hammering it for a few days now. Not a glitch Four RP2040s talking to a Prop-2 @460K Baud:  Craig |
||||
| Page 3 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
