"Signal description language"? Is there such a beast?
Nick Mueller
Posts: 815
Hi!
This is just one of my brain-farts, nothing real ...
For too long a time, I want some pattern generator for testing/debugging hardware. Something like this exists, but they do only have one output and analog waveforms. What I'd like to have is a digital pattern generator with several output (8 .. 16) and maybe even inputs that can influence the outputs.
The speed of the Prop would be suitable for what I need, the COGs could work in parallel etc.
Now one part in the puzzle missing is some kind of language that describes one or more signals. Think of some language that does a better abstract on the signals like pwm(baseFreq, ratio), pulse(higTime, LowTime) and so on and so on.
This language should then be translated to PASM and be executed. If the language isn't too complex, it might even be compiled on the Prop.
Does such a language exist? Some kind of VHDL, just for signals?
I googled, but couldn't find anything matching.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
This is just one of my brain-farts, nothing real ...
For too long a time, I want some pattern generator for testing/debugging hardware. Something like this exists, but they do only have one output and analog waveforms. What I'd like to have is a digital pattern generator with several output (8 .. 16) and maybe even inputs that can influence the outputs.
The speed of the Prop would be suitable for what I need, the COGs could work in parallel etc.
Now one part in the puzzle missing is some kind of language that describes one or more signals. Think of some language that does a better abstract on the signals like pwm(baseFreq, ratio), pulse(higTime, LowTime) and so on and so on.
This language should then be translated to PASM and be executed. If the language isn't too complex, it might even be compiled on the Prop.
Does such a language exist? Some kind of VHDL, just for signals?
I googled, but couldn't find anything matching.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Comments
"Pattern Scripts can be loaded or saved by right clicking over the grid and selecting the relevant option from the popup menu. This is particularly useful if you want to use a particular pattern in several designs.
The pattern scripts are plain text and are simply a comma-separated list of bytes where each byte value represents a column on the grid. Any line beginning with a semi-colon is taken to be a comment line and is ignored by the parser. By default the byte format is hexadecimal though if you are creating your own script you can enter values is decimal, binary or hexadecimal.· "
I've often thought a simple state/count pair would work.· As all the channels probably share a common timebase, you'd just divide that base by the number of divisions you need and enter H:100, L:50, H:25·(high 100 divisions, low 50 divisions, high 25 divisons).
This is certainly the most simple thing and easy to understand. At least a good starting point!
Might cover 80% of the problems.
What I have in my mind (but verrrry unclear) is something more procedural. Where you can have building blocks or counters to generate dynamic patterns.
Dynamic! That's the keyword I missed in my initial posting!
A language that might be able to -for example- describe an RS232-signal just with its own keywords. Nothing that has a built-in and hardcoded rs232, I2C but that is capable of doing such things (and that in parallel).
The rationale behind that idea is to ease software development and debugging. If you do have stable patterns with a stable timing, it would ease development a lot in some cases. Later during development, you can make the signals more unstable, introduce jitter etc. and add one component out of the real-world-signal after the other and still have everything under control.
Nick
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I'm no expert, but it seems you may be entering the world of spice there.
It looks like you have a good idea of what you want to implement... my suggestions is to make up your own code.· Things like rs232 and i2c often have defined headers or tails that could easily be attached to the data you pass.· You might include a JITTER: or RND: command that offsets the timing or skips occasional bits.
I guess what I'm thinking is that even if you were to find a documented scripting format, you'd still end up coding the implemenation yourself, so perhaps you can simply try to define all the elements you want and go from there.
Certainly right!
But then, it helps to have at least a look ar what others did and to see something that is proven to work.
I don't completely have to reinvent the wheel.
Such a language might look completely different from what we mortals know...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
http://www.movingpixel.com/main.pl?PG3AUsersManual.pdf
regards peter
····(01)+
A stream of asynchronous serial data with eight data bits and two stop bits would be expressed:
····(0[noparse][[/noparse]01]{8}11)+
Although regular expressions are normally used for matching strings, they can also be used to generate random strings.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 8/11/2009 7:00:10 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Uh!? I know RegEx, but absolutely not in that context.
Where's that idea from? As for now, this looks so "reverse" to me that I can't grap it. DI you have pointers for me to read more about?
@Steve:
BF? WTF? BNF?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
A regular expression is just a shorthand description of a finite state machine. Any sequence that an FSM can generate can be expressed as a RegEx. Google regex fsm for more info.
-Phil
Try Hanno's ViewPort object as a starting point for a UML modelling sandbox to test your ideas.
Test out various ideas with the sandbox.
Extract the object from the sandbox environment, leaving little, if no dependencies on Hanno's code. a
I have used this method for 25 years to develop driver code for many computers.
Hanno's code is used here as merely a convenient way of concentrating on the object creation.
Use whatever feels comfortable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Thanks. And the first hit started like this:
"Once you understand how easy it is to set up a state machine, you’ll never try to use a regular expression inappropriately ever again."
And I have to admit, I'm "not really fluent" with regex.
But the FSM-route looks promissing.
... after some reading ...
OUTCH! I once designed and implemented a language that was for importing and converting data. I started writing a hardcoded FSM but threw it away after two days when I realized that it will take me months to implement it completely. So I designed that language (which looked like RegEx), implemented it and it took me months to finish. But it was *much* more fun! And easier to maintain.
I no longer have that source, it was contract work. :-(
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
To be honest, it's not that good - if you were trying to set up a long sequence of transmissions or model another digital device you'll find it pretty crude, but trying to use it would probably allow you to see the shortcomings and inspire you to do something more complete.
The ultimate digital i/o programmer is probably the Time Processing Unit (TPU) in certain motorola/freescale devices. This is a device that has prebuilt code to perform common timer tasks but can also have custom microcode to generate uarts etc. It's a lot harder to program than a propeller, but probably more flexible as it's usually associated with a DMA engine and a high-end processor like a CPU32 or PowerPC.