--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.
sampling" and "Parallel synchronous I/O" with clocked input, but I
feel like they can both allow fun stuffs to be made :o) ).
I understood we already had OpenAccessory support, but I may be
wrong...
Other things I think would be nice to have (I can live without them,
but feel free to vote for them if you need them):
- Step motors driving
- Matrix keyboard reading
- Matricial led output (not sure of the name, but basically I'd like
to be able to control 64 leds using 16 binary outputs without having
to manually handle them)
PS:I am not sure the last one is possible (can the PIC do multi
thread?)
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/dQ5BrUQKcUQJ.
+android-scripting
I'm happy to accept patches for SL4A support. I unfortunately don't
have time to spend implementing it myself.
Damon
> +android-scripting
>
> I'm happy to accept patches for SL4A support. I unfortunately don't
> have time to spend implementing it myself.
>
> Damon
>
> On Sun, Aug 7, 2011 at 8:25 AM, Ytai Ben-Tsvi<yta...@gmail.com> wrote:
Any Android >1.5 is good.
But you will probably need a IOIO (unless you want to build a wrapper around a library that you won't be able to use...)
I can't offer you a IOIO (since I'll be paying for it just like everyone else), but you can win eternal glory, for which $50 are really a small price to pay :D
Great news. We'll keep in touch then!
OK, by "clocked" you mean "with a clock pin", not with a timer
trigger :o).
Yes. I thought multi thread because if we want the leds to look like
> > Other things I think would be nice to have (I can live without them,
> > but feel free to vote for them if you need them):
> > - Step motors driving
> > - Matrix keyboard reading
> > - Matricial led output (not sure of the name, but basically I'd like
> > to be able to control 64 leds using 16 binary outputs without having
> > to manually handle them)
> > PS:I am not sure the last one is possible (can the PIC do multi
> > thread?)
>
> All are great ideas! Not sure why multithreading is needed here: IIUC, you
> mean connecting the 64-LED to 8 anode and 8 cathode busses in a row-column
> setup and then quickly scanning (effectively achieving 1/8 power to each
> LED).
they're lit all the time, we need to turn them on/off all the time,
but I guess you may include this to the micro-controler's main loop
(if there is such a thing... sorry if I say stupid things here but I
am not very experienced in micro-controlers (yet)).
I don't see why transistors are needed here but I'll try to understand
> You'd also need transistors on each row-column, or else you'd need to
> really choke the current. Is that what you meant? But by all means, this is
> a cool feature to add, i.e. implement the scanning and switching on the
> IOIO-side, where the Android side just says "I want these LED on now".
it before I burn my IOIO :o)
About the matrix input keyboard, I was thinking to some instruction
that will hang until a key is pressed of a timeout occurs and return
the pressed key code, but if you can manage the leds output matrix in
continue, perhaps you can use some extra cycles to continually scan
the keyboard and allow reading them in a buffered way?
If wishes season is still open, it would be nice to add RC5 protocol
support (both for emission and reception).
Bit banging scripts should allow it but if we can go native.
Eric
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
Right now I don't have any other project, I just love new challanges and
playing with gadgets, I'm one of the core Py4A developers, and I think
I'm the only EE there, so I think I could be the guy to do it.
> I hate when money is an issue stopping a great project (even though
> the whole point of hacking IS to do with re-cycled and cheap stuff...
> lol...)
Yes money is an issue of course, also is time. As I said next month I'm
starting an internship in the US 'til end December, so that means I will
not have much time. But on the other hand is cheaper and easier for me
to ask sparkfun for a board once I'm there.
> If you have a good idea about an interesting project, then send me
> your address and I'll post you a IOIO board.
I can give you my US address as soon as I have it
Stupid question, I haven't investigated the IOIO board much, it's not
like the Arduino where you change the firmware on the fly keeping the
bootloader right? Specially what I mean is, do you write Java code to
modify the firmware? Because if that's the case, I don't think it would
make non developers life easier, and the project might not make sense at
all (still like the challenge).
Manuel
Stupid question, I haven't investigated the IOIO board much, it's not like the Arduino where you change the firmware on the fly keeping the bootloader right? Specially what I mean is, do you write Java code to modify the firmware? Because if that's the case, I don't think it would make non developers life easier, and the project might not make sense at all (still like the challenge).
Another wish - porting of the IOIO API to desktop Java
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/nsc0S3d2124J.
Got it. Great!
--mark
> --
> You received this message because you are subscribed to the Google Groups "ioio-users" group.
> To post to this group, send email to ioio-...@googlegroups.com.
> To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.
>
>
--
do interesting things.
(You know, with an outboard FPGA it could do software radio too...)
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/qKu8tB_3TycJ.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.
Am 28.12.2011 17:42, schrieb kiz:
> The IOIO Manager should present a summary of the application and
> bootloader on any IOIO board. This could be done at the startup, or
> via a menu item. --
> You received this message because you are subscribed to the Google
> Groups "ioio-users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/ioio-users/-/EaOZP8pAkXkJ.
That's a very good point!
Include a function in IOIO Manager to report Hardware ID, Bootloader ID and Firmware ID, and some other interesting info which might be available on the IOIO.
Am 28.12.2011 17:42, schrieb kiz:
The IOIO Manager should present a summary of the application and bootloader on any IOIO board. This could be done at the startup, or via a menu item. --
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/EaOZP8pAkXkJ.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+unsubscribe@googlegroups.com.
This functionality can be achieved by using SPI (with an additional pin for latch if you will, or a falling edge trigger on the SS pin). The feature labelled parallel synchronous io above is a natural extension that would also support this use case (at slower rates probably, SPI can work at up to 8MHz).
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/BZ38lTxtPSQJ.
To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
If it isn't already supported (my IOIO is actually in the mail on the way to my house) I'd like to see support for HD44780 parallel LCD interface or TTL for a serial interface LCD. The project I have in mind requires an onboard display.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/eeNytsm7014J.
Won't you achieve this by wiring rx and tx together, running tx in open drain and use an external pull up to 5v?
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/zRemEUn5_QoJ.
I agree...that should do it...
So have you taken into account the .write buffer length can be part of the total .getMinBufferSize length?
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/ILJqxUHiHkcJ.
This sounds more an issue of including some facility in the firmware so that the API can support ADDITION of external chips to the IOIO at sufficient bandwidths. No offense to anyone, but I dont think there should be hardware addition to the IOIO...it narrows the device flexibility for other subject-specific-applications. The simplicity and adaptability of the IOIO is what will distinguish it against Apple et al.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/e4G0YvtkZsUJ.
We can extend a IOIOLib for adding a functionality the API not offered, some useful resource is remained on the IOIO. Building the source is troublesome though.
If the MCU dose not have the virtual memory, it may be difficult to modularize and pluggable like IOIO Manager does. So how about writing a documentation for extend the IOIOLib and reserve the protocol number for it.
You may be right that there should be no hardware addition to the IOIO. I don't want to offend anyone too, but thinking about it, what's needed is a product, a kind of "Android USB soundcard" that works right out of the box, not some do it yourself hardware (though that's much fun too). That "soundcard" could be based on the IOIO design or something different. I probably should try to find somebody who could help me to build and sell such a product.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/_tslBxl5GnEJ.
I may be that somebody ;)
You may be right that there should be no hardware addition to the IOIO. I don't want to offend anyone too, but thinking about it, what's needed is a product, a kind of "Android USB soundcard" that works right out of the box, not some do it yourself hardware (though that's much fun too). That "soundcard" could be based on the IOIO design or something different. I probably should try to find somebody who could help me to build and sell such a product.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/_tslBxl5GnEJ.
great stuff! An external hi-fi, low-latency sound card for Android is definitely something I would buy.
Even more so, if it had a midi in/out and an audio in/out and software for a synth, a guitar effect rack, a multichannel recorder, a sequencer, etc.
Something along the lines of Amplitube for iPhone.
Allow me to focus the discussion a bit. The goal of this thread was to figure our which features would make IOIO a better product. Making a specific product based on IOIO is out of scope and I'm really hoping that this is something other people will do by leveraging the existing IOIO software.
In the context of audio that's been discussed above, the missing bit in IOIO is not a DAC but rather the API that will enable you to stream data out in a precise rate with high throughput and low latency.
We're talking about 1.5Mbit/sec or so, which should be doable.
What kind of interface would you like to see on the DAC side? SPI? Parallel synchronous? Something else?
I send you a mail.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/blUR-mCYHxkJ.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/Z9ILNqqYW8wJ.
This is hard coded in the firmware. You can change it and rebuild the firmware.
how to change the BlueTooth 4545 PASSCODE to my own/different passcode ?
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/ZIdyxVVxreEJ.
Just use easylogger from sparkfun...
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
http://www.bluegiga.com/BLED112_Bluetooth_low_energy_dongle
http://www.amazon.com/Medialink-USB-Bluetooth-Adapter-Technology/dp/B004LNXO28/ref=pd_cp_e_0
Dear users,I'd really like to spend my development efforts on things that people are actually going to use. So I'm starting this thread to figure out what features people would like to see in the next versions. Your votes will help me prioritize. Thanks in advance for your ongoing support!I'm providing my own list - everyone is encouraged to add more items and/or to vote on items proposed by others:
- Capacitive sensing - for easy connection of capacitive sensors.
- PPM output - for connecting to a transmitter and controlling existing R/C toys.
- IOIO over Bluetooth - support connecting a Bluetooth dongle to the IOIO USB jack and controlling it wirelessly using the exact same API. Will require a bootloader upgrade.
- IOIO over OpenAccessory - use OpenAccessory (like ADK) as the underlying connection. Will improve latency and throughput. Possibly will not be 100% robust like the current version as result of OpenAccessory flaws. Will require a bootloader upgrade.
- Parallel synchronous I/O - support clocked input / output using multiple pins in parallel.
- Periodic digital sampling - obtaining precisely timed digital signals (e.g. for implementing a logic analyzer).
- Bit-banging API - an advanced mode in which users will be able to write short scripts to run on the IOIO-side, which implement arbitrary protocols.
- Increase analog sampling rate - expose an API for controlling the analog sampling rate (currently @1KHz / channel).
- QEI - for communicating with quadrature encoders. Perhaps with a simpler mode for using unidirectional encoders.
>>> I think there are several things called one-wire. Can you point me to a specific spec or device?
http://www.maxim-ic.com/products/1-wire/
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/8ogcHRcaMIMJ.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/oMBmfYRuBYoJ.
I may just not know how to do it, but it would be nice to be able to set (and reset when needed) values for the pins which the device could reset to in the event of a lost connection. This is probably more of an issue with the bluetooth dongles than the direct USB connection, but losing a connection can make an ioiobot run away from you.
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/kVT6zhbUi5UJ.
now that USB Bluetooth Support is working great, i would like to wish
IOIO support to USB Wifi Dongle and USB Modem. (preferably HUAWEI Usb
Modems)
Connecting USB Modem to IOIO will give IOIO connection to Android
device over Internet. that would be a break through. :-)
Simpler wish would be 1-wire interface for devices such as
DS18B20. :-)
thanks
You know that Bluetooth and Accessory have been supported for quite a while, don't you?
PIC24H doesn't have USB OTG if I remember correctly.
+1 to IOIO over Bluetooth.
+1 to IOIO over OpenAccessory
New versions may incorporate a pic 24H.???
High performance 12-bit ADC ...
I am very interested in your work, congratulations ...
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/Kh97xQVEWLoJ.
Are you serious?
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/2upuGW3smJoJ.
Make pins configurable as input or output
I'm sorry. I don't understand what is the feature you are talking about exactly...
--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/-xU8jMCJrxYJ.
I'm sorry. I don't understand what is the feature you are talking about exactly...