Holly's Request
prof_braino
Posts: 4,313
EEPROM Images for Prop Services (to a microcontroller)
In response to Holly Minkowski request from post:
http://forums.parallax.com/showthread.php?131434-Prop-II-Too-little-too-late&p=997931&viewfull=1#post997931
"We should all pitch in and design a 32kb eeprom stuffed full of goodness for the users of lesser uCs. "
"Come on guys, this is a really good idea! :-)"
I suggest we conduct an experiment to test the extent that the prop community can "pitch in and design".
What does this request mean?
I imagine it is something like taking for example objects from the OBEX and pre-packaging them into EEPROM images.
Or functions not in the OBEX that are "needed" and new code written to produce the EEPROM images.
These images can be loaded into a props EEPROM, and when the programmed prop is properly connected to (any) micro controller, the prop will provide a set of services to the microcontroler.
The services would provide functionality the the target micro cannot or would otherwise cause difficulty.
The services can be functions the target is incapable of, or increase capacity of the target's existing function.
A person in a Process Management role might suggest that the development process should contain iterative cycles of both Top-Down and Bottom-Up development techniques.
This is something like establishing a high level set of target functions, to be used in defining the next lower level of functions.
As each level is defined, the previous levels are checked for impact, and adjusted accordingly.
The initial recommentation is that
A) the governing high level requirements be defined before that next lower level supporting requirements/functionality are finalized;
and
that discoveries from lower level implementation "experiments" be checked for impact on the high level requirements, to determine if modification is needed.
A person in a Process Management role might also suggest that the Requestor (Holly or desiginee) is final arbitrator of engineering conflicts, and has final say on all design desisions.
Someone has to be the single authority in charge, and she asked for it, I nominate Holly for this role.
So Here is a stab at a first draft of requirements.
All these items are to be expanded and refined until we produce an EEPROM image or give up.
Please chime in with contributions, suggestions, criticisms, and predictions of success or failure.
High level statement of intent:
Define and implement EEPROM image of functions such that a propellor chip may provide services to an external microcontroler.
Targeted microcontrolers:
In response to Holly Minkowski request from post:
http://forums.parallax.com/showthread.php?131434-Prop-II-Too-little-too-late&p=997931&viewfull=1#post997931
"We should all pitch in and design a 32kb eeprom stuffed full of goodness for the users of lesser uCs. "
"Come on guys, this is a really good idea! :-)"
I suggest we conduct an experiment to test the extent that the prop community can "pitch in and design".
What does this request mean?
I imagine it is something like taking for example objects from the OBEX and pre-packaging them into EEPROM images.
Or functions not in the OBEX that are "needed" and new code written to produce the EEPROM images.
These images can be loaded into a props EEPROM, and when the programmed prop is properly connected to (any) micro controller, the prop will provide a set of services to the microcontroler.
The services would provide functionality the the target micro cannot or would otherwise cause difficulty.
The services can be functions the target is incapable of, or increase capacity of the target's existing function.
A person in a Process Management role might suggest that the development process should contain iterative cycles of both Top-Down and Bottom-Up development techniques.
This is something like establishing a high level set of target functions, to be used in defining the next lower level of functions.
As each level is defined, the previous levels are checked for impact, and adjusted accordingly.
The initial recommentation is that
A) the governing high level requirements be defined before that next lower level supporting requirements/functionality are finalized;
and
that discoveries from lower level implementation "experiments" be checked for impact on the high level requirements, to determine if modification is needed.A person in a Process Management role might also suggest that the Requestor (Holly or desiginee) is final arbitrator of engineering conflicts, and has final say on all design desisions.
Someone has to be the single authority in charge, and she asked for it, I nominate Holly for this role.
So Here is a stab at a first draft of requirements.
All these items are to be expanded and refined until we produce an EEPROM image or give up.
Please chime in with contributions, suggestions, criticisms, and predictions of success or failure.
High level statement of intent:
Define and implement EEPROM image of functions such that a propellor chip may provide services to an external microcontroler.
Targeted microcontrolers:
-
1. Prop (example multi-porp configurations)
2. AVR (example Arduino, ATmega8, ATmega168, ATmega328, and ATmega1280)
3. ARM (example Cortex somebody help me out here)
4. PIC (examples?)
5. X
High Level Statement of Functions:
1. handling video
2. audio
3. precision timing chores
4. X
Interfaces:
1. Development interface(s)
2. Microcontroler physical interfaces
3. Microcontroler logical interfaces
Data Description:
1. Serial/Parallel Data Stream
2. Data records
3. Digital/Analog
Clock/Timing Constraints
1. Propellor frequency
2. Target frequency
Logical Grouping of functions:
1. Must fit in 32K or less
2. Provisions for user selection of functions per image?
3. Provisions for user configuration of functions?
???
Your Input Goes Here. Any takers?
Comments
some questions:
what functions are arduino-shields covering? Could a propeller-based solution be cheaper more versatile?
what functions do arduino-shields NOT covering? Is there a big demand in other MCU-forums for those things?
best regards
Stefan
32K is tiny from an Internet perspective, and i2c EEPROMs are everywhere, so why make a special one ?
It is a good idea to package code/examples, but I would focus that on the internet, and ensure users CAN
get a low cost i2c programmer.
I presume the $20 board can do USB-EE loading ? - can anyone go better than that ?
Three URLs pointing to stuff in the some cents range:
http://www.paintyourdragon.com/?p=43
http://www.mjmwired.net/kernel/Documentation/i2c/busses/i2c-parport
http://pyi2c.sourceforge.net/
You (a developer) are to state the functions that your target micro needs but cannot provide, and that the prop will provide instead. I suppose we need Holly to lead on definition of functions since she is the primary/inital user.
Q1: A propeller solution could be cheaper for any function, in the cases that I have a propeller and programs for it, and I don't have the other alternatives on my desk (which is the case for me now).
Q2: This (arduino function NOT covered) is not so relavant until we determine what functions are needed.
Yes
Because we were ask to do so,
Yes, and will will do that, but lets take a look at this excercise for a bit
A low cost I2C programmer is a separate issue for the time being.
These are very important data, but can we put them outside the scope of this experiment?
For the purpose of this exercise, assume user already has prop, bread board, wire, etc, and is only interested in the functionality in an EEPROM able image. In fact, this is exactly the situation in my lab at the moment, so at least for the development cases, the hardware cost is zero.
External I2C re-programming cable is not important right now.
The whole idea is to give user the feeling that this is an ASIC chip.
So if if the 32k is packet with good stuff, it's good-to-go.
All the prop-commands should go through a single communication cog
That supports 8bit Parallel, 4bit Quad-SPI or 1 Bit SPI/I2C/Uart
Users choice by using jumper or solder pull-up/down resistors etc.
I do think a Prop and a small kit of parts that create a powerful
peripheral processor for lesser uCs to utilize to get video/audio
and other abilities could be popular.
Parallax would be the preferred source of such a kit since only
they can get the Prop at a price that would allow the kit to be
sold at a very low cost. A prop, a 40pin socket for the DIP version,
a pre-programmed eeprom, a crystal and a set of the resistors
needed for NTSC/PAL/VGA would make up the kit.
I2C of course would be the main method of communications but
it would be nice to also have a simple scheme for single pin
communications....this would be great for minimal uCs that have
only 4 to six I/O pins. Since the prop can have a 20mips cog
dedicated to just the communications chores it would allow
for a wide variation in data speed. Hacked together C functions
running at variable speed could be usable. Mostly projects that
use uCs like the Tiny85 don't depend on a crystal since it takes
up two of the I/O pins, they use the internal adjustable rc timer.
The Tiny85 can run at 16.5mhz with enough precision to use
the open source V-USB for USB 1.1 I assume it would be possible
to use this USB connection to make changes to the data in the Prop's
eeprom chip.
Flags could be changed in the eeprom just by having
the controlling uC send a command to do so This would make it easy
to customize the way the Prop would perform its role.
It would be important to ensure that the eeprom could not be corrupted
and thereby brick the prop kit....few things upset a beginning hobbyist
more than bricking their new toy.
I realize that many will consider the idea of the Prop being used as
nothing more than a peripheral chip for other uCs to be distasteful.
But actually that role is an honorable one, and it would expose many
to the Prop and there would be converts :-)
If something like this is undertaken then it will be very important that
it be done right. Someone that can devote considerable time and who
has better engineering skills than I do would be required, my electronics
knowledge is meager at best. My skills are mainly in C for uCs other
than Prop and for the next 7 months I will only have a small amount of
time for projects and I am almost always away from my workbench and
tools/parts, they are in Haifa and I am stuck elsewhere doing boring
research.
I feel it would be nice for there to be a way that uC aficionados could get
a taste of the Prop's power without needing to know anything about SPIN
or PASM.
Outside the box thinking would enhance a project like this. Since a cog
can be dedicated to watching for and decoding incoming data it should be
possible to make sense out of nearly any comm method other than perhaps
smoke signals. Data over the power leads would be a nice touch.
But as: Surface mountable module with castellated mounting holes.
1) Sigma Delta ADC, This is faster on the Prop.
2) VGA.
3) Composite NTSC.
4) Serial com with PC by way of USB through FTDI (less expensive than comparable solutions).
5) PS/2 (this may cost a bit more than directly on an ATMEGA).
And all of this could be put on a single board, thus further reducing the overall cost. Components needed are:
VGA header ($2.50 US).
2 X 6-pin mini DIN PS/2 headers ($1.50 US each).
4 X surface mount resistors (for two ADCs, $0.005 US each).
4 X Surface mount caps ($0.05 US each).
1 P8X32A-XXX ($7.99 US each).
1 3.3V power regulator ($1.50 US each).
1 PCB (price varies).
Headers
and TIME.
A separate microcontroller sends it information to display on a TV screen. It does lots of other cool stuff too.
I do have some reservation on this EEPROM idea. In order to access all the features in the EEPROM the user will have to learn the appropriate commands to send to the slave Propeller. Would learning the correct commands, be so much easier, than learning to use the Prop for themselves, to make it worth it? I personally think the user would be better off learning to use the Propeller for themselves.
One positive aspect of the project is that it could make it easier to slave a second Prop to a master. I just don't see a one solution fix for slave/master communication. What if you want the slave Prop to listen to a serial line and only bother the master is a certain message is received. I'm afraid having a single EEPROM image that has many slave Prop objects would be very complicated to use and also too limiting. I may well be wrong. I find the Propeller Backpack a useful slave Prop. Maybe you all can come up with a better general slave. (Do we have a bounty hunter we can clone?)
Duane
People that are passionate about their 8/16bit mcu and don't have the urge to learn coding a new one.
I could see a vga/video only module.
10 pins for communication, user can choose to use as little as 2pins (I2C) if bandwidth is not an object.
16 pins for VGA, regular 6bit+HV but also a 14bit RGB mode for real-time dxt1 decoding.
4 pins for video
2 pins for communication protocol settings by resistors/jumpers
There are only 4 commands.
Write to memory location, with optional or/and/xor flag (good if u want a cursor/sprite etc)
Read from memory (with optional flag to clear address after read etc)
Burst Write to memory
Burst Read from memory
User will given address maps for each vga/video mode, to change text,color or pixels.
Sounds good.
Though there would still be other 'Commands', writing to the correct memory location to change the video mode would be a type of command for example.
Each command have 3bits for flags, so a specfic one will be used to produce a no-write for this location.
and instead is intercepted to change video mode.
Or I simple include a 5th command, that writes video mode settings.
Yes of course it would be worth it. Especially video, which is very complex. My eyes cloud over when we get to "back porch lines".
There is no requirement for "one solution", only that the functionality be EEPROM suitable.
The requirement here has not be clarified, the requirement should be rephrased:
"Any give EEPROM image will have a collection of functions such that the prop is a black box provider of a function. There can be many images with differing collection of functions. "
This is about software, the specifics of a given hardware platform is a separate issue.
Several questions:
Is this a language neutral proposition?
How exactly would a user of the other targeted "client" micros interface with the propeller services module?
Is there some simple protocol transport layer that will be usable by any of the micros?
Is there a reason atTiny is not on your list of targeted micros?
Lets assume that the Propeller Backpack is the prefered solution for displaying characters on TV, so this function can be outside the scope of this effort.
Might be a side-effect, but this is not the intent. The task is to make EEPROM-able functions such that the prop can be used as a "black-box" to provide services to another micro. This is the extent of the highest level request. Everything else is to be outside this poroject's scope (unless Holly decides to chnage the inital request). This is to control "function creep".
This is the direction that will advance the project. Thanks jazzed!
The final functions are to be "black-box"; any language may be used. The end-user need not access the implementation language,
Interface: In the case of a prop as the second micro, a direct pin to pin connection is sufficient for a serial connection, agreed? I am guessing that this method would be suitable for other micros as well, but I haven't done this so someone else can add information. ALSO, it is not intended for ONE interface for all solutions. Each function will dictate what interface is required.
Protocol: Somebody may suggest a protocol suitable for a given application.
Target: There is no reason not to include atTiny or anything else. (the X was to designate an incomplete list, I can update the list as we fill in specifics). Consider all micros as potential candidates, the list can contain targets that have been successfully interfaced.
To examine a specific example: VGA display services
The prop demo board is a typical hardware configuration that can generate video to a computer display. There are well established objects in the OBEX that provide many diplay options.
We now establish -
High level funtion - VGA display services
General hardware baseline - demoboard configuration (modified/moved pinout will be a secondary consideration for the time being)
Output function set 1 - VGA Text on the monitor attached to the prop
Input - bit stream of ascii bytes to contain the text (and any other needed data) to be displayed.
Further definition of high level inputs - in addition to the text to be displayed, a user will likely want tho control position, color, text size etc. A standard method of doing so is to use ANSI control codes.
Further definition of Outputs - of the various VGA mode the propis capable of supoorting, we intendt to support (this part is to be filled in by the developer, but I provide examples)
- 80x67 lines of text 7 color (black and white)
- 40x37 lines of text 67 color
- etc
Output function set 2 - VGA grahics on the monitor attached to the prop
- etc
The process is that we define the function from the highest level down based on what we know about what we know about the lowest level implementation details and work our way back up. When the top down design meets the bottom up design, we decide if we have something we can code. If not, (if its incomplete or incorrect) we do it over, otherwise we can start to code.
In this example, we have to correct the errors in the high level statement of functions first.
Thanks tonyp12. This fits well with my discussion of proposed development process.
Changing video mode is a function under consideration, to be provided based on the end users use-case (will they want to do this function in the wild?).
"Write to memory location 0" is an implementation detail transparent to the user, and left to the developer. We want to avoid deciding implementation detail in advance of the developers effort. (but since tonyp12 has started this one, he may trun out to be the developer and it will be his choice).
This particular post is an example of lower level, engineering requirements. These should not be finalized until the high level requirements of function, inputs, outputs, and usecase senarios have been established for a given function. Which is not to say that this work cannot be done at this time; to the contrary, this research is required at this time, but should not be considered "final".
The last aspect to be considered before coding is that test cases. How will the functions be tested to ensure they were implemented properly?
The general case is obviously to connect the VGA monitor to the prop and the prop to the micro, and visually verify that the proper characters are displayed. Other cases include test to verify the implemented video modes are displayed properly, and the ANSI control codes (if implemented) behave as defined. The goal of this step is to ensure the developer knows exactly what must be done to complete the task, so it is agreed in advance when work is complete.
Now is a good time to start responding with comments on the proposed development process. This might seem a little nutty to some, but have been demonstrate useful in situation where many developers are working on a common complex task without the benefit of daily personal (face to face) interaction.
It also seems like it would be nice to provide a small card with a surface-mounted prop, crystal and EEPROM. This card would be something like 1"x1" in size, or even smaller. It could have something like 16 I/O pins on a dual-row connector on one side.
Something else I've considered is a Propeller USB "Thumb" which would fit in a tiny 1" x 2" USB enclosure.
I'm not sure if a USB thumb is of any interest or not, but it could offer female connectors with a DIP32 footprint.
I was think more along the lines of simple text on the screen, at least initially; but of course you are welcome to pursue this. I was unaware that GEM VDI has been implemented on the prop.
I am limited to software process, my feeling is that binaries would be reasonable endpoint for the software aspect.
Parallax or other manufacturer would have to deal with packaging the binaries in EEPROM on a propboard; there are several hardware producer on these forums that may be interested is success is demonstrated.
You, the developer, are free to specify any hardware configuration that you feel is suitable for the function you are providing. I chose the demoboard as an example as I have on on my bench and it works well for the VGA experiements. Personally, I defer all harware decisions to anyone who can solder better than me.
There you have hit an immediate problem " the functionality in an EEPROM able image", is very low, if you cannot re-map pins, and link with your own source code.
So the reality is a physical EEPROM, delivers less than we can get now from the internet.
Libraries, and 'canned examples' are a good idea, but asking about a set of bits in a chip, is asking the wrong question.
We could have a webservice for clicking together what the user needs in the EEPROM and let him define the pins... no magick is needed to get there... just sweat... then a cheap I2C-loader would be all he needs at home.
Interfacing to or including custom code or data at runtime could be done by testing the presence of a magic pattern at well defined addresses in the upper half of a 64k EEPROM or in subsequent EEPROMs on other I2C chip addresses but let this be open for version 2.0 of this idea...
I don't understand the issue. Lets look a simple example, VGA video. I'm choosing this since the prop is good at it and the code is well established. The strategy I am forming is something like this:
Output hardware: Demoboard VGA pinout, external monitor connected to VGA header
Output to user (primary): Text on a monitor
Input Hardware: One prop I/O pin
Input from user: Stream of bytes from target micro
Elaboration of inputs: Two classes of input stream 1) Data bytes (text) 2) control codes
Data - displayable ASCII character set
Control - ANSI control codes (easy because I've done it before, the monitors seem to respond)
Elaboration of output - explore possibility of return responses to target micro about successful function completion, current display status, etc, as needed by user (i.e. I have to ask what they want - I've already send a PM to the initial requester, HollyMinkowski)
So far, the whole deal seems technically feasible, and fits the original request as far as I know. The result is the target micro sends characters and formatting out an I/O line, and the prop displays it on the screen. The user has not need of modifying the prop EEPROM, although that is of course always an option.
Does this strategy seem reasonable, or do you see any obvious flaws I need to address?
This is getting fun!
Such a webservice is a fairly elaborate effort to build, compared to my skill and time resources. At such a time when I already have a webservice capability (not time after August at the earliest) this idea can be re-visited. Until then, anybody so inclined is welcome, but for me a webservice configuration tool is outside current scope of "EEPROM image for black box functionality".
"presence of a magic pattern" - The name of the game is to ensure "timely communication from those that have the information to those that need the information". This concept would need further elaboration before it could be established as a functional requirement. This concept could be revisited when the appropriate building blocks are in place. I am trying to limit "function creep".