in firmware or in software?

[casainho]

Hello :-)

Today I were working a bit more on the drivers for DataFlash. I did
understand that DataFlash have a lot of commands and a few
possibilities on each command, which makes a lot of work to make
drivers, implement all commands and possibilities.

I think now that maybe is better to give all control to software for
the hardware, and software will implement all that will be need - not
now I implement all possibilities in firmware that after can simple
not be used on software.

Hardware is very simple, 2 main blocks ICs controlled by SPI, the data
latches and the DataFlash memory. Other device is the sensor hall
effect.

I just need to give control on software of SPI bus + 3 * SS lines +
input from sensor hall effect and finally the control of Vcc of
DataFlash and sensor hall effect.

This all means that we will have almost full control of hardware in
software, the firmware will be simpler. Later I will work more on
software, with Ricardo Lameiro and Herberto.

---
I were with Ricardo Lameiro and borrow him the Olimex development
board w9ith the AT90USB162, so now he can test the communications
between the software and the firmware.

I saw that Herberto did commit some file to SVN server, I think were a
mistake :-)

[kvas_off]

Is there a software-changeable radius of blind zone (distance from
spinning axis to first LED)?

[Casainho]

No, software is in very early stage, as you can see on the SVN server...

[kvas_off]

As I said before (last thing to do :))
I think via my poor mind, there should be a specific bar or box in
software program to manually set the distance between spinning axis
and the nearest LED. That program should actually convert images for
device; otherwise device itself have to 'know' that distance (via
software when is programmed) and then it should know it in specific
units - numbers of distances between nearest LEDs (or it should know
also distance between nearest LEDs itself in millimeters or smth).
I think software image conversion is better for now.

[Jorge Pinto]

Hello :-)

I did read some pages on wikipedia about BMP and bit depth :-)

First, looks to me that using just the "block data - Bitmap data" only
is ok.
http://en.wikipedia.org/wiki/BMP_file_format#Bitmap_data

And I would not used "Indexed color", just "Direct color" - because I am
worried of CPU and memory usage to "decode" the data from the color map,
I don't see any big advantages in using color map on this system.
http://en.wikipedia.org/wiki/Color_depth#Direct_color

So I think hardware should say to software the image bit depth and also
if is monochrome/grayscale or RGB.

Resuming, we would be downloading to hardware a kind of BMP files, of
monochrome/grayscale or RGB colors. This make sense? -- at least for
actual MCU and RAM, I think there will be no problem.

And to this kind of BMP files, we just need to add the frame_time, to be
able to make the animations :-)

What do you think?

[casainho]

> So I think hardware should say to software the image bit depth and also
> if is monochrome/grayscale or RGB.

I were talking with Fernando and I did understand that for grayscale,
8 bits RGB should be used: 3*R + 3*G + 2*B = 8 bits. But MCU have to
compute the values of that bits for a result of an 8 bits grayscale
value.

Well, I know that this idea were already talked:
"I'm thinking I'd rather use those extra bits for more resolution
around the circle. And while its true the current resolution maps
pretty good to the resolution of the 5mm leds, the extra resolution
could be used to modulate the brightness of the image in a similar way
to half-toning like the old black and white MacIntoshes with the
little screen did. So if you quadrupled the resolution you could have
5 brightness levels (grey scale). For example your eye would perceive
a 50% brightness if the LED turned on and off twice in the 5mm
distance the LED would move.

off off off off =0%
on off off off=25%
on off on off=50%
on on on off=75%
on on on on =100%"

So in actual hardware we can maybe try this... don't know If we will
have time and motivation to do that or not, anyway, at least we know
that API is ready for that situation :-)

[kvas_off]

> So I think hardware should say to software the image bit depth and also
> if is monochrome/grayscale or RGB.

I said about this method and its implementation in 'API proposal'
discussion article.

> I were talking with Fernando and I did understand that for grayscale,
> 8 bits RGB should be used: 3*R + 3*G + 2*B = 8 bits. But MCU have to
> compute the values of that bits for a result of an 8 bits grayscale
> value.

