Discussion:
SPI Tool?
(too old to reply)
dwvcfii@yahoo.com [nuttx]
2015-12-22 19:11:27 UTC
Permalink
Greg,

Based on some reading here

http://nuttx.org/doku.php?id=wiki:nxinternal:devices-vs-buses http://nuttx.org/doku.php?id=wiki:nxinternal:devices-vs-buses

it appears that "bus-centric" peek-poke utilities like the I2C Tool violate the functional partition of the OS, but they are, of course, an essential tool when bringing up new hardware. First rule of every design: start simple, and work upward from there. For example, my goal right now is to simply validate the hardware design by reading and writing data to specific registers. Next step would be to actually write the proper device drivers.


The apps/system/i2c tool should work for the initial testing of the I2C bus, but there doesn't happen to be anything similar for SPI (correct me if I'm wrong).



Assuming I can build something that will mimic the I2C Tool, would you consider accepting it into the apps repository? I just want to know whether I should attempt to polish the code or just treat it as a one-off.
spudarnia@yahoo.com [nuttx]
2015-12-22 19:22:06 UTC
Permalink
No. The I2C tool is useful but architecturally a mistake. I will not accept anything similar for SPI.


Greg
spudarnia@yahoo.com [nuttx]
2015-12-22 19:46:45 UTC
Permalink
Post by ***@yahoo.com [nuttx]
No. The I2C tool is useful but architecturally a mistake. I will not accept anything similar for SPI.
A little more...


There are various ways of violating an OS architecture. The very worst is to disregard the OS interface boundary and let an application make direct calls into the operating system via OS-internal, non-standard, "back-door" interfaces. That is prohibited in most NuttX build modes, but that prohibition cannot be enforced the "flat" build used with most small embedded systems. The I2C tools does that kind of nasty interface violation and there most definitely will never be anything more like that in any of the NuttX repositories.


An operating system is only as good as its interface definition. And if the OS interface definition is not enforced, then there really isn't one. I am the only enforcement for the case of the "flat" build.


The above is a "hard" architectural violation. There is a softer violation as well where the application does obey the OS interfaces structurally, but does not follow the intent of the OS functional partitioning or the roadmap of the OS. Perhaps, in fact, that is not a "violation" at all, but just a difference in opinion and "vision". My vision for the OS is certainly different that most people in this group.


For example, you could implement properly structured character drivers that provide access to buses, I2C, SPI, GPIOs, etc. I have been pretty strongly opposed to that in the past. To me, it is a migration of OS driver functionality out of the OS and into applications where it really does not belong. Use of those sneak drivers essentially means that you really plan to develop "user-space" drivers.


However, my position on this softer violation has itself softened over the years. I still do not think that it is a good idea and I think that it encourages a certain chaos in the development of system solutions. However, there are a lot of smart people who don't agree with me and I suppose I should make myself open to some really good bus drivers for use by applications.


Supporting tools and testing is only valid reason I can think of for the existence of bus-oriented character drivers. Laziness is most often stated motivation.


There is a long history of this kind of discussion in this forum if you are interested.


Greg
dwvcfii@yahoo.com [nuttx]
2015-12-22 20:58:25 UTC
Permalink
Post by ***@yahoo.com [nuttx]
My vision for the OS is certainly different that most people in this group.
It's one thing to have differences of opinion, but assuming you did not err in your choice of quantifier here...if your vision is indeed different than "most" people in the group I'd stop and think about my approach if I were you.

I'll grant you that an OS should not be a free-for-all, but for the same reason I question security advocates when security becomes so strict that it gets in the way of actually getting real work done, I must question your strict adherence to an architecture that is apparently inflexible to the point of not allowing the integration of test tools I think most would consider helpful during the hardware bootstrapping phase of development, at least in the flat / embedded memory model configuration.
Post by ***@yahoo.com [nuttx]
Supporting tools and testing is only valid reason I can think of for the existence of
bus-oriented character drivers. Laziness is most often stated motivation.
I've seen first hand what happens when people who think they know better decide to take logic out of the drivers and push it up to higher levels (the application or userspace)...in fact I left a company because they were doing that and more without regard to the eventual kaboom I knew would result, so rest assured that is not my suggestion here insofar as I don't intend for the code to be used as the model for OS development nor in production environments.

I'll go about my business and develop what I need to develop as always, but I'll admit I'm disappointed that such an essential tool does not meet with your current goals or vision. I would nonetheless like to ask that you consider any necessary OS policy or architectural changes needed to properly support bus-oriented tools in the flat / embedded memory model configuration so things like I2CTool need not live out in the cold. People need this stuff.
Post by ***@yahoo.com [nuttx]
There is a long history of this kind of discussion in this forum if you are interested.
I'll look for that. Thanks.
Michael Smith drziplok@gmail.com [nuttx]
2015-12-23 02:34:56 UTC
Permalink
Post by ***@yahoo.com [nuttx]
Post by ***@yahoo.com [nuttx]
My vision for the OS is certainly different that most people in this group.
It's one thing to have differences of opinion, but assuming you did not err in your choice of quantifier here...if your vision is indeed different than "most" people in the group I'd stop and think about my approach if I were you.
Greg has, in fact, stopped and thought about his approach, and articulated it a number of times in this forum already (as he’s indicated).

