So, I'm very much appreciating the addition of the DCD Editor to the MCU Config Tools v6 in MCUX 11.0.0. It's certainly more structured and versatile than command-line tools. I do have a few suggestions for improvement...
1) PLEASE sort the register names alphabetically when picking registers for commands. It's maddening to sort through the IOMUX and SEMC register lists trying to find one specific register when they're all haphazardly ordered.
2) It would be SUPER handy to be able to select and drag multiple consecutive (i.e. blocks of) commands at once. For instance, taking a long list of DCD commands, then making a new group and selecting a portion of those commands and dragging them into the new group.
3) Can you add a copy/paste function for commands? I get that you can effectively "cut and paste" a single command by dragging and re-ordering it, but it would be super-handy to create one command (say, a write to an IO PAD register), then paste it a bunch of times and only edit the register names, instead of manually creating 40+ commands and editing every subfield.
4) Combining #2 and #3, it would be great to copy and paste multiple commands at once. For instance, I'm adding SEMC SDRAM commands, which are sets of three "write slave address, write command, wait for interrupt bit" commands. Right now, I have to manually create each individual command. Would be great to select all three commands, copy, then paste a couple of times, boom, I now have three complete sets of SEMC commands that I can just edit the values of.
5) It would be very convenient if, when I click on a register name in an existing command, the selection window opens up and shows the existing register already highlighted, thus making it easy to change the selection to an adjacent register, rather than having to drill into the register selections from the top level all over again.
6) This is very much a "nice to have", but it would be great if for "write value" commands for registers, there were an interface to view and edit the individual fields of a register, instead of having to calculate the 32-bit composite value elsewhere.
I do appreciate that you keep adding to and improving the tools. Hopefully some of these suggestions can make it into the next revision of the tools.
Solved! Go to Solution.
Hello David,
Thanks a lot for sharing your experience with the tool with us.
Proposals are very helpful and valuable for us as your previous ones. We will add them into our backlog as well to be considered for next releases.
Also thanks for reporting the UI bug, it will be fixed in the next release.
Best Regards,
Tonda
Hello David,
Thanks a lot for sharing your experience with the tool with us.
Proposals are very helpful and valuable for us as your previous ones. We will add them into our backlog as well to be considered for next releases.
Also thanks for reporting the UI bug, it will be fixed in the next release.
Best Regards,
Tonda
I inadvertently noticed another issue, purely a UI bug. If the MCUX window is snapped to the full height of the screen (grab top edge of MCUX title bar and drag to top edge of screen, causing MCUX to expand vertically), and the DCD window is full of entries, if you try to edit the register setting for the bottom-most command, as soon as you try to expand the list of register groups to click an individual register, the selection dialog immediately collapses, making it impossible to select a register.
In the screenshot above, I'm hovering the mouse over "CCM_ANALOG". If I click that, the tree will very briefly expand, then the dialog will immediately collapse. While very unlikely, if I were to somehow define 60-70+ groups, it's possible that event with all groups collapsed, I might not be able to add any more commands at all, because the window is full and the register selection dialog is always collapsing. If there's plenty of space between the register selection and the bottom of the screen, there are no issues.
Hello David,
Thank you for your interest in using our new Device Configuration tool and for your valuable feedback.
All your suggested improvements seem reasonable and useful for other users as well. We will add them into our backlog to be considered for next release.
Regarding the point 6). Please configure the command “Write - bitfields”, select register and then edit value – new dialog…
Is this what you mean or you would expect some similar dialog for the “Write - value” command?
Regarding the issue with the group names, yes that’s a bug. The editor should disallow two groups having the same name – we will fix this.
Thanks again for your feedback and for reporting the issue.
Best Regards,
Tonda
Ah, I hadn't noticed the "Write - bitfields" option. Yes, that would be helpful in some cases. Though, after flipping back and forth between "Write - value" and "Write - bitfields", I think I can see a way that the bitfields screen could become a lot more useful.
Presently, the bitfields screen is only available when using the "Write - bitfields" command. But, there really isn't a "Write - bitfields" command... in the generated code, it's a Clear Bits command and Set Bits command. If I want to use the bitfields view to compose a new 32-bit "Write - value", currently I have to use these steps:
Note: I can't skip steps 5-6, because step 7 will always invalidate/erase the Value field of the command.
Needless to say, that's very complicated. For reference, I'm just including a screenshot of the dialog here:
I think there's a way to make this dialog a lot more useful -- with very little modification, this dialog can be used for ALL "write" and "check" commands.
Bear with me for a moment... first, rename the "Write - bitfields" command to "Write - clear and set bits", since that is what the command is actually doing. This dialog will be used for all "write" commands, so users will be able to edit bitfields regardless of which write command is used.
Next, eliminate the "direct value / individual bitfields" radio button to simplify the interface. Editing the direct value immediately updates the bitfields, and editing a bitfield and pressing tab or enter immediately updates the direct value, so there's no point in selecting one or the other. The cursor can only be focused on one text entry box at a time, so wherever the cursor is focused (the "direct value" or an individual bitfield), that's what the user is editing.
Another change I strongly suggest is that altering the command selection should not alter any of the values entered; it will only change the command that appears in the DCD code. If the user enters "0b10101010********0000000011111111" as a direct value, then the tool should store that value in the underlying XML. Then based on the command selection, the value would appear as:
Also, when the user clicks on the "Value" field in the DCD command listing and the dialog appears, the dialog should immediately focus on and highlight the contents of the direct value entry field. This helps the user to rapidly enter new commands and values, because now all the user has to do is:
This is an efficient use of keystrokes and mouse clicks. If the user wants to drill into the individual bitfields, they now have that option, too.
You can (and should) also apply this same structure to a dialog for the Check Data commands. This dialog would look nearly identical to the Write dialog, except that '*' is no longer a valid entry; the user enters only 0's and 1's; the help text at the bottom would also need to change to reflect this. Now the user can fill in 1's for specific fields, rather than figuring out bitmask values manually.
I think this would greatly improve the utility of the DCD editor.
I can also report, unfortunately, that the editor can be a bit buggy when adding and deleting commands and groups at the end of the DCD list. On at least a couple of occasions, I've gotten into a situation where I have a new, empty group at the end of the list, then I right-click the empty group and select "Add command"... and the command gets added to the immediately preceding group. Or I try to drag a command to the last empty group, and it attached to the preceding group. Just now I tried deleting one of the empty groups to clean things up, and managed to delete the preceding group which had actual commands in it. Feels like an index isn't being kept up to date.
Ah, I figured out the point of confusion... the editor gets confused when two groups have the exact same name. Trying to perform operations on the second group will actually apply to the first group. I have two groups named the same because the "SDRAM AUTO REFRESH" command is issued twice; I have one IP command in each group. The editor should either disallow two groups having the same name, or handle this case correctly.