Since these are requested to be "black box" services, my understanding is that a give EEPROM image will reside in lower 32K EEPROM.
The initial requirement is then assumed to be the EEPROM image premanently reside in default 32K EEPROM and will NOT be modified in any way during use.
Of course this requirement could be revised as needed. Maybe when there are more than one function and functionality expandes beyond 32K of code we could examine this possibility.
If anybody sees a problem with this, please chime in.
The VGA example is like providing a text interface display for a less sophisticated micro similar to the BackPack. If I've missed the point redirect me (still on my first cup of coffee).
Long ago the teletype was invented. The teletype was a printer controlled by a "current loop" or a serial port. The analogy is that some mechanical or other interface can be controlled through a simple protocol.
PLCs may be a natural extension. I wonder if Allen-Bradley would be interested in small Propeller based controllers ... guess they're using something else already.
Does this strategy seem reasonable, or do you see any obvious flaws I need to address?
It is reasonable, but quite limited. What you are describing is a 'Canned Demo', and if the user has a board with that much resource, why do they need physical delivery of a separate EEPROM ? The NET does that better and cheaper.
It also presumes the 'Canned Demo' is precisely what the user wanted.
If it is merely close, they need to get the Source code, in which case, why not start there ?
One of my pet peeves is systems that do NOT include working examples, or included only source files, and no snapshot captures. Map and report files can provide valuable insight.
So morphing the idea away from a Physical EEPROM, which is doomed to fail, to more 'Internet Canned Demo' in concept, I can see a benefit in allowing the user to directly download the binary image, and quickly try it, before they grab the project.
I also like the idea of 'Defining Corner Pegs' type examples, which push the Chip, and illustrate just what CAN be done.
As an real example: Suppose I ask just how fast a rotary encoder pulse rate CAN a Prop follow/count ?
One template says 144clks for the first and +50 for added ones - but is that the best ?
Why not add an SD interface where binaries can easily be copied onto, and just load the eeprom with a bootloader that can read a configuration file from the SD specifying the binaries to load? The difficult part would probably be having a bootloader be able to combine various binaries to a single eerpom image, but it would make the device more powerful/flexible.
If it is merely close, they need to get the Source code, in which case, why not start there ?
Because the project is to see if the community can work together to fullfil a request to make black box functionality available to other micros. We can address other requests as a separate effort on a separate thread.
So morphing the idea away from a Physical EEPROM, which is doomed to fail,
Thanks for your participation and support. There are some details eariler in the thread that you may have missed.
While this is certainly this is an option, perhaps we should focus on getting a couple functions into an EEPROM per the request before we go beyond the scope of the original request.
The first EXAMPLE is for the function of VGA monitor to display text from a Tiny85 or other micro that cannot display VGA easily. This is not a demo, this is hooking up a display to a Tiny85. All we need to establish is the interfaces, which has been started.
Let try nother example: davidsanders has suggested Sigma Delta. If davidsanders defines the input the Sigma Delta function will take, and the output the Sigma Delta will deliver, we could code that function into an EEPROM so the prop be connected to a suitable signal, and deliver that output to a device, perhaps in an existing product that does not signa delta so well.
Don't make it hard, this is a very simple. The difficulty seems to be staying focused on the original request and intent of the discussion. We take any given function that the prop already performs, and define a set of inputs and outputs to that function, and interfaces between the micros, and we can have prop provide blck box functionality to other props or AVRs or PICs or whatever.
Maybe the concept of defining interfaces is the problem. An well known example of this could be an old style external modem. The modem had two physical interfaces: One interface was to the phone company, the other was to the PC. The modem had software interfaces, one was the AT command codes , the other was stuff the modem did with the phone company and the other modem. Why have a separate microcontroler in the modem when there wa a perfectly good one in the PC? Because the modem off--loaded those functions from the PC. In fact the "modems" that used the PC to do all the work were a nightmare. So the modem was micro in a black box that provided services to the PC, and did so with well defined interfaces.
Yes, one could just use the prop directly for everything; yes, you could just go buy a modem, and yes, everything under the sun has been done already. This experiement is to see if we can define the interfaces for a function or two that the prop could provide as a service to another device. Maybe I am not expressing myself clearly, can somebody else state this more succintly? Or have we reached that the limit of this effort?
If the plan is to memory map the prop in to the other MCU over I2C, then we need a set of addresses that can be used to provide the 'Black Box' functionality. I would propose:
1) 2 bytes for the Character Col/Row resolution, a rectangular buffer following this for the Text buffer that the other micro sees.
2) A 1 Byte space for basic ASCII character input from the other micro, with another byte for extended keys (need to define a standard for extended keys).
3) A 1 Byte buffer for the current Sigma Delta value. And 2 byte configuration buffer, one byte defining the number of valid bits, and thus the speed, the other used as a enable flag. Duplicate this as many times as implemented Sigma Delta.
4) A space to write some simple form of vector drawing commands (format of vector drawing to be determined).
We do need to define the address (as seen by the host micro) for each of these, once this is done we will have a good starting point, as much of the code is already done (it is just a matter of some simple adaption.
... memory map the prop in to the other MCU over I2C, ... addresses ....
What I had in mind was that at lest initially, the "addressing" would be simply via pins.
That is, in the case of video, the remote micro sends a byte stream from the target's I/O pin to prop pin 7 for example. The prop sends VGA image of the text out on pins 16-23 per the default demoboard configuration. At this level, we do not have to consider buffering, etc, as those are implementation detail that are best left to the engineer doing the coding at a later date.
In the case of Sigma Delta, I image that the prop would be reading a singal, and sending the data to the remote micro. If this is the case, signal would come in through pin 6 (or would it come in from the electret mic on pin 9? I don't know much about sigma delta) and the output could be sent to the remote micro on pin 5.
In this method, "addressing" is simple, it just pin allocation.
The "interfaces" are items like:
Example: "The VGA function will receive a byte stream on pin 7 of ASCII text and ANSI control codes at 9600 to 115k baud, default at 9600 and application selectable using control sequence XXX. VGA output will be on pin 16-23 through a standerd VGA connector per demoboard configuration."
Example: "The Sigma Delta function will recieve a signal from DC to 80Mhz at a mx voltage of 5V on pin 6 and output a string of text at 9600 baud to the remote micro on pin 5. (or whatever)"
For the time being, we don't need to worry about sharing input and out pins between functions. We only have two functions, and they only use 11 pins between them.
I have been thinking about this and I think
it would be nice to have an external implementation
of this idea. A very small box with RCA and VGA jacks
on it or with cables coming out terminated with RCA and
VGA connectors. The cable idea might be the cheapest
way to go since cables are so inexpensive and that way
the end user would not need to scrounge around for one.
So picture a small device with video and audio cable exiting
out one end and just a power connector on the other end.
To keep costs minimal you could even dispense with the
case and pot the device inside a square block of potting
compound.
The end user would supply power to the device from her
project. Data would be sent to the device by having a single
pin on the controlling uC toggle the + line on/off under program
control. the Prop could read the incoming data with an input pin.
The external device could smooth out the DC input using a capacitor
to hold enough current to keep the Prop powered during the short
duration dropouts due to the sending of data. Linear regulators
would provide the proper V needed. The Prop would of course need
to read the data pulses at a point before the dc gets smoothed
out by the capacitor filter. The users uC could toggle the line using
a single pin to switch a small npn transistor like a pn2222.
This is the most minimalistic idea for an external implementation
that I can come up with...it seems like it should be workable.
Many uC's have very limited memory. Some as little
as .5kb for program and data storage. Many of these
same uC's have only 4 I/O pins. Thus it seems important
that the user be able to store some data inside the Prop's
eeprom for creating a video display....a sort of default
display that will pop up when the unit powers on. then
the uC could manipulate this default display in useful ways.
Using the external dongle implementation a fifty cent uC
could have a nice video display... and the display dongle
could be moved from device to device. This would be a nice
debugging system or the basis of a simple data analyzer
setup.
The hardware cost to add the ability to communicate with
such a video dongle for any uC project would be little more than the
cost of the NPN transistor....15 cents or so. The idea is so simple
that this functionality could be easily added to most existing projects
and devices.
[EXPLANATION]
This post (#44) captures the official user requirements for the prop black box video service.
The previous post is the request from the user
Earlier posts were conjecture
Subsequent posts will define and expand internal requirements and implementation.
The purpose of this post is for the developer to say to the requester, "based on what I heard you say, this is what I think you want me to do".
The requester can provide feedback of "that's not what I meant" and the high level requirements refined until the feedback is "yes, that's what I want".
The goal is to get this defined and agreed upon BEFORE we start writing code (and thus eliminate spending unnecessary time/money)
[/EXPLANATION]
User Request:
Text only video (primary requirement)
Both VGA and composite (two implementations, user option)
Audio also is nice (secondary requirement)
Simplicity of use is important (This subjective definition is not quantifiable, therefore it must be refined in order to make it into a requirement)
Physical parameters:
RCA and VGA jacks, with cables; video and audio cable, and a power connector
Usage:
The end user to supply power.
Data to be sent to the device by a single pin on the controlling uC toggle on/off under program control.
Device must come up int the proper configuration on power-up. Any settable parameters must savable to the device.
Additional Text of user request:
Many uC's have very limited memory. Some as little as .5kb for program and data storage. Many of these
same uC's have only 4 I/O pins. Thus it seems important that the user be able to store some data inside the Prop's EEPROM for creating a video display....a sort of default display that will pop up when the unit powers on. then the uC could manipulate this default display in useful ways.
The language used to put this together is immaterial since it is to be a black box. I can't imagine most users would care what language was used.
Device is intended for: uC's with limited memory, .5kb; 4 I/O pins.
User expects something like "external dongle" so a fifty cent uC could have a removable video display.
================
User request outside of scope (of the software requirements)
Power by communication line: (I think, I'm not a hardware guy))
The external device could smooth out the DC input using a capacitor to hold enough current to keep the Prop powered during the short duration dropouts due to the sending of data. Linear regulators would provide the proper V needed. The Prop would of course need to read the data pulses at a point before the dc gets smoothed out by the capacitor filter. The users uC could toggle the line using a single pin to switch a small npn transistor like a pn2222.
NOTE: NO implementation details are accepted at this level. Specifying "pn2222" at this point would severely restrict development option that need not be committed at this time. This may be implemented as a separate functionality, but it is outside the scope of this functional requirement.
Holly:
So you are saying that Serial comm should be used? Is this correct?
Do you have a concept as to the type of communication protocol to use?
Should we use something along the lines of: 1-BYTE = command, fallowed by 1-BYTE = Data size, and then X-BYTES = DATA? If something like this: What would the default comm speed be? What would the MAX and MIN comm speeds be?
Or do you think it would work better to use something like I2C and address mapped registers?
[EXPLANATION]
This post (#46) captures the official Engineering requirements for the prop black box video service.
The previous post is the official user requirements as interpreted by engineering (me in this case)
Earlier posts were conjecture
Subsequent posts will define and expand implementation.
The purpose of this post is for the developer to say to the requester, "based on what I heard you say, this is what I think you want me to do".
The purpose of this post is for the developer to say to the requester, "based on what we agreed on, this is what I am going to do".
The requester can provide feedback of "that's won't do what I want" and the Engineering requirements refined until the feedback is "yes, that will do it".
The goal is to get this defined and agreed upon BEFORE we start writing code (and thus eliminate spending unnecessary time/money)
NOTICE: In the section below "communications protocols:"
The statement "Status and command responses (to be defined in implementation requirements)"
the definition is not complete. This engineering requirement cannot be considered "final"
until the statement is updated to say "Status and command responses as defined in post #xxx)"
[/EXPLANATION]
Functional Requirement: Text only video (primary requirement)
VGA only (composite video and/or graphics will be addressed in separate requirements)
(Audio will be addressed in a separate requirement)
Physical parameters:
VGA jacks using demoboard pinout [pins 16, 17, 18 ,19, 20, 21, 22, 23]
VGA input on pin 7
a power connector
Usage:
Data to be sent to the device by a single pin on the controlling uC toggle on/off under program control.
Device must come up int the proper configuration on power-up. Any settable parameters must savable to the device.
communications protocols:
Inputs from the target to the prop black box:
ASCII text stream at standard baud rates (specifically 1200, 2400, 9600, 19.2K 56.7K 115K)
ANSI control codes
Outputs from the prop black box to the target:
ASCII text stream at standard baud rates (specifically 1200, 2400, 9600, 19.2K 56.7K 115K)
Status and command responses (to be defined in implementation requirements)
So you are saying that Serial comm should be used? Is this correct? .... communication protocol to use?
Thanks for the request for clarification. This is a vital part of the definition phase.
Should we use something along the lines of: 1-BYTE = command, fallowed by 1-BYTE = Data size, and then X-BYTES = DATA? If something like this: What would the default comm speed be? What would the MAX and MIN comm speeds be?
Please be cautious in this direction. The user should NOT be asked (or permitted) to define implementation details unless there is a specific constraint in place (there is not at this point, don't inflict any when they are not needed). Implementation detail should always be left to the implementer when ever possible.
In this case, I am implementing this version of this function, and I have already arrived at a scheme that roughly fits the stated user need and is within my ability (more or less). ANSI control is an established protocol that already defines these details. Except I don't know about baud rate - I better check that...
Of course, the requirements can change, or a different implementer can make different decisions.
@davidsanders - May I ask you start to define the functional requirement for Sigma Delta?
The user request does not specifically ask for Sigma Delta, but does ask for "a 32kb eeprom stuffed full of goodness", this this function qualifies.
As part of this experiment, if you feel so inclined, could you follow the format from post #46. Please use any definitions for input, output, hardware consideration, and functional limits that you feel appropriate. The experiment is to test how members of the community can work on a common project, and the format is part of the experiment.
Actually, I'm asking you to own the Sigma-Delta implementation. As it was you that offered the example, and I don't know anything about Sigma-Delta, you are probably more qualified.
Functional Requirements: ADC soft implementation, Sigma Delta on pins 1 and 3.
Serial Input and output on Pin 6, speed to be specified.
Physical requirements: Resistor (Value to be specified), on pin 1, Resistor on pin 3 (value to be specified), I capacitor from Vss to junction of resistors, and one capacitor from Junction of resistors to Vcc (capacitor values to be specified).
Usage: The current value of the Sigma Delta is sent in serial form, being an 8-bit value, the data is a raw binary signed 8-bit integer.
Functional Requirements: ADC soft implementation, Sigma Delta on pins 1 and 3.
Serial Input and output on Pin 6, speed to be specified.
Physical requirements: Resistor (Value to be specified), on pin 1, Resistor on pin 3 (value to be specified), I capacitor from Vss to junction of resistors, and one capacitor from Junction of resistors to Vcc (capacitor values to be specified).
Usage: The current value of the Sigma Delta is sent in serial form, being an 8-bit value, the data is a raw binary signed 8-bit integer.
Further requirement, any device communicating with the ADC should be able to read the data at "1.25 MegaSamples per second".
I wasn't really trying to be mean, just a little opportunistic on a jab. As Robert A. Heinlein suggested in "Stranger in a Strange Land", "The waiting will fill." It did as it often does.
Now, a Propeller sampling very fast is a good thing if the Propeller is also translating some of that data. For example, paired with some nice OpAmps with good sensitivity so certain signals may be characterized. The Propeller may draw conclusions in time for one of those slow micros to read via some kind of serialized connection. Nothing at all wrong with that. One of my projects has that as a requirement, but it will all fit in the Propeller with a cheap/fast external memory code boost. All you need is a little hardware and a Propeller program. I would call it a non-trivial task where the Propeller shines and can be shared.
To both of you:
I do enjoy good humor. If the host can handle the speed then it is quite useful, if not it will get what it can. Also there will be only a small 16 byte ring buffer, so that if the host can not handle the speed then it will get what it can handle.
Now, a Propeller sampling very fast is a good thing if the Propeller is also translating some of that data.
OpAmps ... Propeller .... serialized connection. ... has that as a requirement, ... a non-trivial task ...
@jazzed - Could you own the function "internal processing of sigma-delta data"?
It looks like have have a specific hardware configuration in mind, it this needed fo all sigma-delta?
Would it be reasonable to build off of davidsanders sigma-delta aquisition, or is this a different kettle of fish? (Ideally, developers would coordinate their requirements at the start and development at the end for complimentary functions)
@t0nyp12 -"What is the use of 1.25mega samples if you fill up your 32k prop ram in 1/10second As the bottle neck would be to get the data to the host."
PLEASE BEAR IN MIND - our job is NOT to second guess the user, or deny the user's request becaue it "doen't fit with my other project". Only the USER may make that judgement. The request is for the function; the user deciseds how to use it. We only implement it, exactly as requested, to the best of our ability.
EXAMPLE - for a VERY FAST EVENT, the user is only interested in events immediately before and after the event. In this case, 1/10 of a second is many times more data than the user needs. AND if a user really DID need 1.25M samples for hours at a time, the would probably have to get a large budget to buy something like that, and would not use a prop anyway (nor an undersized micro as reciever); or they would specify that in the requirement and somebody smart like jazzed would address THAT requirement.
@jazzed - Could you own the function "internal processing of sigma-delta data"?
It looks like have have a specific hardware configuration in mind, it this needed fo all sigma-delta?
Just letting you know I'm not ignoring you. Yes, I do have a very specific application "in mind", but have too many other things going on right now.
I can "own" a version of of internal processing, but there are so many possibilities.
I propose that a generic method of communicating services in a simple way is required. A complicated way is WSDL or Web Services Definition Language ... That's just too much for an MCU. What would work nicely though is an enumerated list of functions so that the user application knows how to deal with the device (with appropriate revision control which is painful, but necessary).
Lots of Cisco Systems switch/routers in large distributed machinces use what is called an IDPROM. The IDPROM essentially does what is mentioned above in addition to providing some serialization and manufacturing info. This may have been discussed already, but I've had trouble parsing a lot of what's been said so I probably just missed it.
Anyway. An IDPROM section can be as small as say 128 bytes or relatively large, but should it should be flexible. A chain of 128 byte blocks can be crafted using a linked list approach (with a checksum or CRC16 at the last word)... the user's internal data representation can be a performance oriented data structure or selectively used. Data in an IDPROM section is typically write once read many. IDPROM is probably not the best name to use, but is ok just for communicating the idea.
So basically, all that becomes the "final" or "readonly" data that can define a "Holly Device" in a similar way that an "object" of a class may use it. There are complications such as endian-ness, but that is solved by just saying: look, it's "network order" just like the internet requires ... C function htons comes to mind. Check this link for an description of the solution: http://beej.us/guide/bgnet/output/html/multipage/htonsman.html .... I have not read it fully, but at first glance it looks right.
The thing about such device descriptors is the desire for change as device types multiply. future-proofing is difficult especially if someone insists that common fields must be integer or string, etc.... Pointers in common fields will help future-proofing, but even that can fail. I guess what I'm trying to say is that many devices should be in use before a standard is adopted for obvious reasons: mainly, if it works for 3 devices, it might work for 4, but maybe not for the 40th.
Confidence arises only with large scale adoption ... unfortunately, nothing get's large scale adopted around here unless Parallax says "we support this as a standard platform". Where does that leave things? Well, all you can do is try if you think you have a good idea. There's always a nay-sayer around to try and slap you down. If you're fully committed to something, take Nike's advice and "just do it!" In the end there will always be some waste, but that is manageable with periodic examination and adjustment.
I can "own" a version of of internal processing, but there are so many possibilities.
I propose that a generic method of communicating services in a simple way is required.
WOW!
This is great stuff, but in the interest of controling function creep, I ask that we consider the following:
The original request is just for function that can be used with a prop as a black box.
To me this means like an old external modem, or a usb hub, or a monitor. The device requires X hardware interface, recieves X inputs, and produces X outputs.
In my opinion, everything after the second line of your post, while a great idea and relflect extensive experience and broad techincal knowledge, is out of scope of the current request. Perhaps it should be saved for Phase 2 in case Phase 1 ever has a usable result. Or put on a separate thread and developed as an independant effort.
Can "internal processing of sigma-delta data" be defined as the set of inputs, processing, and output that will be the functional parameters, such that another developer could "do the coding"? This is what I see the scope of this thread's discussion to be.
If you need simple stuff, there are far easier ways to achieve it than what you seem to be asking.
I recommend using a MPS3021 if you need a simple I2C ADC.
For more complicated I2C ADCs, an AVR or some other cheap chip is best.
Propeller could be used for something interesting like the speech recognition code, but some type of an interface structure would be needed to take advantage of it. If you're not willing to accommodate that, then i'm not interested.
Propeller could be used for something interesting like the speech recognition code, but some type of an interface structure would be needed to take advantage of it. If you're not willing to accommodate that, then i'm not interested.
This project is willing to accommodate all work anyone wishes to contribute. IF you feel that an interface structure is the most important function and needs to be implemented first, please do it. You have much further vision than I, as well broader skill and technical knowledge.
As a process guy, my function is ensure conformance to requirements, thus guard against scope creep is part of my routine. But changing of requirements and scope is permitted, we just have to acknowledge and impacts (to schedule, resources, design, etc.) I only see the individual functions in the black box, since that was the request. But if the logical design indicates the interface structure, that must be the way to go.
At this point the physical layer interface is unclear to me. Do we just pick something that fits the needs of the device? It seems like asynchronous serial is most common although TWI/I2C is also very common.
Maybe the protocol can be used to differentiate an asynchronous serial interface from an I2C interface.
Since Propeller can receive serial or I2C simultaneously, it should be able to discern the user's intrerface requirement and adjust (... i.e. the I2C SCL line could be used for serial receive and SDA for transmit). I would call this ability a unique propeller strength
So I guess any "serial" device should respond to a type query command, and either refuse service or accept and attempt to do the right thing. The only problem with that strategy is program space, but I suspect that a complex device would need a buffer of sorts and cog code space can be recycled.
Different data transports would be necessary for different physical device interfaces, so it would be good to chose one physical interface if possible. Text based serial ports are good for debugging, etc..., but may not always be appropriate. A simple ASCII command interface might work for serial ports, but would be a big waste for I2C. I2C allows register mapping which would be good for "structured devices."
Being able to separate the transport and protocol layers would be very helpful for a generic solution. I think a case by case implementation is fine for a simple start, but may need rethinking for a follow-on solution.
My schedule is packed until mid-June so I won't be contributing anything tangible until then.
Comments
Since these are requested to be "black box" services, my understanding is that a give EEPROM image will reside in lower 32K EEPROM.
The initial requirement is then assumed to be the EEPROM image premanently reside in default 32K EEPROM and will NOT be modified in any way during use.
Of course this requirement could be revised as needed. Maybe when there are more than one function and functionality expandes beyond 32K of code we could examine this possibility.
If anybody sees a problem with this, please chime in.
Long ago the teletype was invented. The teletype was a printer controlled by a "current loop" or a serial port. The analogy is that some mechanical or other interface can be controlled through a simple protocol.
PLCs may be a natural extension. I wonder if Allen-Bradley would be interested in small Propeller based controllers ... guess they're using something else already.
What other applications could benefit?
Is this tread intended for moderately complex devices or trivial ones?
It is reasonable, but quite limited. What you are describing is a 'Canned Demo', and if the user has a board with that much resource, why do they need physical delivery of a separate EEPROM ? The NET does that better and cheaper.
It also presumes the 'Canned Demo' is precisely what the user wanted.
If it is merely close, they need to get the Source code, in which case, why not start there ?
One of my pet peeves is systems that do NOT include working examples, or included only source files, and no snapshot captures. Map and report files can provide valuable insight.
So morphing the idea away from a Physical EEPROM, which is doomed to fail, to more 'Internet Canned Demo' in concept, I can see a benefit in allowing the user to directly download the binary image, and quickly try it, before they grab the project.
I also like the idea of 'Defining Corner Pegs' type examples, which push the Chip, and illustrate just what CAN be done.
As an real example: Suppose I ask just how fast a rotary encoder pulse rate CAN a Prop follow/count ?
One template says 144clks for the first and +50 for added ones - but is that the best ?
I would like to see any $1.00 ADC that can keep up with the Prop with Sigma Delta at 1.25 MegaSamples per second.
Because the project is to see if the community can work together to fullfil a request to make black box functionality available to other micros. We can address other requests as a separate effort on a separate thread.
Thanks for your participation and support. There are some details eariler in the thread that you may have missed.
While this is certainly this is an option, perhaps we should focus on getting a couple functions into an EEPROM per the request before we go beyond the scope of the original request.
The first EXAMPLE is for the function of VGA monitor to display text from a Tiny85 or other micro that cannot display VGA easily. This is not a demo, this is hooking up a display to a Tiny85. All we need to establish is the interfaces, which has been started.
Let try nother example: davidsanders has suggested Sigma Delta. If davidsanders defines the input the Sigma Delta function will take, and the output the Sigma Delta will deliver, we could code that function into an EEPROM so the prop be connected to a suitable signal, and deliver that output to a device, perhaps in an existing product that does not signa delta so well.
Don't make it hard, this is a very simple. The difficulty seems to be staying focused on the original request and intent of the discussion. We take any given function that the prop already performs, and define a set of inputs and outputs to that function, and interfaces between the micros, and we can have prop provide blck box functionality to other props or AVRs or PICs or whatever.
Maybe the concept of defining interfaces is the problem. An well known example of this could be an old style external modem. The modem had two physical interfaces: One interface was to the phone company, the other was to the PC. The modem had software interfaces, one was the AT command codes , the other was stuff the modem did with the phone company and the other modem. Why have a separate microcontroler in the modem when there wa a perfectly good one in the PC? Because the modem off--loaded those functions from the PC. In fact the "modems" that used the PC to do all the work were a nightmare. So the modem was micro in a black box that provided services to the PC, and did so with well defined interfaces.
Yes, one could just use the prop directly for everything; yes, you could just go buy a modem, and yes, everything under the sun has been done already. This experiement is to see if we can define the interfaces for a function or two that the prop could provide as a service to another device. Maybe I am not expressing myself clearly, can somebody else state this more succintly? Or have we reached that the limit of this effort?
1) 2 bytes for the Character Col/Row resolution, a rectangular buffer following this for the Text buffer that the other micro sees.
2) A 1 Byte space for basic ASCII character input from the other micro, with another byte for extended keys (need to define a standard for extended keys).
3) A 1 Byte buffer for the current Sigma Delta value. And 2 byte configuration buffer, one byte defining the number of valid bits, and thus the speed, the other used as a enable flag. Duplicate this as many times as implemented Sigma Delta.
4) A space to write some simple form of vector drawing commands (format of vector drawing to be determined).
What I had in mind was that at lest initially, the "addressing" would be simply via pins.
That is, in the case of video, the remote micro sends a byte stream from the target's I/O pin to prop pin 7 for example. The prop sends VGA image of the text out on pins 16-23 per the default demoboard configuration. At this level, we do not have to consider buffering, etc, as those are implementation detail that are best left to the engineer doing the coding at a later date.
In the case of Sigma Delta, I image that the prop would be reading a singal, and sending the data to the remote micro. If this is the case, signal would come in through pin 6 (or would it come in from the electret mic on pin 9? I don't know much about sigma delta) and the output could be sent to the remote micro on pin 5.
In this method, "addressing" is simple, it just pin allocation.
The "interfaces" are items like:
Example: "The VGA function will receive a byte stream on pin 7 of ASCII text and ANSI control codes at 9600 to 115k baud, default at 9600 and application selectable using control sequence XXX. VGA output will be on pin 16-23 through a standerd VGA connector per demoboard configuration."
Example: "The Sigma Delta function will recieve a signal from DC to 80Mhz at a mx voltage of 5V on pin 6 and output a string of text at 9600 baud to the remote micro on pin 5. (or whatever)"
For the time being, we don't need to worry about sharing input and out pins between functions. We only have two functions, and they only use 11 pins between them.
it would be nice to have an external implementation
of this idea. A very small box with RCA and VGA jacks
on it or with cables coming out terminated with RCA and
VGA connectors. The cable idea might be the cheapest
way to go since cables are so inexpensive and that way
the end user would not need to scrounge around for one.
So picture a small device with video and audio cable exiting
out one end and just a power connector on the other end.
To keep costs minimal you could even dispense with the
case and pot the device inside a square block of potting
compound.
The end user would supply power to the device from her
project. Data would be sent to the device by having a single
pin on the controlling uC toggle the + line on/off under program
control. the Prop could read the incoming data with an input pin.
The external device could smooth out the DC input using a capacitor
to hold enough current to keep the Prop powered during the short
duration dropouts due to the sending of data. Linear regulators
would provide the proper V needed. The Prop would of course need
to read the data pulses at a point before the dc gets smoothed
out by the capacitor filter. The users uC could toggle the line using
a single pin to switch a small npn transistor like a pn2222.
This is the most minimalistic idea for an external implementation
that I can come up with...it seems like it should be workable.
Many uC's have very limited memory. Some as little
as .5kb for program and data storage. Many of these
same uC's have only 4 I/O pins. Thus it seems important
that the user be able to store some data inside the Prop's
eeprom for creating a video display....a sort of default
display that will pop up when the unit powers on. then
the uC could manipulate this default display in useful ways.
Using the external dongle implementation a fifty cent uC
could have a nice video display... and the display dongle
could be moved from device to device. This would be a nice
debugging system or the basis of a simple data analyzer
setup.
The hardware cost to add the ability to communicate with
such a video dongle for any uC project would be little more than the
cost of the NPN transistor....15 cents or so. The idea is so simple
that this functionality could be easily added to most existing projects
and devices.
A gizmo like this would sell...IMO
This post (#44) captures the official user requirements for the prop black box video service.
The previous post is the request from the user
Earlier posts were conjecture
Subsequent posts will define and expand internal requirements and implementation.
The purpose of this post is for the developer to say to the requester, "based on what I heard you say, this is what I think you want me to do".
The requester can provide feedback of "that's not what I meant" and the high level requirements refined until the feedback is "yes, that's what I want".
The goal is to get this defined and agreed upon BEFORE we start writing code (and thus eliminate spending unnecessary time/money)
[/EXPLANATION]
User Request:
Text only video (primary requirement)
Both VGA and composite (two implementations, user option)
Audio also is nice (secondary requirement)
Simplicity of use is important (This subjective definition is not quantifiable, therefore it must be refined in order to make it into a requirement)
Physical parameters:
RCA and VGA jacks, with cables; video and audio cable, and a power connector
Usage:
The end user to supply power.
Data to be sent to the device by a single pin on the controlling uC toggle on/off under program control.
Device must come up int the proper configuration on power-up. Any settable parameters must savable to the device.
Additional Text of user request:
Many uC's have very limited memory. Some as little as .5kb for program and data storage. Many of these
same uC's have only 4 I/O pins. Thus it seems important that the user be able to store some data inside the Prop's EEPROM for creating a video display....a sort of default display that will pop up when the unit powers on. then the uC could manipulate this default display in useful ways.
The language used to put this together is immaterial since it is to be a black box. I can't imagine most users would care what language was used.
Device is intended for: uC's with limited memory, .5kb; 4 I/O pins.
User expects something like "external dongle" so a fifty cent uC could have a removable video display.
================
User request outside of scope (of the software requirements)
Power by communication line: (I think, I'm not a hardware guy))
The external device could smooth out the DC input using a capacitor to hold enough current to keep the Prop powered during the short duration dropouts due to the sending of data. Linear regulators would provide the proper V needed. The Prop would of course need to read the data pulses at a point before the dc gets smoothed out by the capacitor filter. The users uC could toggle the line using a single pin to switch a small npn transistor like a pn2222.
NOTE: NO implementation details are accepted at this level. Specifying "pn2222" at this point would severely restrict development option that need not be committed at this time. This may be implemented as a separate functionality, but it is outside the scope of this functional requirement.
So you are saying that Serial comm should be used? Is this correct?
Do you have a concept as to the type of communication protocol to use?
Should we use something along the lines of: 1-BYTE = command, fallowed by 1-BYTE = Data size, and then X-BYTES = DATA? If something like this: What would the default comm speed be? What would the MAX and MIN comm speeds be?
Or do you think it would work better to use something like I2C and address mapped registers?
This post (#46) captures the official Engineering requirements for the prop black box video service.
The previous post is the official user requirements as interpreted by engineering (me in this case)
Earlier posts were conjecture
Subsequent posts will define and expand implementation.
The purpose of this post is for the developer to say to the requester, "based on what I heard you say, this is what I think you want me to do".
The purpose of this post is for the developer to say to the requester, "based on what we agreed on, this is what I am going to do".
The requester can provide feedback of "that's won't do what I want" and the Engineering requirements refined until the feedback is "yes, that will do it".
The goal is to get this defined and agreed upon BEFORE we start writing code (and thus eliminate spending unnecessary time/money)
NOTICE: In the section below "communications protocols:"
The statement "Status and command responses (to be defined in implementation requirements)"
the definition is not complete. This engineering requirement cannot be considered "final"
until the statement is updated to say "Status and command responses as defined in post #xxx)"
[/EXPLANATION]
Functional Requirement: Text only video (primary requirement)
VGA only (composite video and/or graphics will be addressed in separate requirements)
(Audio will be addressed in a separate requirement)
Physical parameters:
VGA jacks using demoboard pinout [pins 16, 17, 18 ,19, 20, 21, 22, 23]
VGA input on pin 7
a power connector
Usage:
Data to be sent to the device by a single pin on the controlling uC toggle on/off under program control.
Device must come up int the proper configuration on power-up. Any settable parameters must savable to the device.
communications protocols:
Inputs from the target to the prop black box:
ASCII text stream at standard baud rates (specifically 1200, 2400, 9600, 19.2K 56.7K 115K)
ANSI control codes
Outputs from the prop black box to the target:
ASCII text stream at standard baud rates (specifically 1200, 2400, 9600, 19.2K 56.7K 115K)
Status and command responses (to be defined in implementation requirements)
Thanks for the request for clarification. This is a vital part of the definition phase.
Please be cautious in this direction. The user should NOT be asked (or permitted) to define implementation details unless there is a specific constraint in place (there is not at this point, don't inflict any when they are not needed). Implementation detail should always be left to the implementer when ever possible.
In this case, I am implementing this version of this function, and I have already arrived at a scheme that roughly fits the stated user need and is within my ability (more or less). ANSI control is an established protocol that already defines these details. Except I don't know about baud rate - I better check that...
Of course, the requirements can change, or a different implementer can make different decisions.
The user request does not specifically ask for Sigma Delta, but does ask for "a 32kb eeprom stuffed full of goodness", this this function qualifies.
As part of this experiment, if you feel so inclined, could you follow the format from post #46. Please use any definitions for input, output, hardware consideration, and functional limits that you feel appropriate. The experiment is to test how members of the community can work on a common project, and the format is part of the experiment.
Actually, I'm asking you to own the Sigma-Delta implementation. As it was you that offered the example, and I don't know anything about Sigma-Delta, you are probably more qualified.
Functional Requirements: ADC soft implementation, Sigma Delta on pins 1 and 3.
Serial Input and output on Pin 6, speed to be specified.
Physical requirements: Resistor (Value to be specified), on pin 1, Resistor on pin 3 (value to be specified), I capacitor from Vss to junction of resistors, and one capacitor from Junction of resistors to Vcc (capacitor values to be specified).
Usage: The current value of the Sigma Delta is sent in serial form, being an 8-bit value, the data is a raw binary signed 8-bit integer.
Further requirement, any device communicating with the ADC should be able to read the data at "1.25 MegaSamples per second".
That would eliminate many low end MCUs.
Good one though.
What is the use of 1.25mega samples if you fill up your 32k prop ram in 1/10second
As the bottle neck would be to get the data to the host.
So I don't see the use from using the prop to sample anything, and there are plenty of i2c/spi A/D out there for the low end mcu to use.
Now, a Propeller sampling very fast is a good thing if the Propeller is also translating some of that data. For example, paired with some nice OpAmps with good sensitivity so certain signals may be characterized. The Propeller may draw conclusions in time for one of those slow micros to read via some kind of serialized connection. Nothing at all wrong with that. One of my projects has that as a requirement, but it will all fit in the Propeller with a cheap/fast external memory code boost. All you need is a little hardware and a Propeller program. I would call it a non-trivial task where the Propeller shines and can be shared.
Cheers.
I do enjoy good humor. If the host can handle the speed then it is quite useful, if not it will get what it can. Also there will be only a small 16 byte ring buffer, so that if the host can not handle the speed then it will get what it can handle.
@jazzed - Could you own the function "internal processing of sigma-delta data"?
It looks like have have a specific hardware configuration in mind, it this needed fo all sigma-delta?
Would it be reasonable to build off of davidsanders sigma-delta aquisition, or is this a different kettle of fish? (Ideally, developers would coordinate their requirements at the start and development at the end for complimentary functions)
@t0nyp12 -"What is the use of 1.25mega samples if you fill up your 32k prop ram in 1/10second As the bottle neck would be to get the data to the host."
PLEASE BEAR IN MIND - our job is NOT to second guess the user, or deny the user's request becaue it "doen't fit with my other project". Only the USER may make that judgement. The request is for the function; the user deciseds how to use it. We only implement it, exactly as requested, to the best of our ability.
EXAMPLE - for a VERY FAST EVENT, the user is only interested in events immediately before and after the event. In this case, 1/10 of a second is many times more data than the user needs. AND if a user really DID need 1.25M samples for hours at a time, the would probably have to get a large budget to buy something like that, and would not use a prop anyway (nor an undersized micro as reciever); or they would specify that in the requirement and somebody smart like jazzed would address THAT requirement.
I can "own" a version of of internal processing, but there are so many possibilities.
I propose that a generic method of communicating services in a simple way is required. A complicated way is WSDL or Web Services Definition Language ... That's just too much for an MCU. What would work nicely though is an enumerated list of functions so that the user application knows how to deal with the device (with appropriate revision control which is painful, but necessary).
Lots of Cisco Systems switch/routers in large distributed machinces use what is called an IDPROM. The IDPROM essentially does what is mentioned above in addition to providing some serialization and manufacturing info. This may have been discussed already, but I've had trouble parsing a lot of what's been said so I probably just missed it.
Anyway. An IDPROM section can be as small as say 128 bytes or relatively large, but should it should be flexible. A chain of 128 byte blocks can be crafted using a linked list approach (with a checksum or CRC16 at the last word)... the user's internal data representation can be a performance oriented data structure or selectively used. Data in an IDPROM section is typically write once read many. IDPROM is probably not the best name to use, but is ok just for communicating the idea.
So basically, all that becomes the "final" or "readonly" data that can define a "Holly Device" in a similar way that an "object" of a class may use it. There are complications such as endian-ness, but that is solved by just saying: look, it's "network order" just like the internet requires ... C function htons comes to mind. Check this link for an description of the solution: http://beej.us/guide/bgnet/output/html/multipage/htonsman.html .... I have not read it fully, but at first glance it looks right.
The thing about such device descriptors is the desire for change as device types multiply. future-proofing is difficult especially if someone insists that common fields must be integer or string, etc.... Pointers in common fields will help future-proofing, but even that can fail. I guess what I'm trying to say is that many devices should be in use before a standard is adopted for obvious reasons: mainly, if it works for 3 devices, it might work for 4, but maybe not for the 40th.
Confidence arises only with large scale adoption ... unfortunately, nothing get's large scale adopted around here unless Parallax says "we support this as a standard platform". Where does that leave things? Well, all you can do is try if you think you have a good idea. There's always a nay-sayer around to try and slap you down. If you're fully committed to something, take Nike's advice and "just do it!" In the end there will always be some waste, but that is manageable with periodic examination and adjustment.
Cheers.
WOW!
This is great stuff, but in the interest of controling function creep, I ask that we consider the following:
The original request is just for function that can be used with a prop as a black box.
To me this means like an old external modem, or a usb hub, or a monitor. The device requires X hardware interface, recieves X inputs, and produces X outputs.
In my opinion, everything after the second line of your post, while a great idea and relflect extensive experience and broad techincal knowledge, is out of scope of the current request. Perhaps it should be saved for Phase 2 in case Phase 1 ever has a usable result. Or put on a separate thread and developed as an independant effort.
Can "internal processing of sigma-delta data" be defined as the set of inputs, processing, and output that will be the functional parameters, such that another developer could "do the coding"? This is what I see the scope of this thread's discussion to be.
"scope creep" is my favorite demon!
I recommend using a MPS3021 if you need a simple I2C ADC.
For more complicated I2C ADCs, an AVR or some other cheap chip is best.
Propeller could be used for something interesting like the speech recognition code, but some type of an interface structure would be needed to take advantage of it. If you're not willing to accommodate that, then i'm not interested.
Since the Prop has already proven itself in that area, I second the request for Speech recognition.
This project is willing to accommodate all work anyone wishes to contribute. IF you feel that an interface structure is the most important function and needs to be implemented first, please do it. You have much further vision than I, as well broader skill and technical knowledge.
As a process guy, my function is ensure conformance to requirements, thus guard against scope creep is part of my routine. But changing of requirements and scope is permitted, we just have to acknowledge and impacts (to schedule, resources, design, etc.) I only see the individual functions in the black box, since that was the request. But if the logical design indicates the interface structure, that must be the way to go.
Maybe the protocol can be used to differentiate an asynchronous serial interface from an I2C interface.
Since Propeller can receive serial or I2C simultaneously, it should be able to discern the user's intrerface requirement and adjust (... i.e. the I2C SCL line could be used for serial receive and SDA for transmit). I would call this ability a unique propeller strength
So I guess any "serial" device should respond to a type query command, and either refuse service or accept and attempt to do the right thing. The only problem with that strategy is program space, but I suspect that a complex device would need a buffer of sorts and cog code space can be recycled.
Different data transports would be necessary for different physical device interfaces, so it would be good to chose one physical interface if possible. Text based serial ports are good for debugging, etc..., but may not always be appropriate. A simple ASCII command interface might work for serial ports, but would be a big waste for I2C. I2C allows register mapping which would be good for "structured devices."
Being able to separate the transport and protocol layers would be very helpful for a generic solution. I think a case by case implementation is fine for a simple start, but may need rethinking for a follow-on solution.
My schedule is packed until mid-June so I won't be contributing anything tangible until then.