o_O, may be you misunderstood... any 8 bits-grayscale image is
grayscale at all, there is no such thing like RGB channels, it's just
shades of brightness, gradations. If you mean method how color
displays show grayscale images (using the same brightness for all
color channels, in theory; a little bit blueish or reddish depending
of used colorspaces in practice) - then it's not about 'monochrome'
BiLEDPOVs; it's only about showing grayscale monochrome images via
'full-color' BiLEDPOVs or via another color displays. On the other
hand, an grayscale image itself can be a channel (R,G or B, or even C,
M or Y) for some color image...

> "I'm thinking I'd rather use those extra bits for more resolution
> around the circle. And while its true the current resolution maps
> pretty good to the resolution of the 5mm leds, the extra resolution
> could be used to modulate the brightness of the image in a similar way
> to half-toning like the old black and white MacIntoshes with the
> little screen did. So if you quadrupled the resolution you could have
> 5 brightness levels (grey scale). For example your eye would perceive
> a 50% brightness if the LED turned on and off twice in the 5mm
> distance the LED would move.

> off off off off =0%
> on off off off=25%
> on off on off=50%
> on on on off=75%
> on on on on =100%"

Well, you're talking about hardware anti-aliasing method (imaginary
upscaling resolution via brightness modulation on the contrasting
edges of objects in an image). Frequencies of PWM blinking should lay
over maximal frequencies of 'LED-pixel changing' in polar co-
ordinates, as you know. Anyway, it's about using some PWM via uC.
Casainho, should hardware inform software about its (HW) internal
picture processing methods? As you said before, "Software don't need
to know how hardware works..." :) Sorry for mailbox-spamming messages,
been training my poor Eng. :(

[casainho]

> > I were talking with Fernando and I did understand that for
grayscale,
> > 8 bits RGB should be used: 3*R + 3*G + 2*B = 8 bits. But MCU have to
> > compute the values of that bits for a result of an 8 bits grayscale
> > value.
>
> o_O, may be you misunderstood... any 8 bits-grayscale image is
> grayscale at all, there is no such thing like RGB channels, it's just
> shades of brightness, gradations. If you mean method how color
> displays show grayscale images (using the same brightness for all
> color channels, in theory; a little bit blueish or reddish depending
> of used colorspaces in practice) - then it's not about 'monochrome'
> BiLEDPOVs; it's only about showing grayscale monochrome images via
> 'full-color' BiLEDPOVs or via another color displays. On the other
> hand, an grayscale image itself can be a channel (R,G or B, or even C,
> M or Y) for some color image...

Well, we can compute a grayscale value using the 8 bits RGB, doing:
grayscale_value = 0.3*R + 0.59*G + 0.11*B

> Well, you're talking about hardware anti-aliasing method (imaginary
> upscaling resolution via brightness modulation on the contrasting
> edges of objects in an image). Frequencies of PWM blinking should lay
> over maximal frequencies of 'LED-pixel changing' in polar co-
> ordinates, as you know. Anyway, it's about using some PWM via uC.
> Casainho, should hardware inform software about its (HW) internal
> picture processing methods? As you said before, "Software don't need
> to know how hardware works..." :) Sorry for mailbox-spamming messages,
> been training my poor Eng. :(

No, we will have in hardware memory just images in RGB.

So, I want to start writing today the API, and use as Fernando
suggested the:

* getSystemInfo - returns API version, firmware version, radials
count, leds per radial, color depth (in bits) and memory size.

Actual hardware will return: 1.0.0; 1.0.0; 256; 32; 1; 1024.

If we had one RGB version, with 3 LED, one for each color and be able
to just turn them on and off, hardware should return: 1.0.0; 1.0.0;
256; 32; 3; 1024.

If we want to implement a kind of grayscale on actual hardware(if
possible ??), hardware should return: 1.0.0; 1.0.0; 256; 32; 8; 1024.

[kvas_off]

> Well, we can compute a grayscale value using the 8 bits RGB, doing:
> grayscale_value = 0.3*R + 0.59*G + 0.11*B

Yes, you can compute it via any PC photoeditor (like photoshop or even
Paint) or via your own software for LEDPOV. I still do not understand
why do you want to make such conversion via microconrtoller, which has
very modest computational abilities.

> No, we will have in hardware memory just images in RGB.

Why do you want to litter memory capacities with RGB images while
you'll be using one-color (even with shades) bicycleLEDPOVs? And why
do you want to force an little defenceless Atmel uController (not
ARM!) to make also color-to-black&white conversion? Why? You can do
all of these things via PC-software. It's better to leave some part of
capabilities and computational powers for future PWM-shades
implementation and so on.

> * getSystemInfo - returns API version, firmware version, radials
> count, leds per radial, color depth (in bits) and memory size.

> Actual hardware will return: 1.0.0; 1.0.0; 256; 32; 1; 1024.

> If we had one RGB version, with 3 LED, one for each color and be able
> to just turn them on and off, hardware should return: 1.0.0; 1.0.0;
> 256; 32; 3; 1024.

> If we want to implement a kind of grayscale on actual hardware(if
> possible ??), hardware should return: 1.0.0; 1.0.0; 256; 32; 8; 1024.

What's 'radial count'? Is it number of 'radial gridlines to blink' or
some counter? I thought that we have 32 'circular gridlines' (due to
32LED-strip) and some programmed in firmware number of 'radial
gridlines to blink', so we have polar grid of pixel co-ordinates.
Software (or firmware) must convert rechtangular Cartesian pixel co-
ordinates to polar ones. If it'll be done by software then we'll have
some specific image dataformat (with polar co-ordinates) to put in
board memory. If it'll be done by firmware, then we could use obvious
BMP image format, but microcontroller itself must make such
conversion. Am I right?
And there is some indeterminedness in 'color depth' value. As you
cited before, you'll can implement some sort of 4-states (2bits) PW-
modulation for gradations
(onononon,ononoffon,onoffonoff,offonoffoff,offoffoffoff). Then it must
be '2' for color depth value, doesn't it? So what will be in value of
this variable if you try to implement some 8-statements (3bits) PWM-
shades? 3? But you already use it for 1bit-3channels RGB boards.

And I already suggested (in 'API proposal') how you can organise
'color depth part' in SystemInfo string to return. (aa,bb,cc,dd,ee) In
some kind of such method it will be determined, it'll have only one
meaning, it'll be good.
And, BTW, where is the information about number of independent LED-
strips (your board have 2 of them, older projects have one or double-
one)? Or, maybe, such info isn't necessary, is it?

Read that wikipediarticle (color depth), I beg you. Sorry for my
importunity.

[Jorge Pinto aka Casainho]

Dom, 2008-09-28 às 07:49 -0700, kvas_off escreveu:
> > Well, we can compute a grayscale value using the 8 bits RGB, doing:
> > grayscale_value = 0.3*R + 0.59*G + 0.11*B
>
> Yes, you can compute it via any PC photoeditor (like photoshop or even
> Paint) or via your own software for LEDPOV. I still do not understand
> why do you want to make such conversion via microconrtoller, which has
> very modest computational abilities.

You are right! Thats no sense to leave that work for MCU. So, maybe one
more field on hardware info to indicate if image is in RGB or grayscale?

> What's 'radial count'? Is it number of 'radial gridlines to blink' or
> some counter? I thought that we have 32 'circular gridlines' (due to
> 32LED-strip) and some programmed in firmware number of 'radial
> gridlines to blink', so we have polar grid of pixel co-ordinates.
> Software (or firmware) must convert rechtangular Cartesian pixel co-
> ordinates to polar ones. If it'll be done by software then we'll have
> some specific image dataformat (with polar co-ordinates) to put in
> board memory. If it'll be done by firmware, then we could use obvious
> BMP image format, but microcontroller itself must make such
> conversion. Am I right?

Let's leave the conversions to polar for software, for the same reasons
you told before.

32 LED strip X 256 radials is our matrix on actual hardware - 32 X 256
bits.

Why not hardware return the number of channels and the number of bits
per channel? - like:
- actual hardware: 1 channel, 1 bit;
- grayscale: 1 channel, 8 bits;
- RGB True color: 3 channels, 24 bits.

> And, BTW, where is the information about number of independent LED-
> strips (your board have 2 of them, older projects have one or double-
> one)? Or, maybe, such info isn't necessary, is it?

Yes, actual hardware have 2 strips of 32 LED.

Ok, one more field for indicating the number of strips. With value 1,
the same image goes to the left and right side of the wheel, with value
2, animation 1 goes to left side and animation 2 goes to right side.
Makes sense?

[kvas_off]

> You are right! Thats no sense to leave that work for MCU. So, maybe one
> more field on hardware info to indicate if image is in RGB or grayscale?

> Why not hardware return the number of channels and the number of bits
> per channel? - like:
> - actual hardware: 1 channel, 1 bit;
> - grayscale: 1 channel, 8 bits;
> - RGB True color: 3 channels, 24 bits.

I suggested in 'API proposal' as this (or something like that):
color depth and organisation field:

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 '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). It determines how exactly bits are
distributed between channels.

> Ok, one more field for indicating the number of strips. With value 1,
> the same image goes to the left and right side of the wheel, with value
> 2, animation 1 goes to left side and animation 2 goes to right side.
> Makes sense?

Yes, it does! :)

