RJSM, Very nice website. You were looking for it to be educational. I did get an education on what some of these scientific instruments do.
Propeller on, Great work!
Hi Richard, last we heard from you, you were on the Amalfi coast, and I figured you'd opted to forsake Oz and instrumentation and settle for la dolce vita!
I poked around on your site and see a lot of interesting stuff--You've been playing with interesting hardware and front ends for the Propeller! I was struck by those little piezoelectric pumps you are proposing to use for the fluidic sampler.
Hi Richard
As a chemist with a fascination for instrumentation, I agree : the Propeller works very well in lab systems. I have built a chopper-multichannel scaler system with a prop, and it works very well as a molecular beam time-of-flight system in my research lab.
As the Chair of my department, I see a poorly explored avenue for instruments : small systems with different sensors that can be deployed in large numbers for undergraduate teaching labs. We have 2500 first year chemistry students (6 rooms with 24 students, morning/afternoon/evening labs, 5 days a week). Equipping the labs with ~100 experimental systems is a challenge, financially and reliability-wise. I wonder if a flexible prop-based system could be developed that would allow different sensors to be used to study thermochem, spectroscopy, titrations, etc. Perhaps a RPi as the head unit?
Cheers!
Something I have been contemplating for some time is to add the essential features of LabVIEW to my Virtual Breadboard product line.
This could be a cost effective way of using the sensors without the cost of LabVIEW licenses.
I was looking at the sensors and noticed they re-use the propeller and USB 'block' with just different sensors inputs.
With my propeller based 'Infinity Shield' ( see forum post ) alreading containing USB and a propeller and also the protocols to work within VirtualBreadboard I see interesting potential for making sensor interface shields that use the 'Infinity Shield' as a base (instead of a shield).
Since the Infinity Shield contains the propeller and VBB contains the just-in-time deployment I can wrap existing instrument PASM libraries as objects in the VBB ecosystem to deploy different sensors dynamically.
This means you can develop sensors as new shield interfaces and use VBB in place of LabVIEW to create a very flexible low cost solution.
With the right education partners this could really become 'a thing'.
With my propeller based 'Infinity Shield' alreading containing USB and a propeller and also the protocols to work within VirtualBreadboard I see interesting potential for making sensor interface shields that use the 'Infinity Shield' as a base (instead of a shield).
I was looking at the sensors and noticed they re-use the propeller and USB 'block' with just different sensors inputs.
Another useful logging scheme, would be to write to a .RAW file, that LTSpice ( & others) can read.
(Prop -> USB -> ASCII File)
This is fairly simple, the only limitation is the header sets the number of points, so it is not an open-ended file.
You could of course write a .rawo as raw-open, and then scan later to count the actual whole points, and patch the header line with that count. (and trim any partial records).
This then allows easy visual Zoom and measure of a group of data points.
Thanks for the encouraging comments everyone – I’m giving my website a rest for the moment (to my wife’s great relief !) but will make some mods/additions down the track.
Some responses to the recent posts by forum members :
---
JMG
Its about 9 months since I last played seriously with HyperRAM. I remember spending ages with the XMOS simulator to implement fast and appropriately timed DDR reads/writes - but I persevered, figuring the effort would be worthwhile considering the cost effectiveness of this little chip.
Here’s a few (hopefully helpful) recollections from my HyperRAM experience.
The HR datasheet is definitely not easy to follow, particularly on the issue of fixed vs variable latency.
What is clear is that one needs to set up an initial latency in clock periods – this is done in Config. Register 0 (CR0). This can be 3-6 clock periods depending on the intended frequency of operation - but I chose 3 clock periods given the rather modest I/O speeds possible with the XMOS Startkit. The datasheet clearly states that 6 periods would be required at Fmax of 166 MHz.
The HR datasheet indicates that the initial latency period may need to be extended by additional clock cycles depending on “distributed refresh requirements”. The RWDS line is used by the memory to indicate this need, but here, rather than polling this pin I elected to set bit CR0[3] to force two initial latency periods. That provides deterministic behavior without needing to worry about RWDS and simplifies the user’s code.
One would assume that in my case I’d then need to provide a total of 2x3=6 additional clocks prior to commencing read/write operations - but consulting the timing diagrams on p. 45, Fig. 11.4 (read) and write p. 48, Fig. 11.6 one sees there are actually 7 clocks after the Command-Address period on DQ[7:0] prior to the actual commencement of reads/writes.
Point 6 in the notes for this particular example (Fig. 11.4) states that the initial latency here is actually 4 clock periods, but the point from which the “Latency Count” is measured you’ll see is actually taken one clock back from the end of the Command Address (CA) period - so there’s only 2x4 - 1 = 7 clocks visible after CA.
On realizing this I figured in my case I’d need to generate 2x3-1 = 5 clocks after CA before starting my reads/writes and this seemed to work out. Finally - happy days ! You will see those additional 5 clocks in my timing diagrams.
During a write transaction the host also needs to swap RWDS from an input to an output and drive that pin to control the mode by which data gets loaded into HR (there’s a little info about this under notes 3/4 in Fig 11.6, and also see the comments about data masking at the top of p. 38). RWDS needs to be restored to an input pin after the write operation.
I hold the CS line high all the time apart from in my primitives that write to CR0/CR1 and that do the HR read buffer/write buffer operations. The CLK signal is also only active during those periods.
I can write large numbers of 32/64/128 byte buffers of data via a loop rapidly into HR, wait for an “indefinite” period and then successfully read the data back again so the self-refreshing appears to be ok.
Once I got myself to this point I didn’t do any further experimenting with my HR interface as I just wanted to get on and use it in several larger projects. I described a couple of those on the website.
I confirmed that the XMOS Startkit has no problem moving 64 byte chunks into/out of HR inside a 4 usec window. That speed is perfectly adequate for me but the chip is capable of much faster operation. Certainly would be nice but non trivial…. An FPGA solution seems to beckon.
To date I haven’t attempted to do anything with HR for P1, figuring it wouldn’t likely be as fast as the Startkit. That said, I’d be really interested to see HR connected to a P2 emulation, but that will require someone far more savvy than me knowing how to use the streamer and smart pins in conjunction with one another to do so. I think that would make a great project and could serve as a really nice illustrative example of how those P2 features could be used to solve a practical problem.
Any takers ?? Ozpropdev could probably do this in his sleep..The payback is 8MB of memory for <$5 and only tying up 12 I/O lines.
That’s about all I can tell you right now but I’ll go back and “refresh !” my memory of the code again in the coming week.
Tracy Allen
While it would have been nice to indulge (la dolce vita), unfortunately it was not to be.
Yes those Balters piezo micropumps are an interesting innovation for fluidics experiments. There’s a US distributor in the Boston area. Oh and by the way, Balters have very recently released an OEM driver board that can run 4 MP6 pump channels.
Having worked a lot with peristaltic pumps I’ve been looking for something smaller, cheaper and less power hungry for field analysis work. Really just getting started out in this area, but these little devices are a perfect match to many of the small instruments I’ve described on the website.
PaulRowntree
Very interested to hear about your molecular beam TOF instrument and the chopper/multichannel scaler you developed. Yes one can do a hell of a lot with the P1 !
Also, your First Year Chem labs at the Univ. of Guelph sound just like the ones I used to work in at Monash University, here in Melbourne, Australia. The problems you mentioned are ubiquitous at universities worldwide and were really what got me started down the small instrument path – lots of students, a dearth of instruments meaning lots of very old fashioned (and boring) wet chemistry – titrations etc and small budgets, with a reluctance to let u/g’s onto research-grade instruments for fear they might get broken. Definitely thinking about a flexible system based on a Propeller….
---
VBB
I’ll definitely check out your Virtual Breadboard/Infinity Shield concept – it looks very interesting too. Did you know about LabVIEW Maker Hub ?? – a very low cost way to get into LabVIEW which might be worth checking out.
Here’s a few (hopefully helpful) recollections from my HyperRAM experience.
The HR datasheet is definitely not easy to follow, particularly on the issue of fixed vs variable latency.
...
I hold the CS line high all the time apart from in my primitives that write to CR0/CR1 and that do the HR read buffer/write buffer operations. The CLK signal is also only active during those periods.
I can write large numbers of 32/64/128 byte buffers of data via a loop rapidly into HR, wait for an “indefinite” period and then successfully read the data back again so the self-refreshing appears to be ok.
Does that indicate self-refresh can occur when CS=H, and no clock is needed at that time ?
To date I haven’t attempted to do anything with HR for P1, figuring it wouldn’t likely be as fast as the Startkit. That said, I’d be really interested to see HR connected to a P2 emulation, but that will require someone far more savvy than me knowing how to use the streamer and smart pins in conjunction with one another to do so. I think that would make a great project and could serve as a really nice illustrative example of how those P2 features could be used to solve a practical problem.
I'd agree P2 will give the highest burst speeds, but P1 should also work, and give a useful hardware proof platform.
P1 should be able to stream data at reasonable speeds, (ie just by providing a clock) and a P1+HyperRAM+LVC573 should? be able to maintain a VGA type raster, with the LVC573.oe isolating the display during HV-Blanking, & flyback writes.
If self-refresh is ok with sufficient CS=H, and if RWDS can be ignored with right config settings, P1 code should be simpler.
2 Timers could manage H-Sync and HV-Blanking, with V-Sync done in SW ?
A LVC646 could allow background hold feature, for more write bandwidth with common HMI/Text font displays.
Yes - self-refresh is happening when cs is high. No clock running - CLK line is low except during the reads/writes. I'm not familiar with the LVC573 but will investigate for interest. I agree it would be great to have HR running on a P1.
Definitely start out by setting bit 3 in CR0 as that will save hassle with RWDS
Do you have some hardware to work with - there was some discussion about this quite some time back and someone had built a PCB but I haven't kept up-to-date with that - was that you ?
I just took a look at the octal D type latch with tristate outputs you suggested - seems a good idea to try out and the LVC logic series seems pretty fast too.
Do you have some hardware to work with - there was some discussion about this quite some time back and someone had built a PCB but I haven't kept up-to-date with that - was that you ?
---
VBB
I’ll definitely check out your Virtual Breadboard/Infinity Shield concept – it looks very interesting too. Did you know about LabVIEW Maker Hub ?? – a very low cost way to get into LabVIEW which might be worth checking out.
Actually I didn't know about Maker Hub and can only find a community not a specific product. But I think you misunderstood my post because the goal is to replace LabVIEW and use VBB instead as a lower cost solution to creating instrument visualisation and I wanted to use your LabVIEW expertise to indicate the 'minimum viable product' collection of visualisation 'widgets' that I would need to implement based on your existing LabVIEW based instrumentation and experience.
The concept is to take instrumentation interfaces and put them into a shield format. Actually pretty much like this :
So instead of using the STM32 base , using the propeller powered infinity shield with VBB for Lab Visualisations and you have potentially a low cost solution for education labs.
The idea was to basically take your instrument interfaces and drivers and make shields from them in the same was as ST has done as per the above link.
Anyhow, probably I will get started with a couple of the Analog Device Shields and port some of their drivers as a first step to create an evaluation kit for the concept.
Of course access to the lab market is always the issue but that's why with this thread became interesting because of your own long educational background and also PaulRownTree's post who has direct contact with the problem as department chair.
Comments
Propeller on, Great work!
I poked around on your site and see a lot of interesting stuff--You've been playing with interesting hardware and front ends for the Propeller! I was struck by those little piezoelectric pumps you are proposing to use for the fluidic sampler.
I'm just a beginner learning by messing around,
but wowww your photos are very inspirational
As a chemist with a fascination for instrumentation, I agree : the Propeller works very well in lab systems. I have built a chopper-multichannel scaler system with a prop, and it works very well as a molecular beam time-of-flight system in my research lab.
As the Chair of my department, I see a poorly explored avenue for instruments : small systems with different sensors that can be deployed in large numbers for undergraduate teaching labs. We have 2500 first year chemistry students (6 rooms with 24 students, morning/afternoon/evening labs, 5 days a week). Equipping the labs with ~100 experimental systems is a challenge, financially and reliability-wise. I wonder if a flexible prop-based system could be developed that would allow different sensors to be used to study thermochem, spectroscopy, titrations, etc. Perhaps a RPi as the head unit?
Cheers!
This could be a cost effective way of using the sensors without the cost of LabVIEW licenses.
I was looking at the sensors and noticed they re-use the propeller and USB 'block' with just different sensors inputs.
With my propeller based 'Infinity Shield' ( see forum post ) alreading containing USB and a propeller and also the protocols to work within VirtualBreadboard I see interesting potential for making sensor interface shields that use the 'Infinity Shield' as a base (instead of a shield).
Since the Infinity Shield contains the propeller and VBB contains the just-in-time deployment I can wrap existing instrument PASM libraries as objects in the VBB ecosystem to deploy different sensors dynamically.
This means you can develop sensors as new shield interfaces and use VBB in place of LabVIEW to create a very flexible low cost solution.
With the right education partners this could really become 'a thing'.
You could also look at the FLiP Ken mentions here
http://forums.parallax.com/discussion/comment/1405093/#Comment_1405093
Another useful logging scheme, would be to write to a .RAW file, that LTSpice ( & others) can read.
(Prop -> USB -> ASCII File)
This is fairly simple, the only limitation is the header sets the number of points, so it is not an open-ended file.
You could of course write a .rawo as raw-open, and then scan later to count the actual whole points, and patch the header line with that count. (and trim any partial records).
This then allows easy visual Zoom and measure of a group of data points.
You've have been a busy .
Cheers
Brian
P.S. Must catch up again soon.
Some responses to the recent posts by forum members :
---
JMG
Its about 9 months since I last played seriously with HyperRAM. I remember spending ages with the XMOS simulator to implement fast and appropriately timed DDR reads/writes - but I persevered, figuring the effort would be worthwhile considering the cost effectiveness of this little chip.
You’d be aware that I put the timing diagrams I generated on my HyperRAM page at http://www.instruments4chem.com/page10/page53/index.html.
Here’s a few (hopefully helpful) recollections from my HyperRAM experience.
The HR datasheet is definitely not easy to follow, particularly on the issue of fixed vs variable latency.
What is clear is that one needs to set up an initial latency in clock periods – this is done in Config. Register 0 (CR0). This can be 3-6 clock periods depending on the intended frequency of operation - but I chose 3 clock periods given the rather modest I/O speeds possible with the XMOS Startkit. The datasheet clearly states that 6 periods would be required at Fmax of 166 MHz.
The HR datasheet indicates that the initial latency period may need to be extended by additional clock cycles depending on “distributed refresh requirements”. The RWDS line is used by the memory to indicate this need, but here, rather than polling this pin I elected to set bit CR0[3] to force two initial latency periods. That provides deterministic behavior without needing to worry about RWDS and simplifies the user’s code.
One would assume that in my case I’d then need to provide a total of 2x3=6 additional clocks prior to commencing read/write operations - but consulting the timing diagrams on p. 45, Fig. 11.4 (read) and write p. 48, Fig. 11.6 one sees there are actually 7 clocks after the Command-Address period on DQ[7:0] prior to the actual commencement of reads/writes.
Point 6 in the notes for this particular example (Fig. 11.4) states that the initial latency here is actually 4 clock periods, but the point from which the “Latency Count” is measured you’ll see is actually taken one clock back from the end of the Command Address (CA) period - so there’s only 2x4 - 1 = 7 clocks visible after CA.
On realizing this I figured in my case I’d need to generate 2x3-1 = 5 clocks after CA before starting my reads/writes and this seemed to work out. Finally - happy days ! You will see those additional 5 clocks in my timing diagrams.
During a write transaction the host also needs to swap RWDS from an input to an output and drive that pin to control the mode by which data gets loaded into HR (there’s a little info about this under notes 3/4 in Fig 11.6, and also see the comments about data masking at the top of p. 38). RWDS needs to be restored to an input pin after the write operation.
I hold the CS line high all the time apart from in my primitives that write to CR0/CR1 and that do the HR read buffer/write buffer operations. The CLK signal is also only active during those periods.
I can write large numbers of 32/64/128 byte buffers of data via a loop rapidly into HR, wait for an “indefinite” period and then successfully read the data back again so the self-refreshing appears to be ok.
Once I got myself to this point I didn’t do any further experimenting with my HR interface as I just wanted to get on and use it in several larger projects. I described a couple of those on the website.
I confirmed that the XMOS Startkit has no problem moving 64 byte chunks into/out of HR inside a 4 usec window. That speed is perfectly adequate for me but the chip is capable of much faster operation. Certainly would be nice but non trivial…. An FPGA solution seems to beckon.
To date I haven’t attempted to do anything with HR for P1, figuring it wouldn’t likely be as fast as the Startkit. That said, I’d be really interested to see HR connected to a P2 emulation, but that will require someone far more savvy than me knowing how to use the streamer and smart pins in conjunction with one another to do so. I think that would make a great project and could serve as a really nice illustrative example of how those P2 features could be used to solve a practical problem.
Any takers ?? Ozpropdev could probably do this in his sleep..The payback is 8MB of memory for <$5 and only tying up 12 I/O lines.
That’s about all I can tell you right now but I’ll go back and “refresh !” my memory of the code again in the coming week.
Tracy Allen
While it would have been nice to indulge (la dolce vita), unfortunately it was not to be.
Yes those Balters piezo micropumps are an interesting innovation for fluidics experiments. There’s a US distributor in the Boston area. Oh and by the way, Balters have very recently released an OEM driver board that can run 4 MP6 pump channels.
Having worked a lot with peristaltic pumps I’ve been looking for something smaller, cheaper and less power hungry for field analysis work. Really just getting started out in this area, but these little devices are a perfect match to many of the small instruments I’ve described on the website.
PaulRowntree
Very interested to hear about your molecular beam TOF instrument and the chopper/multichannel scaler you developed. Yes one can do a hell of a lot with the P1 !
Also, your First Year Chem labs at the Univ. of Guelph sound just like the ones I used to work in at Monash University, here in Melbourne, Australia. The problems you mentioned are ubiquitous at universities worldwide and were really what got me started down the small instrument path – lots of students, a dearth of instruments meaning lots of very old fashioned (and boring) wet chemistry – titrations etc and small budgets, with a reluctance to let u/g’s onto research-grade instruments for fear they might get broken. Definitely thinking about a flexible system based on a Propeller….
---
VBB
I’ll definitely check out your Virtual Breadboard/Infinity Shield concept – it looks very interesting too. Did you know about LabVIEW Maker Hub ?? – a very low cost way to get into LabVIEW which might be worth checking out.
Apologies to all for the long post.
Richard
Does that indicate self-refresh can occur when CS=H, and no clock is needed at that time ?
I'd agree P2 will give the highest burst speeds, but P1 should also work, and give a useful hardware proof platform.
P1 should be able to stream data at reasonable speeds, (ie just by providing a clock) and a P1+HyperRAM+LVC573 should? be able to maintain a VGA type raster, with the LVC573.oe isolating the display during HV-Blanking, & flyback writes.
If self-refresh is ok with sufficient CS=H, and if RWDS can be ignored with right config settings, P1 code should be simpler.
2 Timers could manage H-Sync and HV-Blanking, with V-Sync done in SW ?
A LVC646 could allow background hold feature, for more write bandwidth with common HMI/Text font displays.
Yes - self-refresh is happening when cs is high. No clock running - CLK line is low except during the reads/writes. I'm not familiar with the LVC573 but will investigate for interest. I agree it would be great to have HR running on a P1.
Definitely start out by setting bit 3 in CR0 as that will save hassle with RWDS
Do you have some hardware to work with - there was some discussion about this quite some time back and someone had built a PCB but I haven't kept up-to-date with that - was that you ?
Rayman made one here
http://forums.parallax.com/discussion/164540/usb-usd-hyperram-flash-camera-test-board-for-p123
and also this one, by T Chap
http://forums.parallax.com/discussion/comment/1379041/#Comment_1379041
and I think there was one smaller one too....
maybe this one from Tubular
http://forums.parallax.com/discussion/comment/1377007/#Comment_1377007
All nearly 1 year ago, but I've seen no reports of HyperRAM working with P1 ?
Actually I didn't know about Maker Hub and can only find a community not a specific product. But I think you misunderstood my post because the goal is to replace LabVIEW and use VBB instead as a lower cost solution to creating instrument visualisation and I wanted to use your LabVIEW expertise to indicate the 'minimum viable product' collection of visualisation 'widgets' that I would need to implement based on your existing LabVIEW based instrumentation and experience.
The concept is to take instrumentation interfaces and put them into a shield format. Actually pretty much like this :
Instruments on Shields
So instead of using the STM32 base , using the propeller powered infinity shield with VBB for Lab Visualisations and you have potentially a low cost solution for education labs.
The idea was to basically take your instrument interfaces and drivers and make shields from them in the same was as ST has done as per the above link.
Anyhow, probably I will get started with a couple of the Analog Device Shields and port some of their drivers as a first step to create an evaluation kit for the concept.
Of course access to the lab market is always the issue but that's why with this thread became interesting because of your own long educational background and also PaulRownTree's post who has direct contact with the problem as department chair.