Rockbox Player - Project to design and build a Free/Open hardware audio player

[casainho]

Missing is a slide switch for lock.

Okok, I will not assume lock needs in this version in the dev. board. Next version, lets discuss this with guys from Olimex, we can suggest interesting hardware as sliding circle for volume/navigation, as in Sansa or Ipods.

So, 8 buttons, there is no need to calculate another values from this example: http://www.scienceprog.com/interface-multiple-keys-with-one-wire-and-save-pins-of-mcu/ , is just use it! :-) however, It looks like to me that with that technique we can't know what buttons are pressed simultaneous :-( , I don't know if this is a problem... I will try to listen other opinions about this and I identified 8 free I/O pins on MCU and expansion connectors, that can be used for the buttons.

[toffe]

For the remote, take example on the one of the gigabeat, the schematic is here :
http://www.rockbox.org/twiki/bin/viewfile/Main/GigabeatInfo?rev=1;filename=remote_control_gigabeat_F.pdf
I can send you the Kicad file if you want..
I f I didn't make any error on the tracing  

[casainho]

For the remote, take example on the one of the gigabeat, the schematic is here :
http://www.rockbox.org/twiki/bin/viewfile/Main/GigabeatInfo?rev=1;filename=remote_control_gigabeat_F.pdf
I can send you the Kicad file if you want..
I f I didn't make any error on the tracing  

Thank you for sharing :-)

On IRC:
- I am studding a way to link 8 buttons to a MCU... and I have the possibility of use just 1 wire to connect the 8 buttons signals to MCU, however this technique doesn't allow to detect simultaneous buttons press... is important for RB software to detect simultaneous buttons? - 4 direction buttons (up/down/left/right), select, menu, play/pause and stop. Up and down buttons typical acts as volume up and down.
- It's not very important, but often useful.
- I don't think it's necessary to be able to detect each button individually. A few independent groups already help a lot
- As mentioned, it's not only the extremes which are possible. Among the rockbox targets we have a lot of variants ranging from each button connected individually (e.g. archos player), to all buttons connected via one wire except power (e.g. iaudio X5, M5)

I will use 8 wires, for simplicity at understand the hardware and have the possibility to know each individual button press :-) - I will start right now draw the schematic :-)

[linuxstb]

Regarding buttons, you may want to look at the keymap definitions for the various targets in apps/keymaps/ - lines such as BUTTON_ON|BUTTON_UP indicate a button combination that the hardware allows.

The keymap_h1x0_h3x0.c and keymap_gigabeat.c are probably most useful to you, as they have a similar number of buttons as your proposed device.

(note that BUTTON_REL and BUTTON_REPEAT aren't real buttons, they're used to indicate release and repeat events respectively).

[casainho]

Regarding buttons, you may want to look at the keymap definitions for the various targets in apps/keymaps/ - lines such as BUTTON_ON|BUTTON_UP indicate a button combination that the hardware allows.

The keymap_h1x0_h3x0.c and keymap_gigabeat.c are probably most useful to you, as they have a similar number of buttons as your proposed device.

(note that BUTTON_REL and BUTTON_REPEAT aren't real buttons, they're used to indicate release and repeat events respectively).

I wrote this information on TWiki page ;-) Thanks.

Hardware is now defined!! Now I will wait some days for any suggestions or bugs. After I will put a list o material , international sites to buy it online and prices. And after I will ask at company were I work to make some units of the secondary board which I will be able to send by mail to developers that ask for it - assembled board.

I got today another positive answer from one second company, from http://www.in-circuit.de/ , to produce the Rockbox Player :-) I answered that now we are developing a prototype using a developing board and in the end we will contact them.

Very nice because the person told me: "That would be great, full open source mp3 player. From schematic till the firmware and perhaps the songs :-)" and which I replied: "Software/firmware are GPL2, hardware will have somekind of GPL license and there are a lot of music with Creative Commons licenses, as in www.Jamendo.com, with + than 6600 albums, with an actual medium grow rate of 14 albums by day :-)"

[spark]

hi people,

lots of development happened since i last wrote. i have a few suggestions

keyboard interface
8 lines for 8 keys is too much of wiring. since we already have I2C running to the expansion board it would make sense to use a an I2C I/O expander with interrupt support for keys.
e.g. PCA8574 for 8 I/O lines or PCA8575 for 16 I/O lines
PCA8574 -> http://www.rockbox.org/twiki/bin/viewfile/Main/RockboxPlayerV1?rev=1;filename=PCF8574_4.pdf
PCA8575 -> http://www.rockbox.org/twiki/bin/viewfile/Main/RockboxPlayerV1?rev=1;filename=PCF8575_3.pdf

power on/off logic
We need to add a separate power on button that controls power ON logic of power supply.

LCD interface
there should be an I/O line to control LCD backlight. If we use carrier board we have only one 3.3V supply line for both backlight and logic. This means that we will have to switch this supply line on/off to save power. LCD will have to be re-initialized on each power off/on cycle.
we can use a P-channel MOSFET to control LCD power.
again the above I2C i/o expander can be used for LCD power line (i.e. gate of P-channel switch).