[Jorge Pinto aka Casainho]

> getColorInfo: aa,bb,cc,dd,ee

Okok, I think a understand now, except the ee field. Is it really need?
can you give a few examples?

[kvas_off]

> 03,04,05,06,07,08,09,10,11,12,13,14,15,16,24,32 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. :)

When I wrote 09,10,12,13,14,15,16 and higher, I'm joking because these
shade-depthes are used only in HDR-images, high-cost digital image
processors, etc. For grayscale images I only seen 16-bits grayscale -
my scanner can make it, but obvious Photoshop has much more editing
capabilities for obvious 8bits-grayscale images than for this 'HDR'-
grayscale format.

[kvas_off]

> > getColorInfo: aa,bb,cc,dd,ee

> Okok, I think a understand now, except the ee field. Is it really need?
> can you give a few examples?

Well, it's just your beloved 'color depth' value, and checksum, by the
way. Just a summary, 'for great justice' :)

[Jorge Pinto aka Casainho]

> Well, it's just your beloved 'color depth' value, and checksum, by the
> way. Just a summary, 'for great justice' :)

So, it's not a checksum, right? - just the bit color depth?

[kvas_off]

> So, it's not a checksum, right? - just the bit color depth?

Yes, it's just color depth (or grayscale depth for one-color boards),
not circle redundancy check (CRC) or something like that. I just
learned GPS NMEA-0183 protocol and there are some superfluous info
too. You can decide not to use it, of course. I'm glad you get it
right and agreed with my suggestion. :)

