Forums > Technical Discussion > FAO: All Hoppy Techies....
Login/Join to ParticipateBRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
...I'm after some advice. I'm starting to think about making progress on the software side of my HyperLights. There are basically 3 parts to the problem:
1) The software that runs on the micro-controller. This is (currently) written in assembly and is what makes the poi do their flashy things
This is already mostly written to the poin that the poi flash a sequence of patterns. There's going to be a major overhaul soon though (see point 3).
2) The software that allows even the most non-technically-minded of folk to build up sequences and patterns into just about any effect you can imagine. This is still entirely in the planning stages. I'm tempted to write it in VC++ as this is what I'm most familiar with, however, I'd also like it platform independant which suggests Java to me. I've done some java development in my dim and distant uni days, but I would be pretty much starting from scratch (quite a learning curve!). Can Java be compiled into and executable that doesn't require the JRE? Can an applet(?) be run from a website (so that people wouldn't need to install a program, just load up the applet on the hyperlights site)? Is it truly worth going for platform independance given that most people who will use HyperLights will likely use windows?
3) This is probably of most interest to those of you that post replies to this thread. This is the language that sits between 1 and 2.. I'm calling it Poi++
Basically, it's the scripting language that is used to tell the PIC what to do. Sequences devised in (2) would be compiled into this so that the software (1) can run it. There's no reason why the text script couldn't be used to define sequences though!
I'm quite tempted to make (2) and (3) OpenSource as what I'm selling is really the hardware and the software that drives it. By making the intermediate language and the front end open source, that should hopefully make my life easier (you guys can helkp me!
), and also give us software that's easier to use and less full of bugs!
So, opinions, offers of help, better suggestions? I'm listening
...I'm after some advice. I'm starting to think about making progress on the software side of my HyperLights. There are basically 3 parts to the problem:
1) The software that runs on the micro-controller. This is (currently) written in assembly and is what makes the poi do their flashy things
This is already mostly written to the poin that the poi flash a sequence of patterns. There's going to be a major overhaul soon though (see point 3).2) The software that allows even the most non-technically-minded of folk to build up sequences and patterns into just about any effect you can imagine. This is still entirely in the planning stages. I'm tempted to write it in VC++ as this is what I'm most familiar with, however, I'd also like it platform independant which suggests Java to me. I've done some java development in my dim and distant uni days, but I would be pretty much starting from scratch (quite a learning curve!). Can Java be compiled into and executable that doesn't require the JRE? Can an applet(?) be run from a website (so that people wouldn't need to install a program, just load up the applet on the hyperlights site)? Is it truly worth going for platform independance given that most people who will use HyperLights will likely use windows?
3) This is probably of most interest to those of you that post replies to this thread. This is the language that sits between 1 and 2.. I'm calling it Poi++
Basically, it's the scripting language that is used to tell the PIC what to do. Sequences devised in (2) would be compiled into this so that the software (1) can run it. There's no reason why the text script couldn't be used to define sequences though!I'm quite tempted to make (2) and (3) OpenSource as what I'm selling is really the hardware and the software that drives it. By making the intermediate language and the front end open source, that should hopefully make my life easier (you guys can helkp me!
), and also give us software that's easier to use and less full of bugs!So, opinions, offers of help, better suggestions? I'm listening
Cake or Death?
PLATINUM Member
Flying Water Muppet
5,276 posts
Location: Edin-borrow., United Kingdom
Flying Water Muppet
5,276 posts
Location: Edin-borrow., United Kingdom
Posted:
I would think some of them use macs?
I would think some of them use macs?
"the now legendary" - Kaskade
"the still legendary" - Kaskade
I spunked in my friend's aquarium and the fish ate it. I love all fish. Especially the pink ones. They are my bitches. - Anon.
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
Good point.. I just got a message from Mo-seph suggesting we have a hack at the program he came up with a while back. It's Java based and from what I've seen, looks like it may well work for what I want to do!
Good point.. I just got a message from Mo-seph suggesting we have a hack at the program he came up with a while back. It's Java based and from what I've seen, looks like it may well work for what I want to do!
Cake or Death?
PLATINUM Member
Flying Water Muppet
5,276 posts
Location: Edin-borrow., United Kingdom
Flying Water Muppet
5,276 posts
Location: Edin-borrow., United Kingdom
Posted:
He's the man.
He's the man.
"the now legendary" - Kaskade
"the still legendary" - Kaskade
I spunked in my friend's aquarium and the fish ate it. I love all fish. Especially the pink ones. They are my bitches. - Anon.
BRONZE Member
Still wiggling
5,967 posts
Location: Belfast, Northern Ireland (UK)
Still wiggling
5,967 posts
Location: Belfast, Northern Ireland (UK)
Posted:
Can't wait to see the finished product, good luck
Can't wait to see the finished product, good luck
Getting to the other side 
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
You'll be waiting a while
You'll be waiting a while
Cake or Death?
GOLD Member
the floor is a sea of tigers...
404 posts
the floor is a sea of tigers...
404 posts
Posted:
Poi++? that makes it sound like an object orientated language... how about Poithon hehehe
but the thing about having an applet on a website might not be feasable, as you'd have to be able to upload the sequence (which i assume would be read by some form of a bootloader*ish* type thingo on the microcontroller)... anyway, i don't think a java applet on a webpage would have access to the poi via usb/serial (assuming you're using icsp...)
but then i could be wrong as I don't program in java & only have been mucking around with electornics & programmable microcontrollers for about a month or so :P and i'm still trying to fix the programming problems on my current project
Poi++? that makes it sound like an object orientated language... how about Poithon
hehehebut the thing about having an applet on a website might not be feasable, as you'd have to be able to upload the sequence (which i assume would be read by some form of a bootloader*ish* type thingo on the microcontroller)... anyway, i don't think a java applet on a webpage would have access to the poi via usb/serial (assuming you're using icsp...)
but then i could be wrong as I don't program in java & only have been mucking around with electornics & programmable microcontrollers for about a month or so :P and i'm still trying to fix the programming problems on my current project
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
You may have a point (lol) there Oracle. Poithon's probably more apt
You've probably got a point about the applet too, although I get the impression I know no more than you! There's no bootloader - an EEPROM will hold all the data. I'm thinking something like USB, Serial or IR (or possibly some hybrid of those) is going to be the interface. It'll most probably be a USB interface as just about every computer has one these days! Either way, you're right, whatever happens, people will need to install the USB driver so they might as well have the java stuff too.
I've got a few months more experience lead on you, but I'm a slow learner
You may have a point (lol) there Oracle. Poithon's probably more apt
You've probably got a point about the applet too, although I get the impression I know no more than you! There's no bootloader - an EEPROM will hold all the data. I'm thinking something like USB, Serial or IR (or possibly some hybrid of those) is going to be the interface. It'll most probably be a USB interface as just about every computer has one these days! Either way, you're right, whatever happens, people will need to install the USB driver so they might as well have the java stuff too.
I've got a few months more experience lead on you, but I'm a slow learner
Cake or Death?
SILVER Member
veteran
1,228 posts
Location: on the wrong planet, United Kingdom
veteran
1,228 posts
Location: on the wrong planet, United Kingdom
Posted:
Flash is probably easier than EEPROM, as there are plenty of ways to get to it from USB, and PICs can handle flash directly too. Then you'd only need to drag a file onto a disk device.
You could use javascript and a web interface to put together sequencing scripts, as it's not going to take much processing power to compile.
If you fill in a form, press a button, and it does a window.open, then document.writes using the data you just submitted, you could save the generated page as the script file, directly to the flash disk.
The PIC could use ASCII values as programming tokens. ASCII should give you a big enough instruction set with character to instruction mapping. By using javascript anyone with a text editor and a web browser can modify the compiler code, making it totally platform independant and very easy to modify.
If you wanted anything more complex you could always generate script files using other languages, but by making the scripts pure ASCII ensures that they don't need much to edit, could have parts cut and pasted in a text editor, and people could post sequences online and in emails.
Have you thought about making the script platform independant for different poi types?
Flash is probably easier than EEPROM, as there are plenty of ways to get to it from USB, and PICs can handle flash directly too. Then you'd only need to drag a file onto a disk device.
You could use javascript and a web interface to put together sequencing scripts, as it's not going to take much processing power to compile.
If you fill in a form, press a button, and it does a window.open, then document.writes using the data you just submitted, you could save the generated page as the script file, directly to the flash disk.
The PIC could use ASCII values as programming tokens. ASCII should give you a big enough instruction set with character to instruction mapping. By using javascript anyone with a text editor and a web browser can modify the compiler code, making it totally platform independant and very easy to modify.
If you wanted anything more complex you could always generate script files using other languages, but by making the scripts pure ASCII ensures that they don't need much to edit, could have parts cut and pasted in a text editor, and people could post sequences online and in emails.
Have you thought about making the script platform independant for different poi types?
You aren't thinking or really existing unless you're willing to risk even your own sanity in the judgment of your existence.
Green peppers, lime pickle and whole-grain mustard = best sandwich filling.
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
By flash d'you mean compact flash? Because that's a little bigger than I would want to use.
I can see what you're saying with the web stuff, but I can't help feeling that method would seem a bit 'clunky'. I want these things to be as easy to use as possible. If we just have a single little app where you just hit a button which uploads everything for you, that might be easier for a lot of people. That's my thinking anywho
I could be (and probably am) wrong, but would we be able to produce a drag and drop type interface in javascript, including an opengl (or whatever) visualisation of what the poi would look like spinning? I get the feeling that what I want to achieve is just a bit too complicated to pull off using javascript.
Different poi types? Not sure what you mean? One interface to program any poi (Hyperlight, polar lights, aero's, ...)?
By flash d'you mean compact flash? Because that's a little bigger than I would want to use.
I can see what you're saying with the web stuff, but I can't help feeling that method would seem a bit 'clunky'. I want these things to be as easy to use as possible. If we just have a single little app where you just hit a button which uploads everything for you, that might be easier for a lot of people. That's my thinking anywho
I could be (and probably am) wrong, but would we be able to produce a drag and drop type interface in javascript, including an opengl (or whatever) visualisation of what the poi would look like spinning? I get the feeling that what I want to achieve is just a bit too complicated to pull off using javascript.
Different poi types? Not sure what you mean? One interface to program any poi (Hyperlight, polar lights, aero's, ...)?
Cake or Death?
enthusiast
523 posts
Location: Edinburgh, UK
523 posts
Location: Edinburgh, UK
Posted:
I would suggest
- write a language spec, that will do what you want
- write some sequences using the language
- write something which will compile this for your setup (even if it's just writing out blocks of hex which get included in a buildfile)
- write a gui for creating sequences, which can use the previous step to write them to your toy
- figure out how to write them to other toys/your toys over some nice interface
Doing it this way gets you something which works early, with the core part (the language being able to do what you need) tested and developed. Leaving the gui till later will probably get you a better gui, and make it easier to write different ones for different applications.
In terms of getting it onto the toy, it's possible to do usb stuff on small micros - there's a stack for the AVRs which is under 2k. That would make it pretty easy to put sequences on.
People have also talked about flashing lights on screen to do serial links - you get about 10b/s if I remember right, which could probably do a sequence a minute depending on how lean you can make the language.
An applet almost certainly can't do usb. I think there are solutions for making java run without a jre (which are effectively a way of bundling the jre with your stuff, if I remember right). It might be that using some cross platform development kit (GnuStep comes to mind, but I haven't used it) and C/C++ would be just as compatible and more easily portable.
I would suggest
- write a language spec, that will do what you want
- write some sequences using the language
- write something which will compile this for your setup (even if it's just writing out blocks of hex which get included in a buildfile)
- write a gui for creating sequences, which can use the previous step to write them to your toy
- figure out how to write them to other toys/your toys over some nice interface
Doing it this way gets you something which works early, with the core part (the language being able to do what you need) tested and developed. Leaving the gui till later will probably get you a better gui, and make it easier to write different ones for different applications.
In terms of getting it onto the toy, it's possible to do usb stuff on small micros - there's a stack for the AVRs which is under 2k. That would make it pretty easy to put sequences on.
People have also talked about flashing lights on screen to do serial links - you get about 10b/s if I remember right, which could probably do a sequence a minute depending on how lean you can make the language.
An applet almost certainly can't do usb. I think there are solutions for making java run without a jre (which are effectively a way of bundling the jre with your stuff, if I remember right). It might be that using some cross platform development kit (GnuStep comes to mind, but I haven't used it) and C/C++ would be just as compatible and more easily portable.
monkeys ate my brain
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
Lots of things to think about.. I've got a lot of bits and peices to do with Poithon scribbled down, nothing specific, but lots and lots of ideas. I think this is probably what I'll do:
1) First step will be getting my hyperlights to store / read stuff off the EEPROM (or whatever).
2) Get the hyperlights to run a pattern from the eeprom (Currently, it's just a load of sequences that are hard-coded on the PIC).
3) Get the USB interface up and running.
4) Get something (probably quite crude) to send a pattern to a hyperlight and make it run the new pattern. <-- I'm going to be a very excited young man when that happens
5) Your list of bits.
I think the hardware needs a bit more work before I'm ready to start fiddling with the software as that bit has a pretty big influence on what the software needs to do! I'm considering getting some prototype PCBs built soon so I can test some stuff I've been thinking about for a while now (too long!)
Lots of things to think about.. I've got a lot of bits and peices to do with Poithon scribbled down, nothing specific, but lots and lots of ideas. I think this is probably what I'll do:
1) First step will be getting my hyperlights to store / read stuff off the EEPROM (or whatever).
2) Get the hyperlights to run a pattern from the eeprom (Currently, it's just a load of sequences that are hard-coded on the PIC).
3) Get the USB interface up and running.
4) Get something (probably quite crude) to send a pattern to a hyperlight and make it run the new pattern. <-- I'm going to be a very excited young man when that happens
5) Your list of bits.
I think the hardware needs a bit more work before I'm ready to start fiddling with the software as that bit has a pretty big influence on what the software needs to do! I'm considering getting some prototype PCBs built soon so I can test some stuff I've been thinking about for a while now (too long!)
Cake or Death?
SILVER Member
old hand
717 posts
Location: Bristol, England
old hand
717 posts
Location: Bristol, England
Posted:
Just a quick not before I go to the pub. If you're at sheffield I'd deffo like a chat.
USB is a complex beast. But you can get Virtual Serial COM port interface for USB so it shows up as a com port and your pic thinks it's attached to a COM Port.
You are mentioning loading and running patterns and having code on the eeprom that reads this pattern code and runs it.
Another option is to generate the PIC code that performs the patters you've coded and load it directly onto the EEPOM.
You'll then have no interpreter running and may get more speed.
Off to pub now
Just a quick not before I go to the pub. If you're at sheffield I'd deffo like a chat.
USB is a complex beast. But you can get Virtual Serial COM port interface for USB so it shows up as a com port and your pic thinks it's attached to a COM Port.
You are mentioning loading and running patterns and having code on the eeprom that reads this pattern code and runs it.
Another option is to generate the PIC code that performs the patters you've coded and load it directly onto the EEPOM.
You'll then have no interpreter running and may get more speed.
Off to pub now
"**grumble*spuriouswindmills*grumble**" - Coleman
"if poi was only for girls there wouldnt be many good poi spinners...." - Nx
SILVER Member
veteran
1,228 posts
Location: on the wrong planet, United Kingdom
veteran
1,228 posts
Location: on the wrong planet, United Kingdom
Posted:
I think mini-SD can be written directly, probably with SPI. Other than that there are flash chips that can do the job and are even smaller, and a whole host of single chip USB to flash device chips.
If the language specification is thought out well enough, then the language should be totally independant from any one program that outputs scripts, and also readable by as many different poi as possible (I'm thinking your future versions as well as any made by other people*). My main reason for sugesting ASCII is that it's a good medium, being writable by more sources than pure hex, still poi readable at a reasonable speed, and has the bonus of being more human readable than hex, which would come in handy when debugging the output of anything that generates code. Also there are a lot of programming tools for handling text characters, as there are so many string and regex functions, that could be used to mix and match patterns, and check for errors in output code.
There may always be limitations in machine generated scripts, so it's always a good idea to have it human readable too. Human readable blocks of script could always be read back into the script compiler, even if it doesn't have the ability to generate them itself.
*My own poi are going to have a new method of combining strobes and fades, that means scripts for other poi probably won't be totally compatable, unless support for this is included in the language specification. I will be able to get some really complex sequences though
I think mini-SD can be written directly, probably with SPI. Other than that there are flash chips that can do the job and are even smaller, and a whole host of single chip USB to flash device chips.
If the language specification is thought out well enough, then the language should be totally independant from any one program that outputs scripts, and also readable by as many different poi as possible (I'm thinking your future versions as well as any made by other people*). My main reason for sugesting ASCII is that it's a good medium, being writable by more sources than pure hex, still poi readable at a reasonable speed, and has the bonus of being more human readable than hex, which would come in handy when debugging the output of anything that generates code. Also there are a lot of programming tools for handling text characters, as there are so many string and regex functions, that could be used to mix and match patterns, and check for errors in output code.
There may always be limitations in machine generated scripts, so it's always a good idea to have it human readable too. Human readable blocks of script could always be read back into the script compiler, even if it doesn't have the ability to generate them itself.
*My own poi are going to have a new method of combining strobes and fades, that means scripts for other poi probably won't be totally compatable, unless support for this is included in the language specification. I will be able to get some really complex sequences though
You aren't thinking or really existing unless you're willing to risk even your own sanity in the judgment of your existence.
Green peppers, lime pickle and whole-grain mustard = best sandwich filling.
GOLD Member
Pirate Pixie Crew Captain
8,428 posts
Location: Wales
Pirate Pixie Crew Captain
8,428 posts
Location: Wales
Posted:
Ahhhhhhh look! All the geeky boys are bonding
Sorry, no offence meant
Yay for Geeky boys!
Ahhhhhhh look! All the geeky boys are bonding
Sorry, no offence meant
Yay for Geeky boys!
Feed me Chocolate!!! Feed me NOW!
Internet Hate Machine
10,530 posts
Location: They seek him here, they seek him there...
10,530 posts
Location: They seek him here, they seek him there...
Posted:
Jeezus.... I thought I was geeky till now!
You guys have put me to shaaaaaame!
Mr. Hyperlight, I suggest that you ditch this project and start on staves instead.
Other than that, good luck with this, and I am anticipating the release of the latest model with great erm.... anticipation.
Balls... that sucked.
Jeezus.... I thought I was geeky till now!
You guys have put me to shaaaaaame!
Mr. Hyperlight, I suggest that you ditch this project and start on staves instead.
Other than that, good luck with this, and I am anticipating the release of the latest model with great erm.... anticipation.
Balls... that sucked.
The existance of flamethrowers says that someone, somewhere, at sometime said "I need to set that thing on fire, but it's too far away."
GOLD Member
the floor is a sea of tigers...
404 posts
the floor is a sea of tigers...
404 posts
Posted:
talking about a scripting language, i think it'd be really cool if in the end, a standard were developed. and if it was flexible enough to accomodate multi light devices (anything from a poi with 1 light, to staves with 20 lights, etc., etc.) it'd really help the development of other glowtoys i think.
Written by:would doing that be more efficent in the end? i think you'd use at least 1 or 3 bytes of program memory per interval. not very efficent, but say if you stored the sequence in the program memory itself (can't remember which chips can read data from their program memory, but i do know the 16F87xA chips can store a 14bit word in each byte of program memory)
Another option is to generate the PIC code that performs the patters you've coded and load it directly onto the EEPOM.
You'll then have no interpreter running and may get more speed.
talking about a scripting language, i think it'd be really cool if in the end, a standard were developed. and if it was flexible enough to accomodate multi light devices (anything from a poi with 1 light, to staves with 20 lights, etc., etc.) it'd really help the development of other glowtoys i think.
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
That's certainly an option, but processing power on the pic isn't really an issue. If you were running pic commands right off the eeprom, things would probably be more flexible, but your eeprom would have to be faster, and you'd have less space as you'd be using more commands. That's something I'd not thought about before though and you may have an idea - certainly worth investigating
If you were using program memory, that would certainly be faster. It means that the software you have on your PC to do the sequences would be more complicated though... and much more difficult to write
That's certainly an option, but processing power on the pic isn't really an issue. If you were running pic commands right off the eeprom, things would probably be more flexible, but your eeprom would have to be faster, and you'd have less space as you'd be using more commands. That's something I'd not thought about before though and you may have an idea - certainly worth investigating
If you were using program memory, that would certainly be faster. It means that the software you have on your PC to do the sequences would be more complicated though... and much more difficult to write
Cake or Death?
BRONZE Member
Still wiggling
5,967 posts
Location: Belfast, Northern Ireland (UK)
Still wiggling
5,967 posts
Location: Belfast, Northern Ireland (UK)
Posted:
(Tis exciting though... in a couple of years we'll look back and remember this thread and you guys coming up with these funky shiny toys)
(Tis exciting though... in a couple of years we'll look back and remember this thread and you guys coming up with these funky shiny toys)
Getting to the other side
GOLD Member
king of the hedgehogs
125 posts
Location: Madtown, USA
king of the hedgehogs
125 posts
Location: Madtown, USA
Posted:
All Java applets require a JRE of some variety. Code is compiled for the JVM (virtual machine) and you have to have the VM running on whatever platform you are working with. It's really kind of a pain. Personally for what you are trying to do, I would think something like Ruby or Python or even Perl would get the job done, especially if you want to use a web based interface.
Also, no, most of my friends who are in to poi use a Mac - I don't think that it is accurate to suggest a Windows dominated culture.
Written by: *HyperLight
Can Java be compiled into and executable that doesn't require the JRE? Can an applet(?) be run from a website (so that people wouldn't need to install a program, just load up the applet on the hyperlights site)? Is it truly worth going for platform independance given that most people who will use HyperLights will likely use windows?
All Java applets require a JRE of some variety. Code is compiled for the JVM (virtual machine) and you have to have the VM running on whatever platform you are working with. It's really kind of a pain. Personally for what you are trying to do, I would think something like Ruby or Python or even Perl would get the job done, especially if you want to use a web based interface.
Also, no, most of my friends who are in to poi use a Mac - I don't think that it is accurate to suggest a Windows dominated culture.
Yellow and blue make green.
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
I'm hesitant about using Java / Python / Perl because they all require that you have something besides the app I want to run, installed on your machine. The problem with doing something native to each O/S is that I've only had experience writing code for Windows. Now that doesn't mean the other O/S's are an unfathomable task, but it does present a challenge.
With regards the windows vs Mac / Linux / Unix / whatever, I was talking about the world in general. It wouldn't suprise me to find that a lot of people who spin poi are different from the norm though - we're special
I think overall, Java is likely to be the best solution, even if it means people have to install the JRE...
I'm hesitant about using Java / Python / Perl because they all require that you have something besides the app I want to run, installed on your machine. The problem with doing something native to each O/S is that I've only had experience writing code for Windows. Now that doesn't mean the other O/S's are an unfathomable task, but it does present a challenge.
With regards the windows vs Mac / Linux / Unix / whatever, I was talking about the world in general. It wouldn't suprise me to find that a lot of people who spin poi are different from the norm though - we're special
I think overall, Java is likely to be the best solution, even if it means people have to install the JRE...
Cake or Death?
SILVER Member
old hand
717 posts
Location: Bristol, England
old hand
717 posts
Location: Bristol, England
Posted:
I don't think the JRE is always needed (https://gcc.gnu.org/java) Although having not played around with this I can really say...
But the Quote "Java source code directly to native machine code," Seems to hint that what I've said above is true!
The problem seems to be that the windowing stuff is unsupported.
If you keep it nice and seperated and have the thingy that generates the stuff you load on the PIC separate from the GUI people can write native front ends for there OS of choice. witt the back end command line utility written in java so it's portable. (I reckon I should win an award for clarity for that sentance)
I'd definatly like to have a go at knocking up a .NET GUI as I've played around with it and it's pretty cool but never really had somthing I've wanted to work on before.
I don't think the JRE is always needed (https://gcc.gnu.org/java) Although having not played around with this I can really say...
But the Quote "Java source code directly to native machine code," Seems to hint that what I've said above is true!
The problem seems to be that the windowing stuff is unsupported.
If you keep it nice and seperated and have the thingy that generates the stuff you load on the PIC separate from the GUI people can write native front ends for there OS of choice. witt the back end command line utility written in java so it's portable. (I reckon I should win an award for clarity for that sentance)
I'd definatly like to have a go at knocking up a .NET GUI as I've played around with it and it's pretty cool but never really had somthing I've wanted to work on before.
"**grumble*spuriouswindmills*grumble**" - Coleman
"if poi was only for girls there wouldnt be many good poi spinners...." - Nx
GOLD Member
Member
232 posts
Location: United Kingdom
Member
232 posts
Location: United Kingdom
Posted:
Maybe use c# if you're doing it Java based : that compiles exe's, and doesnt require a VM. Platform independent, basically C++, but Java. Java is icky though.
BTW: A Java applet on a webpage could have access to the poi via usb/serial.
If webbased, go Flash
So says a random friend of mine, not a hardcore programmer but he at least understands this strange computer speak unlike me.
EDITED_BY: Kieron (1132230771)
Maybe use c# if you're doing it Java based : that compiles exe's, and doesnt require a VM. Platform independent, basically C++, but Java. Java is icky though.
BTW: A Java applet on a webpage could have access to the poi via usb/serial.
If webbased, go Flash
So says a random friend of mine, not a hardcore programmer but he at least understands this strange computer speak unlike me.
EDITED_BY: Kieron (1132230771)
"I'm quite good at darts, though i often miss" - Kylie
"I'm not a bad driver, I just panic when theres other cars around" - Sarah
SILVER Member
old hand
717 posts
Location: Bristol, England
old hand
717 posts
Location: Bristol, England
Posted:
C# Does require a VM just like Java.
And the pltform independance of .NET stuff is no where near as mature as the Java stuff .NET is really just windows.
Flash is expensive to develop in as the developmnet tools are expensive.
C# Does require a VM just like Java.
And the pltform independance of .NET stuff is no where near as mature as the Java stuff .NET is really just windows.
Flash is expensive to develop in as the developmnet tools are expensive.
"**grumble*spuriouswindmills*grumble**" - Coleman
"if poi was only for girls there wouldnt be many good poi spinners...." - Nx
GOLD Member
the floor is a sea of tigers...
404 posts
the floor is a sea of tigers...
404 posts
Posted:
I might be throwing a wrench into the works here, but I just thought that an alternative to using a USB port to transfer the sequences to the poi, you could maybe have a light sensor/s and use it to capture sequences via flashes on your computer's monitor... In theory, you could also render those flashes out to video and store them on other devices like mobile phones, pdas, etc., etc so you can reprogram your poi while away from a computer. Just a random thought :P
I might be throwing a wrench into the works here, but I just thought that an alternative to using a USB port to transfer the sequences to the poi, you could maybe have a light sensor/s and use it to capture sequences via flashes on your computer's monitor... In theory, you could also render those flashes out to video and store them on other devices like mobile phones, pdas, etc., etc so you can reprogram your poi while away from a computer. Just a random thought :P
GOLD Member
king of the hedgehogs
125 posts
Location: Madtown, USA
king of the hedgehogs
125 posts
Location: Madtown, USA
Posted:
With gjc you are replacing the JRE with libgcj, probably not as painful of a dependency, but a dependency nonetheless... even the "native machine code" will require the proper libraries and cause headaches to those who have little experience with them. Most modern operating systems (i.e., post 2k) have some variety of JRE installed by default, and as long as you are not including the "latest and greatest" bleeding-edge java classes, you can run your code on just about anything. I'm not saying that Java is the way to go - I would personally recommend a ruby/AJAX server-side solution, but I just wanted to put in my 2¢.
Written by: garthy
I don't think the JRE is always needed (https://gcc.gnu.org/java) Although having not played around with this I can really say...
But the Quote "Java source code directly to native machine code," Seems to hint that what I've said above is true!
The problem seems to be that the windowing stuff is unsupported.
With gjc you are replacing the JRE with libgcj, probably not as painful of a dependency, but a dependency nonetheless... even the "native machine code" will require the proper libraries and cause headaches to those who have little experience with them. Most modern operating systems (i.e., post 2k) have some variety of JRE installed by default, and as long as you are not including the "latest and greatest" bleeding-edge java classes, you can run your code on just about anything. I'm not saying that Java is the way to go - I would personally recommend a ruby/AJAX server-side solution, but I just wanted to put in my 2¢.
Yellow and blue make green.
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
Oracle: Yeah, that's been discussed once or twice before. You don't get amazing bitrates (i.e. it could take a few minutes to upload to your poi)... and I'd rather have something faster.
I've managed to simplify things I think by getting around the need for USB - I realised that the chip I'm using to do the USB stuff already has drivers that create a virtual COM port, so on that front, we just need to access a COM port. I've not had much of a play with the USB stuff, but from what I've read, it shouldn't be too tough!
From some stuff garthy mentioned, this is looking like the probable flow:
HyperLight ---> USB Port --> Virtual Com Port --> Commandline App --> Gui interface
I think that's basically the chain. People could either write scripts to run in the command line app, or use the gui we develop, or their own version of the GUI.
I've not got any solid plans for the software interface / gui, but I may well start fleshing out some UML soon. I'd be tempted to stick it on SourceForge for sure as there are a few people interested in this.
H
Oracle: Yeah, that's been discussed once or twice before. You don't get amazing bitrates (i.e. it could take a few minutes to upload to your poi)... and I'd rather have something faster.
I've managed to simplify things I think by getting around the need for USB - I realised that the chip I'm using to do the USB stuff already has drivers that create a virtual COM port, so on that front, we just need to access a COM port. I've not had much of a play with the USB stuff, but from what I've read, it shouldn't be too tough!
From some stuff garthy mentioned, this is looking like the probable flow:
HyperLight ---> USB Port --> Virtual Com Port --> Commandline App --> Gui interface
I think that's basically the chain. People could either write scripts to run in the command line app, or use the gui we develop, or their own version of the GUI.
I've not got any solid plans for the software interface / gui, but I may well start fleshing out some UML soon. I'd be tempted to stick it on SourceForge for sure as there are a few people interested in this.
H
Cake or Death?
GOLD Member
king of the hedgehogs
125 posts
Location: Madtown, USA
king of the hedgehogs
125 posts
Location: Madtown, USA
Posted:
Thinking more about this subject - if you look at what you want to do, it falls into two categories: you have the "processing" bit, and the "communication" widget. If you are wanting a web-based solution, you can handle all the "processing" on the server, and write the code in whatever tickles your techno-fancy. Strapping together a truly cross-platform "communication" widget proves to be a little trickier, but it is still within the realm of doability. The biggest problem that you will run into will be in the way different OS will handle IO, which is daunting at the best of times. Sticking with something that has robust IO libraries will keep you from pulling most of your hair out.
Thinking more about this subject - if you look at what you want to do, it falls into two categories: you have the "processing" bit, and the "communication" widget. If you are wanting a web-based solution, you can handle all the "processing" on the server, and write the code in whatever tickles your techno-fancy. Strapping together a truly cross-platform "communication" widget proves to be a little trickier, but it is still within the realm of doability. The biggest problem that you will run into will be in the way different OS will handle IO, which is daunting at the best of times. Sticking with something that has robust IO libraries will keep you from pulling most of your hair out.
Yellow and blue make green.
BRONZE Member
old hand
1,174 posts
Location: Great Malvern [UK]
old hand
1,174 posts
Location: Great Malvern [UK]
Posted:
I can see what you're saying about the server-side processor, although I'd be keen to keep as much of this as possible away from being purely web-based. That way, anyone without the internet can still use the software and program their poi.
As far as I can see, writing a java app to access the serial port should be relatively simple. For example, check this out. I guess the problem is going to be this:
String defaultPort = "/dev/term/a";
...but how hard can it be to check the system type to change that part? *looks around nervously*
I can see what you're saying about the server-side processor, although I'd be keen to keep as much of this as possible away from being purely web-based. That way, anyone without the internet can still use the software and program their poi.
As far as I can see, writing a java app to access the serial port should be relatively simple. For example, check this out. I guess the problem is going to be this:
String defaultPort = "/dev/term/a";
...but how hard can it be to check the system type to change that part? *looks around nervously*
Cake or Death?
GOLD Member
king of the hedgehogs
125 posts
Location: Madtown, USA
king of the hedgehogs
125 posts
Location: Madtown, USA
Posted:
Sure, if you are willing to go the java route, it's rather trivial to write stuff for IO.
Sure, if you are willing to go the java route, it's rather trivial to write stuff for IO.
Yellow and blue make green.
resident bagpiper
342 posts
Location: Vermont, USA
342 posts
Location: Vermont, USA
Posted:
look, please don't use java. a java GUI always requires the jvm, and never integrate with the os well. I suggest real basic
https://www.realbasic.com/
it is really a good way to compile for multiple platforms.
look, please don't use java. a java GUI always requires the jvm, and never integrate with the os well. I suggest real basic
https://www.realbasic.com/
it is really a good way to compile for multiple platforms.
Q:What's the difference between the Great Highland Bagpipes and the Northumbrian Pipes?
A:The Great Highland Pipes burn longer.
© 1998 - 2024 Home of Poi
All prices converted to United States dollars using XE.com