Lots to think about there. I'm fairly comfortable with tight pitch footprints and even thinking of trying some BGA packages in the future. I've been looking at larger SRAMs but they get expensive quick. I'll have to look at the MUX-RAM but I'm considering putting a couple HYPER-RAMs on my next board. The Eve2 has been on my list for a while, they seem really interesting.
I've got one of those SPI displays on the way, along with a bunch of other goodies. I've explored a low pin count solution a few times and with an 8 bit bus instead of 16, it could be done with 11 or 12 propeller pins but you sacrifice a lot of speed for setup. Right now the 64 macrocell device is less than half full. Another idea I had in the past was to isolate the propeller pins when doing ram -> display transfers but that needs more cpld pins.
One of the things I've been considering is how to handle multiple displays. Each additional display only requires 2 more pins... I guess the question is how long of a ribbon cable and at what point the capacitive loading becomes too much.
You then have 2 clocks, one for write to PSRAM, and one for LCD when reading.
What's not clear on these parts are the rules around refresh.
I'm assuming they have the same usual 32~64ms refresh cycling times, and the sub-slices within that are somewhat more flexible, allowing Line playback, then burst write or refresh in flyback.
If you do not need other-image storage, and are ok with just 1 frame payback then the frame time should be ok for that portion of refresh.
-I want a fast modern-looking GUI (people are accustomed to smartphone quality)
-Low cost
-UI is subjected to day-to-day abuse. Needs to be easily replaced.
-Prop resources are tight and therefore precious.
Stick a cheap Android tablet on the front end and link to the Prop via BlueTooth.
Use the free/open source RFO Basic (Richard Feynman Observatory) interpreter to create the Android app (ridiculously easy to use).
I also use a RAD tool for the UI: RFODESIGNER
RFO Basic is aka: BASIC! (including the exclamation) on Google Play.
-I want a fast modern-looking GUI (people are accustomed to smartphone quality)
-Low cost
-UI is subjected to day-to-day abuse. Needs to be easily replaced.
-Prop resources are tight and therefore precious.
Stick a cheap Android tablet on the front end and link to the Prop via BlueTooth.
Use the free/open source RFO Basic (Richard Feynman Observatory) interpreter to create the Android app (ridiculously easy to use).
I also use a RAD tool for the UI: RFODESIGNER
RFO Basic is aka: BASIC! (including the exclamation) on Google Play.
Interesting take. I've got an ESP8266 on the way and probably picking up an ESP32 soon. Also have a HC-06 Bluetooth serial on the way. It will be interesting to play around with these.
For my purposes a "modern" gui is a bit flashy. I'm still a fan of the good ol win98 look personally. I'll be taking some pictures and video once I actually start working on hardware because they really speak for themselves. Right now I'm setting up my workbench and in redesign stage.
Cost is subjective again. These boards look like they're going to cost around $50 a piece once assembled.
This design is intended to extend the prop's resources, you actually get MORE digital pins although you need to know a bit about how you want to use them first. The SRAM design is intended for the highest bandwith transfers possible on a 16 bit bus. This should allow fairly fast, large C programs. Just to give you an idea of what can be done though
-I want a fast modern-looking GUI (people are accustomed to smartphone quality)
-Low cost
-UI is subjected to day-to-day abuse. Needs to be easily replaced.
-Prop resources are tight and therefore precious.
Stick a cheap Android tablet on the front end and link to the Prop via BlueTooth.
Use the free/open source RFO Basic (Richard Feynman Observatory) interpreter to create the Android app (ridiculously easy to use).
I also use a RAD tool for the UI: RFODESIGNER
RFO Basic is aka: BASIC! (including the exclamation) on Google Play.
Mickster, using an Android device as a GUI for the Prop looks very interesting. Do you have any working code or examples to show us?
Sure, I'm on-site right now but I'll post source and the actual apk when I get back to my desk.
It really is child's play; in the BASIC! code, you simply open the BT comms with "BT.Open" and then poll "BT.Status". If BT.Status = 3, there is data to be read.
Of course there is a BT.Read and a BT.Write. Simply a wireless serial port.
I have the remote BT device set up as the "master" with "autoconnect". I can walk out of range with the tablet and back in to range and communication resumes without any fuss.
I've got an ESP8266 on the way and probably picking up an ESP32 soon.
I just tested a WiFi-to-RS422 with BASIC! Just as easy as BT.
What I like about using mobile devices is that if the main device (tablet) fails for any reason, you can download the app to a phone, pair the BT and you are up and running again.
One of my clients had a Siemens touch-panel fail after 3 years. £4,000 for a replacement and he was dead-in-the-water for a week.
This is a very simple system that I just started on.
I have 4 old pipe-bending machines to re-control. The youngest is circa 1976.
The operators are quite senior and quite intimidated by "computers".
I am replacing pushbuttons and rotary switches with a 7" tablet so simplicity is the order of the day.
90% of the code is generated by RFODESIGNER, hence the (offensive) redundant IF-THEN structure.
This can be cleaned up once I'm done with this UI generator and I start to hand-code.
Look for the lable "Bthnd" for the BT stuff.
The apk compilation isn't a compiler as such. The interpreter is packaged with your source but it runs like any Android app.
Comments
I've got one of those SPI displays on the way, along with a bunch of other goodies. I've explored a low pin count solution a few times and with an 8 bit bus instead of 16, it could be done with 11 or 12 propeller pins but you sacrifice a lot of speed for setup. Right now the 64 macrocell device is less than half full. Another idea I had in the past was to isolate the propeller pins when doing ram -> display transfers but that needs more cpld pins.
One of the things I've been considering is how to handle multiple displays. Each additional display only requires 2 more pins... I guess the question is how long of a ribbon cable and at what point the capacitive loading becomes too much.
https://lcsc.com/product-detail/RAM_Lyontek-Inc-LY68L6400SLIT_C261881.html
You then have 2 clocks, one for write to PSRAM, and one for LCD when reading.
What's not clear on these parts are the rules around refresh.
I'm assuming they have the same usual 32~64ms refresh cycling times, and the sub-slices within that are somewhat more flexible, allowing Line playback, then burst write or refresh in flyback.
If you do not need other-image storage, and are ok with just 1 frame payback then the frame time should be ok for that portion of refresh.
-I want a fast modern-looking GUI (people are accustomed to smartphone quality)
-Low cost
-UI is subjected to day-to-day abuse. Needs to be easily replaced.
-Prop resources are tight and therefore precious.
Stick a cheap Android tablet on the front end and link to the Prop via BlueTooth.
Use the free/open source RFO Basic (Richard Feynman Observatory) interpreter to create the Android app (ridiculously easy to use).
I also use a RAD tool for the UI: RFODESIGNER
RFO Basic is aka: BASIC! (including the exclamation) on Google Play.
Interesting take. I've got an ESP8266 on the way and probably picking up an ESP32 soon. Also have a HC-06 Bluetooth serial on the way. It will be interesting to play around with these.
For my purposes a "modern" gui is a bit flashy. I'm still a fan of the good ol win98 look personally. I'll be taking some pictures and video once I actually start working on hardware because they really speak for themselves. Right now I'm setting up my workbench and in redesign stage.
Cost is subjective again. These boards look like they're going to cost around $50 a piece once assembled.
This design is intended to extend the prop's resources, you actually get MORE digital pins although you need to know a bit about how you want to use them first. The SRAM design is intended for the highest bandwith transfers possible on a 16 bit bus. This should allow fairly fast, large C programs. Just to give you an idea of what can be done though
https://forums.parallax.com/discussion/comment/1122465/#Comment_1122465
Mickster, using an Android device as a GUI for the Prop looks very interesting. Do you have any working code or examples to show us?
It really is child's play; in the BASIC! code, you simply open the BT comms with "BT.Open" and then poll "BT.Status". If BT.Status = 3, there is data to be read.
Of course there is a BT.Read and a BT.Write. Simply a wireless serial port.
I have the remote BT device set up as the "master" with "autoconnect". I can walk out of range with the tablet and back in to range and communication resumes without any fuss.
I just tested a WiFi-to-RS422 with BASIC! Just as easy as BT.
What I like about using mobile devices is that if the main device (tablet) fails for any reason, you can download the app to a phone, pair the BT and you are up and running again.
One of my clients had a Siemens touch-panel fail after 3 years. £4,000 for a replacement and he was dead-in-the-water for a week.
Edit:
http://uconnect.com.tw
This is a very simple system that I just started on.
I have 4 old pipe-bending machines to re-control. The youngest is circa 1976.
The operators are quite senior and quite intimidated by "computers".
I am replacing pushbuttons and rotary switches with a 7" tablet so simplicity is the order of the day.
90% of the code is generated by RFODESIGNER, hence the (offensive) redundant IF-THEN structure.
This can be cleaned up once I'm done with this UI generator and I start to hand-code.
Look for the lable "Bthnd" for the BT stuff.
The apk compilation isn't a compiler as such. The interpreter is packaged with your source but it runs like any Android app.