[Casainho]

> You can decide not to use it, of course.

I will not use it then, to simplify. Color depth information is also
on filed before.

[Jorge Pinto aka Casainho]

Okok, did wrote the API:
http://code.google.com/p/bicycleledpov/wiki/BicycleLEDPOVAPI

Please everyone verify and say If there is some error or there is
something that should be added.

kvas_off, I did add you as a member, you can now write on wiki pages and
on SVN server :-)

[Fernando Silva]

API version: byte_1; byte_2; byte_3
* can just be a byte (8 bits) for the following: MMMMmmmm where M is
Major and m is minor
we don't need the revision number

Firmware version: byte_4; byte_5; byte_6
* same as above

Number of radial lines: byte_7; byte_8
* why 2 bytes?

Number of LEDs per radial line: byte_9; byte_10
* why 2 bytes?

It's possible to minimize further the bytes returned or accepted by
the functions?

[kvas_off]

> Number of radial lines: byte_7; byte_8
> * why 2 bytes?

Because it can be 256 or higher (it's actually 256 now
)

> Number of LEDs per radial line: byte_9; byte_10
> * why 2 bytes?

The same reason (32 now)

[casainho]

Dom, 2008-09-28 às 20:00 +0100, Fernando Silva escreveu:
API version: byte_1; byte_2; byte_3
> * can just be a byte (8 bits) for the following: MMMMmmmm where M is
> Major and m is minor
> we don't need the revision number

