New times for Bicycle LED POV
casainho
Recently I am being working with a small company that wants to make
some products for bicycles, but just a few prototypes.
Included projects are:
- http://www.opensprints.org
- Pedal Power Generators
- Bicycle LED POV
While Bicycle LED POV is not done, we may use the SpokePOV.
O next times I will be without working at my company so I will be
looking for another job and I may have free time to invest again on
this project.
I am being thinking a few times about the functionalities and I would
like to have an hardware that when connected to PC by USB would be
like a USB Storage Device and that the DataFlash memory would be read
and write as if it was a USB Flash disk. On that way the system could
read .bmp files from the FAT32 file system on the DataFlash and put
them on the LEDs :-)
I am being learning a lot on the past months, I am being using ARM7.
My last finished project with ARM7 is this one:
http://code.google.com/p/casainho-projects/wiki/PedalPowerMeter
I must design another board, with the same track size as AVRopendous,
I even know the shop where AVRopendous boars were done, we just can
use the same shop and have good looking board: http://code.google.com/p/avropendous/
I would like to use the A91SAM7S128, that works as USB device, have
128K flash memory and 32K ram. The 128k flash memory should be enough
for hold the code for the FAT32 + USB device + POV. The 32k ram should
be enough to hold the FAT32 and the 32x32 matrix of data of the BMP
file, I hope.
That A91SAM7S128 costs 5,07€ for 25 units, on mouser:
http://pt.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMvu0Nwh4cA1wUVlLgw9m2DPOAuN%2fkRafsE%3d
Could we build all the hardware for 35€ unit?
Kvassov Neakolai
Everything sounds just fine except one thing.
I doubt you'll can possibly implement FAT32 in your ARM's 32K RAM.
Just because the very block of FAT32 is 32K long, respectively. But
may I wrong?
Btw, why not FAT16 (just FAT)? - all flash drives have it.
Sincerely yours,
kvassoff
Ricardo Lameiro
because everyone speaaks of fat 32.... :)
2009/7/24 Kvassov Neakolai <kvas...@gmail.com>:
Fagote / Contrafagote
Bassoon / Contra-bassoon
http://myspace.com/ricardolameiro
Casainho
Lameiro<ricardo...@gmail.com> wrote:
>
> I think that Casainho wanted to say FAT16, Maybe it was a mistake,
> because everyone speaaks of fat 32.... :)
>
> 2009/7/24 Kvassov Neakolai <kvas...@gmail.com>:
>>
>> Hi there!
>> Everything sounds just fine except one thing.
>> I doubt you'll can possibly implement FAT32 in your ARM's 32K RAM.
>> Just because the very block of FAT32 is 32K long, respectively. But
>> may I wrong?
>> Btw, why not FAT16 (just FAT)? - all flash drives have it.
Ok :-)
I will discover... but after reading the pages of FatFS, memory usage
table (http://elm-chan.org/fsw/ff/en/appnote.html), I believe that
memory on AT91SAM7S128, the 32Kbytes RAM, will be more than ok. We can
also use instead the AT91SAM7S256 (because have the same pinout) with
64Kbytes RAM but a bit more expensive.
Right now I am start using the FatFS library for a project that I want
to finish before start working again on Bicyckle LED POV. The project
is "SD Card Bathroom Scale" and I am using an ARM7 LPC2103 from NXP
Philips with 8 KBytes of RAM, so, I will discover if FatFS is ok :-)
http://code.google.com/p/casainho-projects/wiki/SdCardBathroomScale
Casainho
> Hi there!
> Everything sounds just fine except one thing.
> I doubt you'll can possibly implement FAT32 in your ARM's 32K RAM.
> Just because the very block of FAT32 is 32K long, respectively. But
> may I wrong?
Card Bathroom Scale" project, where I write on a SD Card my weight. I
am using the full FatFs library* on an Philips NXP ARM7 LPC2103 with
32kbytes flash and 8kbytes ram memories.
Here is the report I get when linking:
arm-elf-objdump -x --syms main.out > main.dmp
arm-elf-size main.out
text data bss dec hex filename
27132 1 36 27169 6a21 main.out
So, about 27kbytes of flash used. 1 byte for RAM?? (this value should
be wrong). 36 bytes for initialized vars.
So, I will use for sure the FatFs library on Bicycle LED POV next
version :-)
* http://elm-chan.org/fsw/ff/00index_e.html
> Btw, why not FAT16 (just FAT)? - all flash drives have it.
about patents of FAT... FatFs library mounts FAT12, 16 and 32, and can
use long names.
Kvassov Neakolai
So, I will use for sure the FatFs library on Bicycle LED POV next
version :-)
So I was wrong - and that's good too in our case. :-)
> Btw, why not FAT16 (just FAT)? - all flash drives have it.
Is there any library EXT2 or any other Open File System? I don't know
about patents of FAT... FatFs library mounts FAT12, 16 and 32, and can
use long names.
Casainho
About the ARM MCU to use, I am not really sure that AT91SAM7 is the
best option now, because I believe that Opendous will make soon a
board using another ARM, from NXP Phillips, an ARM Cortex M3 which is
more cheap than AT91SAM7 about 3€ or more. Also if we use the same ARM
MCU, we can reuse the schematic, PCB footprints and part list from
ARMopendous, since it is an Open Hardware project :-)
ARM Cortex is more recent technology than ARM7, which is cheaper and
should use less energy also.
I also believe that we can get direct help from Matt (Opendous) - he
is being help me about others projects.
About the LED, I am being thinking in making the hardware more simple,
with just maybe 24 LED for each side and the same image for both sides
of the wheel, so it can be saved 5 ICs for driving LED - using just 3
ICs instead of 8. 3 ICs can drive 8 * 3 = 24 LEDs.
Jorge Pinto aka Casainho
Since batteries should on the new design be separated from the main
board with LED, why not put with the batteries the main controller of
the system, and just use LED strips? -- like system being 2 parts, part
1: 3 X AAA batteries; part 2: LED strip with sensor hall effect.
The connections between both parts would be:
pin 1: GND
pin 2: Vcc (3 X 1,2(5)V = 3,6(4,5)V
pin 3: SPI Clock
pin 4: SPI Data Out
pin 5: Enable
pin 6: Sensor Hall Effect signal
The Sensor Hall Effect signal would be optional to be on the LED strip
or not, it could be attached with 2 wires (GND + sensor signal) and be
placed on some other part of the wheel.
The advantages on this idea? -- using LED strips of many flavors we can
find now on market. We could just sell the controller and hope that
users make their own LED strips. Also on one wheel there can be many
strips, not like other POVs that if we want 3 POV for each wheel we
should have 3 controllers.
Even there is RGB LED strips which I would like to find a cheap and
buy... because they are digital control. See this project:
http://hackaday.com/2009/06/17/addressable-rgb-led-strip/
Here is one manual of one RGB LED strip:
Casainho
The files are on SVN, directory V2.0.
Probably I will not use the ARM7 AT91SAM7Sxxx, instead the ARM Cortex-
M3 from NXP Phillips, just because is a more recent, cheap, powerful
technology AND there is the Open Hardware boards from
"Cortopendous" (well, they should be available in 1 month or a bit
later, schematic sources are already available, using KiCAD).
I will try to make a prototype of Bicycle LED POV V2.0 using
Cortopendous boards + a strip of LEDs (including the serial shift
register and the sensor hall effect). Later will be easy to make the
final boards since the source files for KiCAD are available :-) :-)
And recently, I assembly an OpenSprints hardware (http://
opensprints.org/) for the Bicycle Film Festival to happen on Lisbon
(Portugal) next month. I had to use magnets and sensor hall effect :-)
Also I had recently a great experience (http://code.google.com/p/
casainho-projects/wiki/SdCardBathroomScale) with an FAT library for
microcontrollers, I will use it for making the Bicycle LED POV V2.0
work as an USB pen flash.
Also, this week I got my first digital oscilloscope, a 50MHz,
1Gsamples, 2 channels, for 300€ :-) I am building a little hardware
lab at my house :-)