We may disagree with his some of his choices, but NuttX is his project and thus his decisions are what goes.
Post by ***@yahoo.com [nuttx]
I'll grant you that an OS should not be a free-for-all, but for the same reason I question security advocates when security becomes so strict that it gets in the way of actually getting real work done, I must question your strict adherence to an architecture that is apparently inflexible to the point of not allowing the integration of test tools I think most would consider helpful during the hardware bootstrapping phase of development, at least in the flat / embedded memory model configuration.
Just as a datapoint, since we are swapping opinions here; if effective security is getting in the way of “real work”, then you should stop and think about your approach to “real work”.
Post by ***@yahoo.com [nuttx]
I'll go about my business and develop what I need to develop as always, but I'll admit I'm disappointed that such an essential tool does not meet with your current goals or vision. I would nonetheless like to ask that you consider any necessary OS policy or architectural changes needed to properly support bus-oriented tools in the flat / embedded memory model configuration so things like I2CTool need not live out in the cold. People need this stuff.
This is the essential difference between an application developer (you) and a platform maintainer (Greg). You’re focussed on what you need and you see the boundaries of the problem in the terms of your current and recent undertakings. Greg is looking at a bigger picture with hundreds of targets and thousands of devices, limited development and support resources and objectives that favour the greater good of the project as a whole rather than the occasional squeaky wheel.

= Mike
dwvcfii@yahoo.com [nuttx]
2015-12-23 17:16:18 UTC
Permalink
Post by Michael Smith ***@gmail.com [nuttx]
Greg has, in fact, stopped and thought about his approach, and articulated it a number of
times in this forum already (as he’s indicated).
We may disagree with his some of his choices, but NuttX is his project and thus his
decisions are what goes.
<snip>
Post by Michael Smith ***@gmail.com [nuttx]
This is the essential difference between an application developer (you) and a platform
maintainer (Greg). You’re focussed on what you need and you see the boundaries of
the problem in the terms of your current and recent undertakings. Greg is looking at a
bigger picture with hundreds of targets and thousands of devices, limited development
and support resources and objectives that favour the greater good of the project as a
whole rather than the occasional squeaky wheel.
I understand his position and actually agree with his desire to stop code from accessing what are in effect private interfaces. I've railed about this before on my own projects.

But that doesn't negate my needs either, particularly given the fact that I'm not really doing anything particularly special, "one-off" or otherwise unique for my project. I'm merely trying to develop generic test tools that allow faster sanity-checking of all hardware. Provided this is done in a manner that Greg endorses, I simply don't see a problem with it.

I'll grant that I could just bring up the micro from bare metal on my own and throw some test code in an entry point and get the job done, but I strongly believe in testing with the stuff I plan to deploy, hence my interest in getting test tools working within Nuttx. That way when I go to deploy the only change is reconfiguring it to exclude the test tools.

Fortunately Greg appears to have recently updated his todo list (and perhaps his policy as well) to properly support an I2C bus driver. That's encouraging.
spudarnia@yahoo.com [nuttx]
2015-12-23 17:44:59 UTC
Permalink
I am actually much more flexible on this topic than I have been in the past.


No, I will not accept any tools or applications that poke around directly in the OS internals. But I will accept invasive applications like this provided that they conform to standard OS usage. In order to conform to standard OS uses, the solution has to be divided into two parts:


1. A character driver within the OS that supports open, close, read, write, IOCtl, etc. The character driver lives inside the OS and can be accessed by any applications as, say, /dev/i2c2, which provides all of the functionality via read() and write() but mostly via IOCtl().


(Yahoo! insists on capitalizing the IOC in IOCtl)


2. An application that does not violate the OS/application interface but, instead, opens the character driver and accesses the I2C bus via read(), write(), and IOCtl().


The current I2C tool is the worst example since it violates all of the rules. It is grandfathered in but someday will be fixed to work better with the OS interfaces.


So I think we are discussing only "how" to implement these tools at this point, correct? And there is clearly a wrong way and there is a right way to do that. Based on what you have said, I think we both agree on that. The only point is the current I2C tool is the wrong way and, no, I won't take something like that into the repository.


If similar tool were done the right way (with an OS driver), then I don't think I would have any particular reason to be concerned.


Greg
dwvcfii@yahoo.com [nuttx]
2015-12-23 19:25:25 UTC
Permalink
Post by ***@yahoo.com [nuttx]
So I think we are discussing only "how" to implement these tools at this point,
correct? And there is clearly a wrong way and there is a right way to do that.
Based on what you have said, I think we both agree on that. The only point is
the current I2C tool is the wrong way and, no, I won't take something like that
into the repository.
Yes. We're on the same page.

Continue reading on narkive:
Loading...