Is there some explicit and clear documentation that talks about migrating a Digi software project from the 7.4 ESP environment to the latest 7.5. Basically something that gets into the lower level details and gotchas.
I have an old code base that needs to be compiled using the latest tools. My experience has been that the 7.4 workspace and IDE is finicky to work with. And obviously there are some big changes in project structure between 7.4 and 7.5 specifically with where the web files are store and how the C code is generated with PBuilder in the latest 7.5 version.
I am looking for some guidance on potential pitfalls (references to 7.4 framework code vs 7.5 framework code, project and folder structure requirements, etc) and some sort of migration walk through guide. Something a little more in depth than a few release notes.
You can look at the Digi NET+OS 7.5 Programmers Guide, which talks about porting, but that may still be more high level than what you’re looking for. However, that being said, there aren’t many ‘pitfalls’ you’ll run into. The biggest thing is that you’ll have to port your BSP changes (any changes you made in your bsp folder, not necessarily the code outside of it) from your current NET+OS 7.4 project to a new NET+OS 7.5 BSP. After that, if you’ve used a wireless device, the functions have changed and you’ll have to figure out correct the mapping, which depends on when you started in 7.4 (7.4.2, for example, looks more like 7.5). Otherwise the rest of your code should just work.
What about SNMP?
Has anyone managed to port a 7.4 SNMP implementation to 7.5 with any success? If so how do you deal with tables? In 7.4 you just check the index and fill in the data for the row, allowing for run time setting of the table size, how do you do this in 7.5?
The documentation suggests you don’t need to write any setter/getter functions, but how does the data from the device end up in the SNMP agent then??
What about SNMP?
Has anyone managed to port a 7.4 SNMP implementation to 7.5 with any success? If so how do you deal with tables? In 7.4 you just check the index and fill in the data for the row, allowing for run time setting of the table size, how do you do this in 7.5?
The documentation suggests you don’t need to write any setter/getter functions, but how does the data from the device end up in the SNMP agent then??
Help much appreciated to this!
I’ve only just realised that the SNMP stuff had changed! I’ve still got ESP 7.4 on my machine, and it set up a load of paths to netos74 utilities - so I’ve been using the old MIB compiler without realising.
I’m as confused as you are about using the new SNMP stuff - despite comments elsewhere, I found it largely quite straightforward, although the code didn’t look very efficient.
I imagine you’ve read Digi’s white paper on the subject, which I found to be little help - it goes into excruciating detail on trivia, and misses out the important stuff (like how you handle data get/set).
It looks to me as if the structure mibTableHeaders in custvars.c (which is defined by your MIBs) has pointers to data areas for each group of data. And presumably the idea is that your code keeps this data up to date for SNMP reads, and has to somehow pick up that its been changed via SNMP. If this is the case, its going to be very difficult to use effectively - in my applications SNMP writes trigger ‘real world’ actions (like turning on a switch); very easily managed at present.
On the plus side, such words as there are imply that you can have several MIBs active at a time, which I would find useful. Not tried it yet though.
I’ve had a further read, and the SNMP stuff is beginning to make sense in terms of what to do - although the change makes no sense to me at all! (And if you read some of the 'Known problems of the MIB Compiler ’ in the HTML help, Digi don’t seem over-enamoured of the approach either).
Data is indeed accessed through structure mibTableHeaders - an extra chunk of RAM to allocate, which could be critical for some. For read data I either have to keep this in sync with data saved elsewhere, or pick up read requests and copy the data into the right place in the table. Either way this is a lot more code than filling in a few stub routines (a familiar concept from AWS). Similarly for SNMP writes, I have pick up that they’ve occurred, so I can trigger ‘real world’ actions. Digi suggest modifying the main code file generated by the MIB compiler.
This model also doesn’t fit well with my system structure, since it expects SNMP to be fairly tightly bound in with the rest of the code. For me, SNMP is an option which many customers don’t use (it’s actually very inefficient for our type of equipment), so I have APIs to link the functional core with various means of remote access.
I tried implementing an existing MIB as a comparison.
My existing file of completed stub routines (i.e. with the data access code added) is less than 600 lines.
The file I now have to modify to facilitate data access is more than 5000 lines long! And full of code which is of no relevance to the problem I have to solve. It also contains functionality I don’t need - for example, where I use tables, their size is known at run-time and never changes, so I don’t need the code to insert and delete rows.
Overall this change appears to be very much for the worse. There is also a substantial amount of work required to upgrade existing code. So I shall continue to use the 7.4 MIB compiler, despite its problems, until I hit some show-stopping bug.