okok.

> Firmware version: byte_4; byte_5; byte_6
> * same as above
>
> Number of radial lines: byte_7; byte_8
> * why 2 bytes?
>
> Number of LEDs per radial line: byte_9; byte_10
> * why 2 bytes?> >

Because I am thinking as kvas, with 1 byte we get an image of maximum
256x256, we need more for future.

And all this bytes are not expressive in memory usage and processing
power.

[casainho]

Updated the API.

Saw that kvas also did help on API wiki page :-)

[kvas_off]

BicycleLEDPOVAPI fixed a little bit. (a little bit more)
Casainho, if you would be a little bit more attentive, I could
understand much more... :)
0-4-4 in bytes is 1028 in decimals, actually. And you have 'radials
from 0 to 255, i.e. 256 in decimals = 1-0 in bytes.

[kvas_off]

Jorge, actually my last name is Kvasoff, by the way ;)

BTW, it's more likely to use just two hexadecimal digits for byte
values. To non-confused interpretation.

[Jorge Pinto aka Casainho]

I did write "[0] [255]", which means 256, counting with 0, until 255.

Kavsoff, do you have experiency with AVR? Will you help on firmare? ;-)

[kvas_off]

Jorge Pinto aka Casainho:

> I did write "[0] [255]", which means 256, counting with 0, until 255.
> Kavsoff, do you have experiency with AVR? Will you help on firmare? ;-)

Pnito, you wrote in wiki ' 255 radial lines ' as byte value
explanation, instead of 256 which you actually have :)
Well, what can I say about the question? I have two of them (ATMega8 &
ATMega16). That's all :) Also I learned assembler' codes for PIC-micro
midrange 8-bit microcontrollers and I have a lot of them. :) And I
studied MSP430 (texas instruments) programming with assembler codes
and some C (via IAR) in university, only one semester. So what can I
do ( the last phrase sounds like Russian ' I'll find some vodka ' ) :)

[kvas_off]

*Kvasoff
*Pinto
btw, zero means zero as natural number in all scales of notation; or
when you write '0' you automatically means it for '1'? weird... 8-0

[Jorge Pinto aka Casainho]

Dom, 2008-09-28 às 13:53 -0700, kvas_off escreveu:
> Jorge Pinto aka Casainho:
> > I did write "[0] [255]", which means 256, counting with 0, until 255.
> > Kavsoff, do you have experiency with AVR? Will you help on firmare? ;-)
>
> Pnito, you wrote in wiki ' 255 radial lines ' as byte value
> explanation, instead of 256 which you actually have :)

Eheh, okok :-)

> Well, what can I say about the question? I have two of them (ATMega8 &
> ATMega16). That's all :) Also I learned assembler' codes for PIC-micro
> midrange 8-bit microcontrollers and I have a lot of them. :) And I
> studied MSP430 (texas instruments) programming with assembler codes
> and some C (via IAR) in university, only one semester. So what can I
> do ( the last phrase sounds like Russian ' I'll find some vodka ' ) :)

Well, you may did read the Firmware page already, and firmware have two
different parts.

First we must implement the API and after the POV. API is already +-
implemented, is structured now - If you want, you can help in implement
the base API (is the must urgent to do).

It should be difficult to work without hardware ;-) - unfortunally, I
don't have any PCB... I was also waiting to next version of hardware to
make one or two more PCBs.

Don't know if you are familiar with the GCC-AVR and AVR-Libc... you
know, they are very good and Free Software ;-) -- not as IAR ;-)