anybody knows how much current the LCD module needs? i guess we can safely use a 500mA power switch.

[casainho]

Spark, I wrote on TWiki the objectives for this V1 and the planing future versions. I hope they make sense, more or less.

keyboard interface
8 lines for 8 keys is too much of wiring.

Adding another IC seems unnecessary to me, since we have free I/O lines on MCU (with pull-ups).

LCD interface
This means that we will have to switch this supply line on/off to save power.

There in no need to save power, we are using a dev board. Future circuit on V2 can be totally different in question of this LCD and power circuit.

Your concerns looks like more for the V2 and not for this V1. If we go with Olimex for V2, looks like they will not need our help to design the circuit, however we will have to control that! On that time, I think that this ideas you wrote, can be worked, but not in this V1.

Look, I asked you in past to make a planing, you didn't and I had free time and I am being working on the project, I made the planing, contacts, and defined some simple hardware, I hope all this make sense and are ok.....

[spark]

Casainho, i was tied up with something and could not write anything this week.

my concerns were for a basic player.

there should be a way to turn off LCD backlight if there is no user activity for certain time. (irrespective if we power from mains or battery). This functionality can be added by using a transistor (less than $0.5).

while development you should have free i/o lines. you never know when you would need them. the I2C i/o expander is a standard chip for less than $1.5

since we are already making an expansion board, i don't think adding these 2 chips is gonna cost a lot.

dev board
Casainho, did you get a user guide with the dev board? can you please upload it for us?
how does it bootload? u-boot in flash?
what if u-boot is erased? how do we recover a virgin board?

[casainho]

there should be a way to turn off LCD backlight if there is no user activity for certain time. (irrespective if we power from mains or battery). This functionality can be added by using a transistor (less than $0.5).

But If we will use this prototype just to show Rockbox working, we don't need all the little things. If we add that functions in hardware, they will also must be done in software, and for V1 there is no need, V1 will be just a straightforward version in terms of hardware + software.
I don't pretend to perfect all software for this V1, since just the developers will use this V1. And we have a lot of working ahead to do, in software!! 

while development you should have free i/o lines. you never know when you would need them. the I2C i/o expander is a standard chip for less than $1.5

Thats right, we can use this dev board for future development of another hardware, but, I am not seeing that possibility in a short time, because we already have all that we need in the board! There is no software in Rockbox for any other fancy hardware...
Even If we change the hardware a bit, we can draw a total new version of this secondary board.

since we are already making an expansion board, i don't think adding these 2 chips is gonna cost a lot.

It's not a question of price for me, It's just I think we don't need or will need them, thinking in make a simple demo of this player, I think in simplifying the hardware + software + documentation + BOM, we will win time and this 2 things will change for sure quickly in the next version V2, they are just temporary.

dev board
Casainho, did you get a user guide with the dev board? can you please upload it for us?

No, but looking at others manuals from Olimex, that manual should just be important for install Linux on the board, IMO. So I am not worried with that, since we have all information, all datasheets :-)

[Bagder]

there should be a way to turn off LCD backlight if there is no user activity for certain time. (irrespective if we power from mains or battery). This functionality can be added by using a transistor (less than $0.5).

This sort of stuff is already done by Rockbox. No need to do anything about it hw-wise really.

what if u-boot is erased? how do we recover a virgin board?

The at91 chips are easily bootstrapped over serial (or usb I believe) even when nothing at all is in flash.

[casainho]

there should be a way to turn off LCD backlight if there is no user activity for certain time. (irrespective if we power from mains or battery). This functionality can be added by using a transistor (less than $0.5).

This sort of stuff is already done by Rockbox. No need to do anything about it hw-wise really.

Software can't control the energy in this hardware: http://www.sparkfun.com/datasheets/LCD/ColorLCD-Carrier-Schematic.pdf

And since we are talking about this, for V2 I would like to have PWM control for this back light of the LCD, so we can make a fade in/out. Also the same for every LED :-)

I know that actual MCU don't have PWM channels, but on V2 we can change to the AT91SAM9RL64, which have PWM and USB full speed.

what if u-boot is erased? how do we recover a virgin board?

The at91 chips are easily bootstrapped over serial (or usb I believe) even when nothing at all is in flash.

Well, I bought the JTAG cable, I think that we can program all with JTAG. I bought mine in SparkFun at the same time I bought the LCD carrier board. http://www.sparkfun.com/commerce/product_info.php?products_id=275
There is other alternative, the USBprog :-) - http://www.embedded-projects.net/index.php?page_id=165
I believe that It can be also bootstraped by JTAG :-) - I don't have any experience with JTAG or 32 bits, ARM, MCUs. I just read a lot about them :-)

Text taken from datasheet:
AT91SAM9260 Boot Program

The Boot Program integrates different programs permitting download and/or upload into the dif-
ferent memories of the product.

First, it initializes the Debug Unit serial port (DBGU) and the USB Device Port.

Then the DataFlash Boot program is executed. It looks for a sequence of eight valid ARM excep-
tion vectors in a DataFlash connected to the SPI. All these vectors must be B-branch or LDR
load register instructions except for the sixth vector. This vector is used to store the size of the
image to download.

