Chip
BTW is the comparator working in the analog of digital domain. I mean is it a analog comparator for which one input is the pin and the other a variable voltage reference or is a digital comparator thar compares the adc output with a latch/register?
On the P2 it's an analog comparator that compares the voltage at the pin with the output of the level DAC.
There is no ADC value available inside the pin circuit, the ADC mode is only a Sigma-Delata modulator that generates a bitstream. On the P2 you need a cog-counter to translate the bitstream into a value. On the P1+ one of the smart modes may do this, and then a digital comparsion would also be possible.
One thing that immediately stood out for me with the Prop1 counters was that mode setting wasn't done as a bit per gate config basis but rather as hard encoded groupings of common mode settings, ie: The 5 bits of CTRMODE are spread across maybe 7 or 8 or more actual control bits.
I'd prefer such mode set groupings to be soft encodings instead.
Every man and their dog claim to be able to do Smart IO... might be too Generic and anonymous.
'Smart Pins' would be more descriptive
A quick google nets me no-one appears to use "smart pins" in the related fields of ICs or computing.
There is some garden planter system, there is lapel pins, there is some needlework thing I think, there is a yachting pin thingy, there is some archery thing and there is even some medical dosing device.
I would like to have a Pos Edge CTR mode that allows you to input a value for the counter to count up to, fire a pin high, reset the counter, take the pin low. There are cases where in PASM the time for code to do this takes too long.
So, is the high pin pulse just one clock?
It's covered by the PWM feature. It's a count down rather than count up but the definable pulse length within a repeating definable period is what Mr Chap is asking for I believe.
Excellent idea!!! This would simplify things quite a bit, speed things up, and make things deterministic again. It would, though, disallow phenomena that wasn't some multiple of 32 clocks, though - that needs some considering.
That shouldn't be an issue given the overall slow'ish nature of the messaging in general. It's fine for config.
The question really goes to what happens to access to the currently fast access of the actively changing data in dac/adc/ctr/ser? Do they all fall onto this messaging bus too?
Addit2: Adding a CY out on the Adder for other NCO modes, bobbles the data again, and it now has 98 Slices, ( 193 LUT4) and ~246MHz with CY added
Went from
ripple logic: 17 (34 LUT4s) to ripple logic: 34 (68 LUT4s)
so looks like the tools duplicated some paths, maybe to meet timing (set to 220MHz )
Because the above bumped the ripple logic count, I tried another partition, this time with a single adder, and a choice of
[SetV,+1,-1] in a 3 way MUX (non registered).
With a 220MHz target, fP&R reaches 231.803MHz, and Total LUT4 drops from 193 to 174, and ripple count drops from 34 to 17
Slices increased to 107 from 98, but I think the LUT4 total is a better indicator of total Logic needed.
The sophistication comes in the form of flexible, reusable, cores with just enough smarts in the pins to support the implementation of a wide variety of protocols (potentially even ones that have not been created yet). Contrast that to other MCUs that provide full hardware support for SDRAM, but can only ever use that part of the hardware for SDRAM (or, at best, other forms of RAM). The rest of the time, that hardware is useless. Now, extend this conversation to SPI, I2C, UART, USB, CAN, etc, and you realize that the traditional MCU approach of implementing everything in hardware is rather brutish (i.e. shove it all in, whether you need it or not).
Obviously, this sort of thing is a great balancing act, where software and hardware are at opposite ends. The current smart pin conversations are, from my perspective, an attempt to find that balance. If we can get the balance right, I think we'll end up with a very sophisticated chip.
... Contrast that to other MCUs that provide full hardware support for SDRAM, but can only ever use that part of the hardware for SDRAM (or, at best, other forms of RAM). The rest of the time, that hardware is useless. ...
This is a typical propeller-fan point of view. You will always have hardware in a chip that is not used. But I it is useless to discuss this in this forum.
And use this arrays in code like an array in Hubram. If this is not possible, than SDRAM is not an option for me with this chip, because I can not use "standard" software modules from others (e.g. http://www.easygui.com).
This is a typical propeller-fan point of view. You will always have hardware in a chip that is not used. But I it is useless to discuss this in this forum.
What I want is something like this:
And use this arrays in code like an array in Hubram. If this is not possible, than SDRAM is not an option for me with this chip, because I can not use "standard" software modules from others (e.g. http://www.easygui.com).
as those functions could hide the implementation details.
You can always do these things in your own code. But if the code, you want to use, needs direct access to these buffers, I mean buffer[x] = value, than the compiler has to solve this. I mean, maybe the gcc team can make this happen without hardware support.
This is a typical propeller-fan point of view. You will always have hardware in a chip that is not used. But I it is useless to discuss this in this forum.
What I want is something like this:
And use this arrays in code like an array in Hubram. If this is not possible, than SDRAM is not an option for me with this chip, because I can not use "standard" software modules from others (e.g. http://www.easygui.com).
You are talking about interacting with SDRAM at an abstraction level that's well above the pin operation modes, which is all I was discussing. I'm not aware of any MCU that accomplishes what you want without software.
What I want is something like this:
And use this arrays in code like an array in Hubram. If this is not possible, than SDRAM is not an option for me with this chip, because I can not use "standard" software modules from others (e.g. http://www.easygui.com).
SDRAM is not random-access, it is best used in burst modes, and in Video cases, you will want read to have priority over write.
That means write would usually be queued and done in the non-display time windows.
At the HW level, it needs a CLK and a CS# that pulses to qualify the clock.
Other signals can then be slower, from SW banging the pins.
The SDRAM data shows typically minimum of 5 clocks and 3 CS# activates before the first data appears.
After the first data,each CS#+CLK can R/W more data - packed, if the SW can keep up.
Read is simpler if the Full page on SDRAM can include a whole scan line, but 512 is a common Page size.
You are talking about interacting with SDRAM at an abstraction level that's well above the pin operation modes, which is all I was discussing. I'm not aware of any MCU that accomplishes what you want without software.
At the risk of getting slammed for throwing this out from the peanut gallery, another mode of smart pins could be a precision current source.
Brand X has the feature they call CTMU (Charge Time Measurement Unit) which allows precision measurements of voltages and time measurements down to nanoseconds ... without using a clock.
At the risk of getting slammed for throwing this out from the peanut gallery, another mode of smart pins could be a precision current source.
I think the P2 pin blocks used here do include current output modes, but not sure if any 'precision' or trim range is defined yet.
The blocks do have a Fast comparator, and an ADC.
To match the CTMU a couple of async gated options would be needed for .
* Current mode Current-pF oscillator (frequency measure should be possible)
* Window gated Current injector, and ADC trigger. (for narrow time window ramp-measurement)
EasyGui seem to offer to write you a FREE DRIVER for your microcontroller as offered on the Front Page of their web.
Everything else seems to be not so free at all
easyGUI products
All our easyGUI packages come with a complimentary 3 month Support plan and an easyGUI Dongle license. Choose between Monochrome, Color or Unicode. The packages are sold as a Download, this means that you will have your software within a few days of ordering it. Read more.
EasyGui seem to offer to write you a FREE DRIVER for your microcontroller as offered on the Front Page of their web.
Everything else seems to be not so free at all
....
WOW
WITH DONGLE!
AND LICENSE FEES ALSO!
WOW
Why, exactly does Parallax need to change their FREE development tools for you to use this again?
Confused again
Mike
I know these all. I work with this software for three years now. Where do you read something about licence fees ? The software and library costs money, yes. Work normaly costs money. The time I would need to program these all would cost more. They use a dongle to protect there software, not a bad idea. So I can use this software on different computers.
The driver only copies the data from displaybuffer to the displaycontroller. To have room for code the displaybuffer would be in SDRAM. And there library needs direct access to the display buffer. So they would have to change the whole library.
Parallax can do what they want. And then I respectively we have to decide if there product is good for our project(s) or not. Prop1 with 32 kBytes was to small for nearly everything (with C). Spin was and is not an option.
This new chip looks very interesting. With a SDRAM controller with address mapping this chip could be a replacement for many things. With more than 64 Pins it would be unrivaled.
Seems that one has a fair amount of RAM 256Kb, and 2MB flash to run code out of. A P2 will have 512Kb RAM, and if we want, a very large SDRAM to run code out of.
Seems that one has a fair amount of RAM 256Kb, and 2MB flash to run code out of. A P2 will have 512Kb RAM, and if we want, a very large SDRAM to run code out of.
Now it's getting totally of topic.
The library codesize depends on the functions/options you use in your project. And the tool can make a separate binary file of all the screendata (tables, bitmaps, fonts), so you can pull them in from external memory (SD-Card, Flash....) on demand (via callback function).
In my case this would mean ca. 500 kbytes total code (I estimate less than half of this is for the library code) and ca. 1Mbyte external data + Displaybuffer(s) in SDRAM.
Not really off topic. Just wondering how big things were, and how one might arrange things. The dual 640x480x8bpp buffer would be an upgrade from what you must be running now.
One could run code in HUB, and fully buffer a display in SDRAM, or for smaller displays, have that happen in the HUB, pulling code from the SDRAM, or other device as JMG pointed out, perhaps with high speed routines in the HUB also. Additionally, with a fast display like is possible in the HUB, a partial off screen buffer could be used to draw flicker free. A full buffer isn't generally needed.
Not really useless. Seems there are some choices there. Thanks for the size reference.
...The dual 640x480x8bpp buffer would be an upgrade from what you must be running now.
... Additionally, with a fast display like is possible in the HUB, a partial off screen buffer could be used to draw flicker free. A full buffer isn't generally needed.
For this library you need at least one full buffer in internal RAM or some "mapable" external SDRAM, like we do now in the RX, because the drawing functions of the library do manipulate the buffer direct with "buffer[x][y] =".
But the buffer with code will not fit into the 512kB. So the prop will not fit for this project, unless there will come some support to map external ram somehow into internal address space (via compiler and/or built in SDRAM controller).
Now we have one buffer in SDRAM. After the library is finished with drawing, the whole screen is copied to the display controller, which has also room for one screen.
With the prop you could get rid of the displaycontroller.
There's no hardware "mappable" SDRAM and it's simply not going to be in this or any near-future Propeller. On the other hand, there may be some instructions or other features that will make it easier to do this sort of thing in software. There's already cache software for the existing Propeller 1 which makes it possible to run largeish programs in the limited 32K HUB RAM using C.
Keep in mind that the Propeller, whether the current or future versions, is not meant to be all things for all people and projects. Its main "claim to fame" is the multiple processors with uniform I/O pin features, deterministic code, straightforward design, and the ability to easily cut power consumption way down when not busy. The new version looks like it will have more processors, more speed, more memory, more I/O, and some additional functionality. It won't have quite the same low power consumption, but that's one reason why the Propeller 1 will remain in use for a long time. Maybe the proposed Propeller won't be a good fit for your project. Maybe it would be a fair fit, but something else would be easier to use for the project. If the need to get rid of the display controller is strong enough, you'll find a way to make the buffer processing work despite the lack of automatic mapping of external SDRAM into the internal RAM. That's the way these things work out.
I wonder if direct USB interfacing will be possible with the new P2 (AKA P1+)...
Anybody think so?
There was discussion of USB 'helpers' on P2, and the new pin cells are going to be configurable.
Some pin-logic and the new JP, JNP may be enough to extract SE0 and Differential Data, and Balanced pin drive I think is also intended
So all the pieces look to be there for some level of USB. 1.5MHz would be easier than 12MHz
Bit-destuff and Edge Auto-sync are possible with a small verilog block, (which shifts SW from bit to byte level) but that will depend on how large the PinCell Counters and config are. Time will tell.
Comments
I figured you would do this
Just want to say +1000 for this. Especially if the gating source may be also from effects from adjacent timers...?
On the P2 it's an analog comparator that compares the voltage at the pin with the output of the level DAC.
There is no ADC value available inside the pin circuit, the ADC mode is only a Sigma-Delata modulator that generates a bitstream. On the P2 you need a cog-counter to translate the bitstream into a value. On the P1+ one of the smart modes may do this, and then a digital comparsion would also be possible.
Andy
I'd prefer such mode set groupings to be soft encodings instead.
A quick google nets me no-one appears to use "smart pins" in the related fields of ICs or computing.
There is some garden planter system, there is lapel pins, there is some needlework thing I think, there is a yachting pin thingy, there is some archery thing and there is even some medical dosing device.
It's covered by the PWM feature. It's a count down rather than count up but the definable pulse length within a repeating definable period is what Mr Chap is asking for I believe.
That shouldn't be an issue given the overall slow'ish nature of the messaging in general. It's fine for config.
The question really goes to what happens to access to the currently fast access of the actively changing data in dac/adc/ctr/ser? Do they all fall onto this messaging bus too?
Hm, I thought it would be more sophisticated. More like a memory-bus like in other mcus.
But this whole "smart io" thing goes over my horizont.
Because the above bumped the ripple logic count, I tried another partition, this time with a single adder, and a choice of
[SetV,+1,-1] in a 3 way MUX (non registered).
With a 220MHz target, fP&R reaches 231.803MHz, and Total LUT4 drops from 193 to 174, and ripple count drops from 34 to 17
Slices increased to 107 from 98, but I think the LUT4 total is a better indicator of total Logic needed.
The sophistication comes in the form of flexible, reusable, cores with just enough smarts in the pins to support the implementation of a wide variety of protocols (potentially even ones that have not been created yet). Contrast that to other MCUs that provide full hardware support for SDRAM, but can only ever use that part of the hardware for SDRAM (or, at best, other forms of RAM). The rest of the time, that hardware is useless. Now, extend this conversation to SPI, I2C, UART, USB, CAN, etc, and you realize that the traditional MCU approach of implementing everything in hardware is rather brutish (i.e. shove it all in, whether you need it or not).
Obviously, this sort of thing is a great balancing act, where software and hardware are at opposite ends. The current smart pin conversations are, from my perspective, an attempt to find that balance. If we can get the balance right, I think we'll end up with a very sophisticated chip.
This is a typical propeller-fan point of view. You will always have hardware in a chip that is not used. But I it is useless to discuss this in this forum.
What I want is something like this:
And use this arrays in code like an array in Hubram. If this is not possible, than SDRAM is not an option for me with this chip, because I can not use "standard" software modules from others (e.g. http://www.easygui.com).
What you could have in the current chip is:
setPixel(buffer,x,y)
getPixel(buffer,x,y)
as those functions could hide the implementation details.
You can always do these things in your own code. But if the code, you want to use, needs direct access to these buffers, I mean buffer[x] = value, than the compiler has to solve this. I mean, maybe the gcc team can make this happen without hardware support.
You are talking about interacting with SDRAM at an abstraction level that's well above the pin operation modes, which is all I was discussing. I'm not aware of any MCU that accomplishes what you want without software.
SDRAM is not random-access, it is best used in burst modes, and in Video cases, you will want read to have priority over write.
That means write would usually be queued and done in the non-display time windows.
At the HW level, it needs a CLK and a CS# that pulses to qualify the clock.
Other signals can then be slower, from SW banging the pins.
The SDRAM data shows typically minimum of 5 clocks and 3 CS# activates before the first data appears.
After the first data,each CS#+CLK can R/W more data - packed, if the SW can keep up.
Read is simpler if the Full page on SDRAM can include a whole scan line, but 512 is a common Page size.
Pins alone maybe. Pins + some "hubhardware" (like the cordic or multiply) sure. How easy, I don't know.
http://documentation.renesas.com/doc/products/mpumcu/doc/rx_family/r01uh0033ej0130_rx62n.pdf on page 130/131 you see how it is on the Renesas RX.
There I can do exactly what I described.
Brand X has the feature they call CTMU (Charge Time Measurement Unit) which allows precision measurements of voltages and time measurements down to nanoseconds ... without using a clock.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en553967
I think the P2 pin blocks used here do include current output modes, but not sure if any 'precision' or trim range is defined yet.
The blocks do have a Fast comparator, and an ADC.
To match the CTMU a couple of async gated options would be needed for .
* Current mode Current-pF oscillator (frequency measure should be possible)
* Window gated Current injector, and ADC trigger. (for narrow time window ramp-measurement)
EasyGui seem to offer to write you a FREE DRIVER for your microcontroller as offered on the Front Page of their web.
Everything else seems to be not so free at all
easyGUI products
All our easyGUI packages come with a complimentary 3 month Support plan and an easyGUI Dongle license. Choose between Monochrome, Color or Unicode. The packages are sold as a Download, this means that you will have your software within a few days of ordering it. Read more.
easyGUI Monochrome version 6 with a 3 months complimentary easyGUI support plan, and a Dongle license.
EG-3M
€ 929.00
easyGUI Color version 6 with a 3 months complimentary easyGUI support plan, and a Dongle license.
EGC-3M
€ 1439.00
easyGUI Unicode version 6 with a 3 months complimentary easyGUI support plan, and a Dongle icense.
WOW
WITH DONGLE!
AND LICENSE FEES ALSO!
WOW
Why, exactly does Parallax need to change their FREE development tools for you to use this again?
Confused again
Mike
EGU-3M
€ 1919.00
I know these all. I work with this software for three years now. Where do you read something about licence fees ? The software and library costs money, yes. Work normaly costs money. The time I would need to program these all would cost more. They use a dongle to protect there software, not a bad idea. So I can use this software on different computers.
The driver only copies the data from displaybuffer to the displaycontroller. To have room for code the displaybuffer would be in SDRAM. And there library needs direct access to the display buffer. So they would have to change the whole library.
Parallax can do what they want. And then I respectively we have to decide if there product is good for our project(s) or not. Prop1 with 32 kBytes was to small for nearly everything (with C). Spin was and is not an option.
This new chip looks very interesting. With a SDRAM controller with address mapping this chip could be a replacement for many things. With more than 64 Pins it would be unrivaled.
Seems that one has a fair amount of RAM 256Kb, and 2MB flash to run code out of. A P2 will have 512Kb RAM, and if we want, a very large SDRAM to run code out of.
- or QuadSPI flash, ( in x4 or 2x4) for Execute in Place code.
Now it's getting totally of topic.
The library codesize depends on the functions/options you use in your project. And the tool can make a separate binary file of all the screendata (tables, bitmaps, fonts), so you can pull them in from external memory (SD-Card, Flash....) on demand (via callback function).
In my case this would mean ca. 500 kbytes total code (I estimate less than half of this is for the library code) and ca. 1Mbyte external data + Displaybuffer(s) in SDRAM.
We now use a chip with 128kB RAM and 2MB Flash.
Not really off topic. Just wondering how big things were, and how one might arrange things. The dual 640x480x8bpp buffer would be an upgrade from what you must be running now.
One could run code in HUB, and fully buffer a display in SDRAM, or for smaller displays, have that happen in the HUB, pulling code from the SDRAM, or other device as JMG pointed out, perhaps with high speed routines in the HUB also. Additionally, with a fast display like is possible in the HUB, a partial off screen buffer could be used to draw flicker free. A full buffer isn't generally needed.
Not really useless. Seems there are some choices there. Thanks for the size reference.
For this library you need at least one full buffer in internal RAM or some "mapable" external SDRAM, like we do now in the RX, because the drawing functions of the library do manipulate the buffer direct with "buffer[x][y] =".
But the buffer with code will not fit into the 512kB. So the prop will not fit for this project, unless there will come some support to map external ram somehow into internal address space (via compiler and/or built in SDRAM controller).
Now we have one buffer in SDRAM. After the library is finished with drawing, the whole screen is copied to the display controller, which has also room for one screen.
With the prop you could get rid of the displaycontroller.
Keep in mind that the Propeller, whether the current or future versions, is not meant to be all things for all people and projects. Its main "claim to fame" is the multiple processors with uniform I/O pin features, deterministic code, straightforward design, and the ability to easily cut power consumption way down when not busy. The new version looks like it will have more processors, more speed, more memory, more I/O, and some additional functionality. It won't have quite the same low power consumption, but that's one reason why the Propeller 1 will remain in use for a long time. Maybe the proposed Propeller won't be a good fit for your project. Maybe it would be a fair fit, but something else would be easier to use for the project. If the need to get rid of the display controller is strong enough, you'll find a way to make the buffer processing work despite the lack of automatic mapping of external SDRAM into the internal RAM. That's the way these things work out.
Anybody think so?
There was discussion of USB 'helpers' on P2, and the new pin cells are going to be configurable.
Some pin-logic and the new JP, JNP may be enough to extract SE0 and Differential Data, and Balanced pin drive I think is also intended
So all the pieces look to be there for some level of USB. 1.5MHz would be easier than 12MHz
Bit-destuff and Edge Auto-sync are possible with a small verilog block, (which shifts SW from bit to byte level) but that will depend on how large the PinCell Counters and config are. Time will tell.
http://laughtonelectronics.com/Arcana/One-bit%20computer/One-bit%20computer.html
The article points to an older industrial control unit from Motorola (MC14500) which I'd never heard of before.
-joe