[Jorge Pinto aka Casainho]

> btw, zero means zero as natural number in all scales of notation; or
> when you write '0' you automatically means it for '1'? weird... 8-0

0001 0000 -> version 1.0, eheh, should be value 16 ;-)

[kvas_off]

> Don't know if you are familiar with the GCC-AVR and AVR-Libc... you
> know, they are very good and Free Software ;-) -- not as IAR ;-)

Don't worry, I used licensed IAR - in our Electronics Department. :)
Btw, I heard some controvercy about GCC compiler "it'snotabug-
it'safeature"s (oddities) & bugs in interrupt handler with function
recalls...
But many people use it due to freeware... Generated codes are less
dense than generated by licensed software (Keil or smth.) But, again,
money for license...

[Jorge Pinto aka Casainho]

> But many people use it due to freeware...

Much more than freeware ;-)

> Generated codes are less
> dense than generated by licensed software (Keil or smth.) But, again,
> money for license...

Atmel have some workers working activly on GCC-AVR and AVR-Libc :-) And
I use this tools on my daily work, doing products with LEDs for
automobile industry ;-) - well, also we do some projects on renewable
energies :-)

[kvas_off]

> Ok, one more field for indicating the number of strips. With value 1,
> the same image goes to the left and right side of the wheel, with value
> 2, animation 1 goes to left side and animation 2 goes to right side.
> Makes sense?

Well, I don't understand... Are we talking about design specific
information or about programmable function of board?
If my first version is right, then all older PCB designes from another
projects could be used with your API (with alternative firmware, of
course), but they generally have double-one strip of LEDs, so on one
side of wheel image will be mirrored (unless difficult "anti-mirror"
PCB-tracing will be implemented). Your project board with two
independent LED strips will be able to show equal-and-not-mirrored
images on both sides, or equal-but-one-mirrored images, or different
images, right or left - whatever you want and programmed (or set via
software in uC). But anyway your board design should return "2" value
because it has 2 independent strips. When you'll produce some reduced
board revisions (for bicycles with big disk brakes, for example)
without second strip, they have to return "1" value.
I think so.

> 0001 0000 -> version 1.0, eheh, should be value 16 ;-)

Yes, actually it should. Why are you limit yourself and other
developers with 255 (or even less) values of versions instead of the
whole variety of BiLEDPOV species? Why don't you use the golden mean,
the happy medium: not 1 byte, nor 3 bytes but 2 of them for each value
of versions?

[Fernando Silva]

There is only one value that the software will ever need to check to
adapt itself to the connected hardware. And that value is the returned
API version, for which a limit of 1 byte is enough.

When we are talking about the firmware, it's version is firmware
"type" dependent and it has only some meaning to the hardware where
that specific firmware is implemented. And that means, that 1byte is
also enough for versioning that firmware. I don't think someone will
develop more than 16 major versions of a firmware so quickly... and if
that happens, someone needs some lessons about defining versions to
software.

[kvas_off]

About general API: should hardware tell software what is the start
address of its memory?

[kvas_off]

> There is only one value that the software will ever need to check to
> adapt itself to the connected hardware. And that value is the returned
> API version, for which a limit of 1 byte is enough.
>
> When we are talking about the firmware, it's version is firmware
> "type" dependent and it has only some meaning to the hardware where
> that specific firmware is implemented. And that means, that 1byte is
> also enough for versioning that firmware. I don't think someone will
> develop more than 16 major versions of a firmware so quickly... and if
> that happens, someone needs some lessons about defining versions to
> software.

Reasonable enough. But we're defining a GREAT STANDARD here and you
just come and bring us back to Earth to little uControllers and simple
"blinky-shiny" devices... :) Our API is maked for years, for ages! :)

[Jorge Pinto aka Casainho]

> I don't think someone will
> develop more than 16 major versions of a firmware so quickly...

And If some others projects start using the same software, to program
matrix LEDs? 16 diferent hardwares is very few...

1 byte here just represents 0,00006 % of total memory of actual MCU (16kB) - we don't need to save them.