If a valid sequence is found, code is downloaded into the internal SRAM. This is followed by a
remap and a jump to the first address of the SRAM.
If no valid ARM vector sequence is found, the DataFlash Boot program is executed on the sec-
ond chip select.

If no valid ARM vector sequence is found, NAND Flash Boot program is then executed.
The NAND Flash Boot program looks for a sequence of eight valid ARM exception vectors. If
such a sequence is found, code is downloaded into the internal SRAM. This is followed by a
remap and a jump to the first address of the SRAM.

If no valid ARM vector sequence is found, SAM-BA Boot is then executed. It waits for transac-
tions either on the USB device, or on the DBGU serial port.

[Bagder]

Software can't control the energy in this hardware

Are you saying that the software can't switch the backlight on/off ?

[casainho]

Software can't control the energy in this hardware

Are you saying that the software can't switch the backlight on/off ?

Yes, I was. Sorry, I should be objective. Software can't switch backlight on/off because this hardware don't do that on/off: http://www.sparkfun.com/datasheets/LCD/ColorLCD-Carrier-Schematic.pdf

[spark]

Thats why i said we should send 3.3V power to the LCD through a MOSFET switch with its gate connected to the I/O line of the uC. With this way we can swith on/off the LCD through software.
since both backlight and LCD logic are powered off, we will have to re-initialize the LCD on each power cycle.

V1 and V2
we cannot call a dev board + expansion board as a V1. that is just an eval platform.
A V1 needs to have its own board and we should be developing it, here in the wiki and forum.
if Olimex (or other vendor) is interested in developing the board, we should invite their engineers to join the forum and give their inputs. we do not want them to develop the board in their closed rooms. that looses the essence of open source development.

[casainho]

V1 and V2
we cannot call a dev board + expansion board as a V1. that is just an eval platform.

Okok, someone already told that :-) - I feel the need to document all hardware + software of the dev board + expansion board and for that I will need to have a TWiki page, and for that I need to give a version to that, It can be V0.1, maybe, no? - remember that MCU will be the same to others future versions. - what can be the version name for this first prototype - including hardware + software?

A V1 needs to have its own board and we should be developing it, here in the wiki and forum.

Right, but there is a good option in the table now, we don't need to go for all the work, time and money consuming, we have a company that can do that for us, a company that have people with experience in that, from design, to choose good, available in market, components, and assembly.

The company here I work, design hardware is strong connected with shop section of the company and assembly section, because It can't be totally separated processes.

if Olimex (or other vendor) is interested in developing the board, we should invite their engineers to join the forum and give their inputs. we do not want them to develop the board in their closed rooms. that looses the essence of open source development.

I already invited for that, but they have no time for this, they are busy with theirs "normal" work! Also I remember Bagder told: don't put your hopes to a company doing this settle for a hw design and use that build-your-own style prove that the design works and that there's working software should put yourself in a better position when trying to convince companies...
So I feel very luck in have this 2 positive answers from the only 2 companies that I contacted!! I am sure they believe in the project, not only, because Rockbox already works in many hardwares, have a lot of good features and there are a lot of happy people!! Thanks to developers

About Olimex or other company develop board in close, that is no problem to me, If they give full schematics and use ICs approved by us. If we look at their dev boards, we know all, we have schematics and the place of components in the board. If company draw the board for them assembly it, let It stay with them if they do not want release it public. We having the schematics, we can then draw the board using our Free Software programs. If Another company wants to make also the board, they can design for them selfs or use our design in KiCad.

About Olimex, even If we don't have their engineers here, we have schematics of their boards, we can reuse their schematics knowing that they have knowledge about that and it works...
When they suggested "AT91SAM9260 + LCD NOKIA 6610 + 8MB flash + 8/16MB SDRAM + nRF24L01 wireless chip + audio CODEC + Li-ion battery + charger + miniUSB + buttons", I didn't mention wireless nor battery, they just suggested that, so I assume that after we show prototype working on that Olimex dev board, we can say what we need and they can tailor a schematic for us and after we can approve it or say the necessary changes.
They have a board with an TFT LCD 3.5" 320x240 pixels with TOUCH SCREEN, they have boards with Ethernet and wireless... what can we need more? :-)

Spark, thinking like this, I don't need to have in the dev and external boards, hardware to switch on/off the back light of the LCD or others things, that can be defined for the next board. And we can just say that in text and engineers from Olimex will draw that, just If we will not be satisfied with result, we can than design as we want/need.

And we should control the quality of the hardware, to have a good sound quality as possible. Thats an advantage that this player can have, I remember to read on wikipedia page about the Ipod, that are models that have bad sound quality, because of cheap hardware. My daily work is also, at the end of the prototype, find smaller values of capacitors, inductors, etc, to reduce the price of the system!

This are my ideas.

EDIT: We can start defining, writing, what hardware we want in V1 (can be a audio player and recorder)! For example, I tough in one version for a flash player and another for a HD player, but now I think It can be possible have pcb with an SD card connector for having a flash player and a connector for an HD. People that want use an HD, just connect it on the board. Looks like there are a lot of people here at RB that likes to have a portable player with 250GB.