New API proposal
casainho
In sequence of my last message, I want to suggest the follow hardware
API - software can control hardware by:
Hardware: - 1 command to read hardware version.
Sensor hall effect: - 1 command to read it's state.
LEDs: - 1 command to set the state of LEDs.
Memory (be it EEPROM, DataFlash or other) : - 1 command to read byte;
1 command to write byte.
I would remove actual "dummy command" since "hardware version" command
can be used for the same purpose.
Since this project is DIY and hack friendly, I feel the need to have
more control on hardware, so users can debug his hardware when
building it! For example, I want to be able to turn high or low level
each data line and probe with a voltmeter.
Also DataFlash memory can send more information about itself, as model
and size, so, more commands are need to do that. I think in a kind of
subset commands for sensor and memory. This subset commands do not
need to be implemented by all hardware, they are like hardware
dependent.
I would like to receive suggestions. Thank you :-)
casainho
In last days I had being working with Fernando on the API and on the
memory organization.
Today there were a few new ideas about API: hardware should return his
version and also the number of LEDs, number of radial lines, number of
colors and bits per color.
Looks a lot of information, but this will permit the software be the
same for a lot of hardwares, with diferent number of LEDs, colors and
shadows or composite colors - should work perfectly with RGB POV, be
it with only 1 bit per color or 8, 16, 24 or 32 bit colors!!!
Actual V1.0 hardware is one color and 1 bit per that color.
We also were talking about memory organization... and we decided that
at the beguining of the memory will be a flexible size table,
indication the start and the end of each animation, so, the number of
animations are limited by memory size only. User will be able to jump
over animations pressing button SW1.
Each frame of the animation have 3 bytes for indication the time of
the frame.
I may be missing something that we had being talking -- in next days I
will write and work in API and memory organization wiki pages :-)
Does anyone read about "Peggy, A Light Emitting Pegboard Display"??
goes in my mind that this software and hardware can be used to make
derived works like Peggy (matrix LED display) or other kind of
POVs :-)
http://www.evilmadscientist.com/article.php/peggy
kvas_off
1 bit codes 2 states: presence and absence of one colour. So,
technically, it's 2 colours which are coded by 1 bit. So if you use 3
boards with different (R, G and B) LEDs, you can already have 8
colours (2 colour states per channel)
So, API should return info not only about 1 or 8 bits per colour (or
per channel), but also about 2bit/channel(64 colours), 3 (512), 4
(4,096), 5 (32,768), 6 (262,144), 7 (2,097,152) or 8b/channel
(16,777,216 colours). There could be variations in different colour
spaces: 65536 colours (5bits-R, 6bits-G, 5bits-B 16bits HighColor
colour space)
24bit colour image has 8bits (1 byte) per channel, as you know. I
didn't hear anything about 32bit images, I heard only about 24bit-
images, which are used with additional 8bits alpha-channel for
transparency purposes and other transitions in 32bits-colour spaces.
And I heard about 48-bits- and 96-bits HDR images (with 16 and 32 bits
(2 and 4 bytes) per channel, respectively; but do you really want to
beat plasma industry and make an HDR display-on-wheel? :))
16bits-colour spaces use different coding formats.
VERY INTERESTING and useful article: http://en.wikipedia.org/wiki/Color_depth
kvas_off
changed by uController after each round of wheel, for example, and
looped. (running animals, etc.) The easiest way - to make a little
displacement of one picture elements' output after each round (slowly
spinning images, inscriptions)
Or do you dare to use any video formats? :)
Casainho
>
> Easy way to make animated images - to use just an image sequence,
> changed by uController after each round of wheel, for example, and
> looped. (running animals, etc.) The easiest way - to make a little
> displacement of one picture elements' output after each round (slowly
> spinning images, inscriptions)
I did wrote a wiki page about my toughts:
http://code.google.com/p/bicycleledpov/wiki/MemoryOrganization
But yesterday I agree with Fernando to do like this: Initial table on
memory have the position of START and END of animation on the memory.
Each position, frame, have the time that will be displayed and the
data, so, MCU will just show frame_data and wait the frame_time before
jumps to next frame.
This make sense??
About colors, I am a bit loose... eheh :-)
kvassoff, what do you think that hardware should report, using the
API?? the size of the matrix, number of channels and bits per channel?
Casainho
Eheh -- just put raw data on memory, so an MCU like this one with 512
RAM bytes can use it.
To use video, I would use some hardware with Linux, to be able to read
all kind of video codecs and data images.
Ricardo Lameiro
maybe will need to shift the direction of software dev, I am just an
amateur and I dont have the skills or the time to learn them, so we
should start to search someone to do this. Maybe Fernando is a god
choice, I wouldn't mind if the software uses the mono platform, I
believe that in mono would be very cross-platform friendly. say your
thoughts about this.
2008/9/24 Casainho <casa...@gmail.com>:
--
Fagote / Contrafagote
Bassoon / Contra-bassoon
http://myspace.com/ricardolameiro
Jorge Pinto
> I should war that for all of this
Sorry, didn't understand that - my poor understand of english.
> we need to have an strong software,
> maybe will need to shift the direction of software dev, I am just an
> amateur and I dont have the skills or the time to learn them, so we
> should start to search someone to do this. Maybe Fernando is a god
> choice, I wouldn't mind if the software uses the mono platform, I
> believe that in mono would be very cross-platform friendly. say your
> thoughts about this.
Fernando can help on software and he will work with tools that he is
motivated to work with. But for sure that is some Open Source programing
language and development tools, also the software will be available with
some Open Source license.
For now, it's very important to work on API and memory organization, so
anyone can do a software program implementing that API and memory
organization. The same on hardware firmware.
Ricardo, you can always continue to working on software and using the
BRANCH directory on SVN, and let's learning with all of our
knowledge!! :-)
I hope to stay with Fernando next saturday and write on paper the API
and memory organization, after I will put it on wiki to see if there is
some other ideas, some errors, something missing.
I am still waiting for kvas_off ideas.
Ricardo Lameiro
>Sorry, didn't understand that - my poor understand of english.
When I was reading an idea came to me about software/hardware, maybe
you could debate this with Fernando. The idea is to develop, in first
place, a device driver for the hardware, a kind of library that
abstracts the hardware completely from the software, so it is easier
to a person who doesn't have hardware knowledge to develop software
for the device. Something like a driver that implements all the
possible operations of the device. This will enhance the device to be
used for other purposes other than the bicycleledpov.
This is only an idea, I don't know if it is interesting or not, but
could have some benefits maybe making this device a kind of arduino of
leds :).
2008/9/24 Jorge Pinto <casa...@gmail.com>:
DZiems
on, maybe we should focus on getting the core functionality down,
since I don't think one of these boards has produced an image yet.
On Sep 24, 4:02 pm, "Ricardo Lameiro" <ricardolame...@gmail.com>
wrote:
> >Sorry, didn't understand that - my poor understand of english.
>
> sorry my fault, I wanted to say "warn",.
>
> When I was reading an idea came to me about software/hardware, maybe
> you could debate this with Fernando. The idea is to develop, in first
> place, a device driver for the hardware, a kind of library that
> abstracts the hardware completely from the software, so it is easier
> to a person who doesn't have hardware knowledge to develop software
> for the device. Something like a driver that implements all the
> possible operations of the device. This will enhance the device to be
> used for other purposes other than the bicycleledpov.
> This is only an idea, I don't know if it is interesting or not, but
> could have some benefits maybe making this device a kind of arduino of
> leds :).
>
Fernando Silva
As I discussed with Jorge, we need to have an API that should have 2
goals: be simple and flexible. As all you know if we implement
something simple it will have some ground to grow in the future.
So, Jorge, please finish the API spec and forget that non sense of
having "everything" in the first version of this software.
Resuming:
* getSystemInfo - returns API version, firmware version, radials
count, leds per radial, color depth (in bits) and memory size
* readByte - reads one byte from the memory
* writeByte - writes one byte into the memory
And this is enough to implement something!
Regards,
Jorge Pinto
> Resuming:
> * getSystemInfo - returns API version, firmware version, radials
> count, leds per radial, color depth (in bits) and memory size
Okok, I can now start writing but I have one question: color depth, what
is in actual hardware? and what would be in an RGB hardware with 3 leds,
one R, other G and other B, with just turning ON and OFF each LED?
DZiems
available. There are two methods of doing RGB, and the two methods
are incompatible software wise by my estimations. Its good that you
are ambitious and want to get RGB done right away, but lets get
monochromatic done first, RGB will be an easy scale-up from there.
DZiems
> There are two methods of doing RGB, and the two methods
> are incompatible software wise by my estimations.
use to do RGB, and until we decide on which one to go with, there is
no sense in coding for it yet, because we may choose an RGB method
incompatible with the current code..
Fernando Silva
That means, that we need to return a byte with the number of bits
supported. In this case, it will return "1" and it's with that value
that we will work.
In the future, it can return any other value (eg. 8, 16, 24, 32) that
we will then think how we will implement.
Casainho
Fernando tolds me that do not want to make various versions of
software, just one to work with one API.
To say the true, I also feel the same when thinking in coding again
API changes on firmware... I would prefer now to work on API, thinking
very well it and after just do one more time firmware for it.
Although there may be different ways to make hardware for RGB, there
is no problem because hardware and firmware can adapt for the API!!
Also I understand that the way to go is having information on memory
as If it was an image file, or at least, software will work like
that...
Fernando, so:
> In the future, it can return any other value (eg. 8, 16, 24, 32) that
> we will then think how we will implement.
If I wanted to make one RGB hardware, with 8 bits of data for each R,
G and B colors,
* getSystemInfo - returns API version, firmware version, radials
count, leds per radial, color depth (in bits) and memory size
getSystemInfo could return:
API version - 1.0.0
Firmware version - 1.0.0
Radials count - 256
Leds per radial - 32
Color depth - 24 (8 bits for R + 8 bits for G + 8 bits for B)
Memory size - 1024 (kB)
And If RGB but with just ON/OFF each R,G, and B LED:
getSystemInfo could return:
Color depth - 1 ???
How can we know if hardware uses 1 bit color depth for just one color
LED (like actual hardware) or uses 1 bit color for 3 color LEDs?
Fernando Silva
just like that... the system tells us how many bits (colors) it
support, and the software give the color encoded for that. The rest is
up to the hardware.
kvas_off
Part about color (in systemInfo to return) could be like this:
getColorInfo: aa,bb,cc,dd,ee
where:
aa - number of bits per channel for "monochrome"
boards (00 for future "full-color" boards; 01 for 'monochrome' boards
without PWM or other modulation; 02 or
03,04,05,06,07,08,09,10,11,12,13,14,15,16,24,32 for for 'monochrome'
boards with PWM or smth);
bb,cc,dd - numbers of bits/R, bits/G and bits per B,
respectively, for "full-color" boards (00 for each value for
'monochrome' ones; 01 or
02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,24,32 for 'full-color'
ones);
ee - summary of four preceding values; for 'full-
color' boards it means color-depth in bits, for 'monochrome' ones it
means gradation-depth in bits. And, btw, it's just a checksum. :)
Why 3 values for each channel? Because there are different color
depthes: there are two 'Highcolors', for example: RGB555 (32768
colors) and RGB565 (65536 colors).
As I said, you can already have 3bits color depth with 8 colours via 3
'monochrome' 'one-bit' bicycleLEDPOVs (take an image, extract channels
from it, downgrade each channel to 1 bit (black or white) and insert
them into uC memory in 3 some SpokePOVs or smth else. In our project
software can automatically split image to channels)
As I said before, VERY INTERESTING and useful article:
http://en.wikipedia.org/wiki/Color_depth
Please, do not call cathode-tube TV set or DLP-projector - "POV".
Though, actually, they are. :)
Casainho
Software don't need to know how hardware works...
Maybe is just putting an image file like .BMP on memory, MCU after
have to decode the image before putting it on LEDs.... BUT, this MCU
have just 512 bytes RAM (the same RAM shared for USB, etc). Also MCU
is speed is very low, 8MHz, to read memory data, decode it and send to
SPI BUS for the LEDS, and use data from sensor hall effect to
calculate time frame....
I remember Fernando talking about using .BMP or ICOn files...
> As I said before, VERY INTERESTING and useful article:
> http://en.wikipedia.org/wiki/Color_depth
I need to find some free time to read it :-)
kvas_off
least, what kind of HW it should work with? :)
> Maybe is just putting an image file like .BMP on memory, MCU after
> have to decode the image before putting it on LEDs.... BUT, this MCU
> have just 512 bytes RAM (the same RAM shared for USB, etc). Also MCU
> is speed is very low, 8MHz, to read memory data, decode it and send to
> SPI BUS for the LEDS, and use data from sensor hall effect to
> calculate time frame....
some ARM or smth.
> I remember Fernando talking about using .BMP or ICOn files...
direct read.
But now I suggest software conversion to 'internal data format' before
put image into board (uC) memory, as many do nowadays.
3 boards and 3 one-channel pictures OR one 3-color board and 3
'simultaneously' showed 1bit- 1channel- images - and you have 8 colors
for everything (lifestyle purposes, advertisement purposes, riding
across city streets, money, money, money <lol>). :)