It's the principle! remember, you do it today because although not a scalable solution it's a small problem. Then in the future the problem scales, the solution cannot and you have to reinvent the wheel. Tell me, how do J1939 auto ECU's manage this problem? they have several hundred messages of no same format, you are telling me that someone wrote a message handler for each one?
Premature generalisation is a sin. "YAGNI" as the eXtreme Programming people say. People such as John Carmack agree: "It is hard for less experienced developers to appreciate how rarely architecting for future requirements / applications turns out net-positive."
It's the principle! remember, you do it today because although not a scalable solution it's a small problem. Then in the future the problem scales, the solution cannot and you have to reinvent the wheel. Tell me, how do J1939 auto ECU's manage this problem? they have several hundred messages of no same format, you are telling me that someone wrote a message handler for each one?
In a sense, maybe yes.
In at the hardware level, on a message bus, each device will only pick out and process messages it is interested in. It will look at the PGN and SPN to decide this, and if it doesn't care it will ignore the message. So it only locally has to handle a few kinds of message.
On the other hand, if someone is writing a debugger or bus sniffer that needs to decode and display all kinds of messages, then it will indeed have to handle dozens or hundreds of message types. But it won't do this with huge amounts of code, it will use a database where it looks up the message type and gets the decode information from the database, so it can automate the process. It will use this database to figure out how to unpack and decode the contents of each message.
If you want an example of my frustration, here I have been told that I should not define variables as static unless inside a function.
In another thread months ago I was told I absolutely should declare anything static that I did not want to be global
But the fact still remains that hardware registers in micro controllers are mapped with structures. As they are hardware registers it is not a question of arguing about how the struct memory is allocated. It is already allocated by hardware and these systems work. I understand that maybe RAM allocated structures will be created differently but then I want to know why and how. I can't just keep followring recipes.
If you want an example of my frustration, here I have been told that I should not define variables as static unless inside a function. In another thread months ago I was told I absolutely should declare anything static that I did not want to be global, you see my problem? The language was created in the 70's and not formally standardized until 1989, and then standardized about ever 5 years. People tend to stick with what they learnt when they were young and then don't change, so opinions are always mixed.
If you have code that uses global variables with the same name in different files and you don't want them to actually be the same bytes in memory then, yes, all of them (or all but one) need to be static.
On the other hand, static inside a function has nothing to do with visibility, and just causes the value to be persistent between function calls. There are a few cases where this is needed, but not many. More often than not it is a really bad idea and should be avoided as it can prevent recursion and re-entrant behaviour.
But the fact still remains that hardware registers in micro controllers are mapped with structures. As they are hardware registers it is not a question of arguing about how the struct memory is allocated. It is already allocated by hardware and these systems work. I understand that maybe RAM allocated structures will be created differently but then I want to know why and how. I can't just keep followring recipes.Well, yes, in many systems, hardware I/O registers are mapped to particular memory addresses, and then it is possible to overlay a structure on that section of memory to make it easy to access the registers by name. However, it is still essential to define the struct carefully to ensure the structure elements align properly. When these structure definitions are provided in a header file, someone has gone to great care to make sure this works.
Premature generalisation is a sin. "YAGNI" as the eXtreme Programming people say. People such as John Carmack agree: "It is hard for less experienced developers to appreciate how rarely architecting for future requirements / applications turns out net-positive."
Why CAN and not something much simpler like RS485 where you roll your own small frame-format/protocol to only do what you need for your application. Instead of learning tons of CAN stuff
Premature generalisation is a sin. "YAGNI" as the eXtreme Programming people say. People such as John Carmack agree: "It is hard for less experienced developers to appreciate how rarely architecting for future requirements / applications turns out net-positive."
Why CAN and not something much simpler like RS485 where you roll your own small frame-format/protocol to only do what you need for your application. Instead of learning tons of CAN stuff
I'm not saying you shouldn't use CAN or you should use RS485. I don't know enough about your application. Just curious why CAN.
And just to say, I am updating my motor drivers every 7ms at the moment, try that on RS485.....
And just to say, I am updating my motor drivers every 7ms at the moment, try that on RS485.....
what do you imagine would be the issue?
@Simon
what do you use on your GNU/Linux computer as a canBUS HBA?
USB-to-CAN?
You can either offer a proper answer and stop telling me I am ranting for weeks or continue to belittle me.
You can either offer a proper answer and stop telling me I am ranting for weeks or continue to belittle me.
I don't know what your question is and you haven't provided a clear *example* (that means code) of what you are doing. You verbally describe 1-2 lines of code at a time without context and I for one am completely lost at what you are actually doing.
Premature generalisation is a sin. "YAGNI" as the eXtreme Programming people say. People such as John Carmack agree: "It is hard for less experienced developers to appreciate how rarely architecting for future requirements / applications turns out net-positive."things like "refactoring" is imho one of "you are going to need it in the future" in mind. following YAGNI, whats the point of refactoring? as long as it work?
And just to say, I am updating my motor drivers every 7ms at the moment, try that on RS485.....
what do you imagine would be the issue?