>

[Fernando Silva]

hmmmm... 0000:0000?

[Fernando Silva]

Windows - 20 years - 5 major versions
Linux - 15 years - 2 major versions

I don't recall of any kind of software with more than 16 major versions...

[Jorge Pinto aka Casainho]

Dom, 2008-09-28 às 16:14 -0700, kvas_off escreveu:
> About general API: should hardware tell software what is the start
> address of its memory?

I think no, the beguinning is always 0. And the end is the size of
memory.

[Fernando Silva]

If other projects start using the same software and API, they will
have for each project the same version but within different projects.

project X - version 1.0 - API 1.0
project Y - version 1.0 - API 1.0

For the software we don't need to understand the firmware/hardware
version, just the API.

But if you want to show information about the hardware and firmware
itself, go ahead and put the option with and array of several bytes to
return a string saying "MY KINKY PROJECT" and then it's version 1.0!

[Jorge Pinto aka Casainho]

My question is with extended API, which will be different for each
hardware...

How can we do for that? I belive that 16 is not enought...

[kvas_off]

> My question is with extended API, which will be different for each
> hardware...
> How can we do for that? I belive that 16 is not enought...

> > If other projects start using the same software and API, they will
> > have for each project the same version but within different projects.
> >
> > project X - version 1.0 - API 1.0
> > project Y - version 1.0 - API 1.0
> >
> > For the software we don't need to understand the firmware/hardware
> > version, just the API.
> >
> > But if you want to show information about the hardware and firmware
> > itself, go ahead and put the option with and array of several bytes to
> > return a string saying "MY KINKY PROJECT" and then it's version 1.0!

Funny :) I think this is a reasonable, fundamental conversation about
nothing. You can chose whatever you want.
Everything will be right, some advises will be even more righter, even
righteous. Let's work on, let's try to solve the problems.

[casainho]

Fernando, base API shouldn't change for almost hardwares, but extended
API should!! 16 different versions of hardware is not to much, even
for a few POVs that are already on Internet.

How software should know about different extended API?

[Fernando Silva]

If you refer to "software" as the main application developed by this
project, the answer is: it doesn't know there is an extended API.

Only developers that do a extended firmware, will have tools to access
that. More, we are documenting the extended API, but it should be in a
specific page to not be confused as a "standard" API for the project.

[Casainho]

> If you refer to "software" as the main application developed by this
> project, the answer is: it doesn't know there is an extended API.
>
> Only developers that do a extended firmware, will have tools to access
> that.

So, for each different hardware, with different extended API,
developers should add the extended API functionalities to software?
Isn't there a better way, like we are trying to do with base API?

> More, we are documenting the extended API, but it should be in a
> specific page to not be confused as a "standard" API for the project.

Okok, when I will have free time I will separate the information in two pages.

[Fernando Silva]

Think a bit...

A developer does a new firmware with a complete new set of functions,
with special commands, special arguments, special return values... how
could a software even imagine what to do? Unless it's a special
software already knowing it...

[Casainho]

> A developer does a new firmware with a complete new set of functions,
> with special commands, special arguments, special return values... how
> could a software even imagine what to do? Unless it's a special
> software already knowing it...

Okok - so implementing extended API on firmware and software must be
done for the same developers that builds a new hardware.

I remember you saying something about hardware returning information
to software about commands on extended API - maybe I misunderstood.

Okok - this week I will be working on firmware, implementing the API
that we defined on this last days.

[Fernando Silva]

Yes. The base API can have a return value saying that the firmware
implements an extended API.
But that's all it can do!

[Casainho]

> Yes. The base API can have a return value saying that the firmware
> implements an extended API.

Ok, did that: http://code.google.com/p/bicycleledpov/wiki/BicycleLEDPOVAPI

I added 2 bytes, so we can have 2^16 numbers of different hardwares,
each one with his own extended API.

Extended API page is here:
http://code.google.com/p/bicycleledpov/wiki/BicycleLEDPOVExtendedAPI