Raspy Juice Expansion Board:


25 posts
by Adnan » Fri Mar 30, 2012 6:05 am
Hi people,

Like most of us, I'm still impatiently waiting for my Raspberry Pi. I've ordered mine after the launch sold-out date and I suspect it will come even later. I'm really waiting for two things: my RasPi, and my self-designed expansion PCB blanks, which I call Raspy Juice.

The main features of the Raspy Juice expansion board are:


  • 6-20V input to 5V 3A buck regulator

  • RS232 level translator, with a 2.5mm stereo connector (self-requirement)

  • RTC based on PCF8523

  • Small


Whilst designing the above, the PCB initially "looked" sparse, so I added some secondary features: an ATmega168A expansion micro-controller connected to the I2C and supposed to control:


  • 4-channel RC servo interface (PC0, PC1, PC2, PC3)

  • RS485 interface (USART0, must be bit-accurate to 115200,8N1)

  • RS232 interface (software-based UART, mainly at 9600,8N1)


(The above last two interfaces are meant for other simple robotics expansion boards, not "industrial-strength" stuff).

My projects wish-list for this RasPi and Raspy-Juice combination are for:


  1. Replace my aging Gumstix Overo-Tobi home server with RasPi and 2 attached USB HDD. With 3A, I think the Raspy-Juice will have enough power, but I may have to circumvent RasPi's USB port fuses.

  2. Build a battery-powered, smallish and almost headless demonstration gadget with RC servos attached.

  3. Help someone else build her moving paper mache "Eye of Sauron" project with a webcam. (The webcam part was my idea 8-).


My micro-controller programming skills aren't bad, but not great either. I know I can get blinking-LED, servo movement and eventually, serial interfaces working through userspace I2C read-writes. But I have my sights on something more like PyMCU (or really, just a small subset will do).

Is there anyone interested in such a expansino board? I can hope to assemble additional prototypes (when the blanks finally arrive and working to some extent, that is) if there is some interest… (If there's too much interest, however, I'll have to put it up on a webshop :-) .

Downsides of my design:


  • Probably I can't test the hardware completely, because I've no actual RasPi.

  • Probably I can't write I2C code properly, because I've no actual RasPi. (Starting to rant).

  • It's also too bad that the PCB is so small, that I had to sacrifice convenient MCU programmability through RasPi's SPI pins (routing constraints). The only way to program the MCU is one would've to own an AVR 6-pin programmer.

  • And then there's the danger of bricking the AVR should some incorrect fuse programming is performed. There's no way to recover from this, apart from re-soldering the DFN chip (hard, hard, hard ;-().

  • At worst, we're left with just a PSU regulator PCB (and that is, if it even works. No PCB's, unbuilt and untested as yet).


Any interest?
Posts: 12
Joined: Sun Mar 04, 2012 1:12 am
by mole125 » Fri Mar 30, 2012 7:34 am
I don't know much about AVR (mostly been looking at Pic instead), but assuming they are self programmable, can't you use the I2C from the RPi as the protocol to program it? If the standard bootloaders are designed for SPI then it may need a bit of tweaking but I would have thought it was possible?

My main question is what do you see as the main differences between your board and Gert's board?
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm
by 6677 » Fri Mar 30, 2012 8:13 am
It was my understanding in another topic (under the features section of the forum) that the i2C interface isn't present on the GPIO strip for the production boards
Posts: 382
Joined: Wed Mar 14, 2012 9:23 pm
by jamesh » Fri Mar 30, 2012 9:00 am
I2S is the problem, not I2C

James
Volunteer at the Raspberry Pi Foundation, helper at Picademy September, October, November 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12375
Joined: Sat Jul 30, 2011 7:41 pm
by Mattylad » Fri Mar 30, 2012 12:45 pm
Anyone find it ironic that several expansion boards are available before the actual pi is.....
Posts: 98
Joined: Tue Jan 17, 2012 9:59 pm
by RaTTuS » Fri Mar 30, 2012 12:56 pm
Mattylad said:


Anyone find it ironic that several expansion boards are available before the actual pi is.....


they don't have to get CE tested and none are actually available yet
http://www.catb.org/esr/faqs/smart-questions.html <- ask smart Questions
"That's not right, the badgers have moved the goalposts."
1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX - Prosliver FTW
User avatar
Posts: 5628
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
by Mattylad » Fri Mar 30, 2012 12:59 pm
Had someone thought of compliance when they were developing the pi and had it tested before it was decided to release so many then there would not be this hiccup.

Looking at the above pic, it looks ready and if it is manufactured for sale it also needs compliance testing.
Posts: 98
Joined: Tue Jan 17, 2012 9:59 pm
by jamesh » Fri Mar 30, 2012 1:15 pm
Mattylad said:


Had someone thought of compliance when they were developing the pi and had it tested before it was decided to release so many then there would not be this hiccup.

Looking at the above pic, it looks ready and if it is manufactured for sale it also needs compliance testing.


Yes.There are a number of explanations already posted - in comments, in forum and on the front page as to why this problem has occurred now.
Volunteer at the Raspberry Pi Foundation, helper at Picademy September, October, November 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12375
Joined: Sat Jul 30, 2011 7:41 pm
by hzrnbgy » Fri Mar 30, 2012 1:19 pm
Mattylad said:


they don't have to get CE tested and none are actually available yet


I had one prototyped ages ago. Good thing is, it has a built in MCU so RPi not required. Its a GPS add-on board.

Posts: 106
Joined: Mon Dec 26, 2011 10:55 pm
by Adnan » Fri Mar 30, 2012 1:51 pm
6677 said:


It was my understanding in another topic (under the features section of the forum) that the i2C interface isn't present on the GPIO strip for the production boards



Hi 6677, James:

Thanks for note on deprecation of I2S, not I2C -- for a moment my heart skipped a beat.
Posts: 12
Joined: Sun Mar 04, 2012 1:12 am
by gordon@drogon.net » Fri Mar 30, 2012 2:20 pm
Adnan said:



  • Probably I can"t test the hardware completely, because I"ve no actual RasPi.

  • Probably I can"t write I2C code properly, because I"ve no actual RasPi. (Starting to rant).

  • It"s also too bad that the PCB is so small, that I had to sacrifice convenient MCU programmability through RasPi"s SPI pins (routing constraints). The only way to program the MCU is one would"ve to own an AVR 6-pin programmer.

  • And then there"s the danger of bricking the AVR should some incorrect fuse programming is performed. There"s no way to recover from this, apart from re-soldering the DFN chip (hard, hard, hard ;-().

  • At worst, we"re left with just a PSU regulator PCB (and that is, if it even works. No PCB"s, unbuilt and untested as yet).


Any interest?



Hm.

You can get a parallel programming cable that connects a PCs parallel port to the 6-pin progrmaming interface on the AVR chips - or make one - I made my own and use avrdude to program up chips. Or you can buy the ATmega chips pre-programmed with the Arduino bootloader for a fiver from (e.g.) coolcomponents. 1000's of Arduino programmers seems to get on OK with this and bricking is rare. I once thought I'd bricked a chip, but managed to recover it via the parallel programmer. The Arduino bootloader lets you program them via the serial port and if that's connected to the R-Pi, then off you go.

But... What are you achieving? If you want an AVR chip on a board then buy an Arduino. Same price as the R-Pi and (IMO) a lot more versatile when it comes to interfacing and real-time control.

Back to the R-Pi - I think what might be better is a BUFFERED I/O board with (optional) (ie. via jumpers) D/A and A/D on-board. A bit like HALF of the Gertboard. Provide the board with drivers capable of driving a relay or directly driving LEDs. The hard part is working out what the pins are set to from the GPIO side of things - as they can be set to input or output via software, and connecting an output buffer to a pin set for input mode isn't going to get you anywhere - I envisage a bank of 2-way jumpers to connect a GPIO pin to an output buffer or an input buffer - inelegant, but if it saves you blowing up the R-Pi then so much the better.

However I suspect that the cost of such a buffer board is going to be on-par with the cost of an R-Pi, so you might as well consider them disposable - as people will try to connect the GPIO up to motors, and inapropriate sensors (eg. ones running at 5 volts not 3.3)

What I have done recently is connect my Linux host to an Arduino using the serial (USB) line (something I'm pretty sure I 'll be able to do on the Gert board) Not sure what it will achieve on the Gertboard though, other than adding to the quantity of IO avalable.

From what I can gather (wiki) The GPIO has:

I2C (aka TWI, 2 wire interface - Linux driver unwritten AIUI) - 2 pins.

Serial (Standard Linux driver present) - 2 pins

SPI (or 4-wire bus - No driver yet? ever?) 5 pins (odd as the SPI spec only needs 4)

That leaves 8 pins of general purpose IO.

No worse than the Beeb's "user port" :-)

So maybe what's needed is some sort of modular system - a base to connect the R-Pi to and that base buffers signals, provides small ribbon cable connectors to connect up other boards - e.g. relay boards, motor boards, switch input boards and so on. You'll need to be clever at signal multiplexing to use the 8 IO pins, OR you abandon them and use the serial or I2C interface to a microcontroller and it's then the microcontroller thats doing the real IO. But if you're doing that, then just use the microcontroller in the first place - especially for proper real-time control which is never going to be able to be realised on the R-Pi.

I'm now thinking it's a real anomaly (the GPIO port!) - and wondering if it would have been better off with no IO at all... But then the Beeb had the User port which I used for a variety of stuff, and I also used the printer port (output only, but it was buffered!) and the lesser used "1MHz Bus".

Hm. It's really got me thinking now ... A modular base with a variety of IO and modules to connect into it... That's appealing... I'm thinking of using the 8 GPIO pins to drive nothing more than 8 LEDs - debugging, then use serial (or i2c when avalable) to talk to the base controller which does the hard work of interfacing to the hardware. But maybe that's what the Gertboard already does!

But it'll just look like another Arduino clone...

Ah well...

G
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1544
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by Adnan » Fri Mar 30, 2012 2:45 pm
mole125 said:

My main question is what do you see as the main differences between your board and Gert's board?

Hi mole125:

Thanks for the tip of using I2C as a bootloader protocol for re-programmability. It's do-able, but it'd take me weeks of development and testing to make it "safe". But I will try.

As to your question of main differences between Juice and Gert boards: I hadn't really thought of that.

The main reason I designed Juice was to supply ample power efficiently from a wide-VIN range because I use a common cheap-to-obtain 12V adapter. Also, Juice was to provide myself a convenient RS232 port (via the 2.5mm stereo jack) for me to play with bootloader options, root-level logins, etc. My past toying with beagleboards, overo's and other eval boards (even at work) all had this "fix". I find eval boards requiring exactly +5V restrictive, and I've lost boards before. Thankfully, +5V microUSB is now here and RasPi's use-model of that is effective.

Everything else on Juice came as an afterthought and I jammed in whatever I thought would be "fun-to-have". (Except the RTC). Call it free-style bottom-up PCB-to-electronics design if you like.

Main differences of Gertboard and Juice: (uhhhhhhh - I'm really making these up)


  1. Juice can't be a manually-solderable kit except for its header. It has SMT components too difficult to solder without good practice. Gertboard can be used for a more hands-on approach.

  2. RasPi and Juice combo is self-contained and may run off batteries efficiently.

  3. Personally, I was hoping to jam the RasPi and Juice combo into an enclosure designed by others in this forum and exposing only the RC servo ports which could make it safer for less experienced teachers/users/youngsters. Maybe other people want to do similarly.

  4. The caveat above is that it closes off RasPi's GPIO header expandability unless the user is an advanced electronics experimenter.

  5. Juice has no firm firmware plans yet! I don't even know how this could play out except supply me a good +5V 3A output.


(Now that I think of the RC servo control, I forgot that most meccano/robotics projects need some form of inputs which Juice's exposed ports doesn't provide).
Posts: 12
Joined: Sun Mar 04, 2012 1:12 am
by arm2 » Sun Apr 01, 2012 8:44 pm
RaTTuS said:


Mattylad said:


Anyone find it ironic that several expansion boards are available before the actual pi is.....


they don't have to get CE tested and none are actually available yet



Correct they don't need CE testing, available now? Well I've got hundreds of PCBs for our RTC (Some fully assembled) the problems is that until I can get one tested in a R-Pi it would be foolish to sell them, oh and I can't get them tested until someone writes the I2C driver :-(
Posts: 246
Joined: Thu Dec 15, 2011 3:46 pm
by Adnan » Sun Apr 01, 2012 9:28 pm
arm2 said:

... that until I can get one tested in a R-Pi it would be foolish to sell them, oh and I can't get them tested until someone writes the I2C driver :-(

Hi arm2,

(it's really really early in the morning here -- couldn't sleep well).

Juice RTC is going to use NXP's PCF8523, a fairly new chip. What chip does your PCB use?

a. Juice's RTC is so new that the driver probably isn't in the upstream kernels yet. Looks like Juice will remain a prototype for a long,long time until until the PCF8523 driver becomes prevalent in the distribution.

b. How do I find out which kernel version RasPi distributions are using? Try as I might, I couldn't find any references to it. (Looks like I've to download a distribution and untar it).
Posts: 12
Joined: Sun Mar 04, 2012 1:12 am
by hzrnbgy » Mon Apr 02, 2012 7:09 am

Juice's RTC is so new that the driver probably isn't in the upstream kernels yet. Looks like Juice will remain a prototype for a long,long time until until the PCF8523 driver becomes prevalent in the distribution


Just use an MCU for now (Arduino/AVR/PIC/Cortex etc), build the firmware for the RTC and other peripherals you might have, and have the RPi talk to the MCU via a more standard communication port such as serial. That way, you are not in the mercy of some clever individuals to build an I2C or SPI driver for your RTC.
Posts: 106
Joined: Mon Dec 26, 2011 10:55 pm
by gordon@drogon.net » Mon Apr 02, 2012 7:26 am
hzrnbgy said:



Juice's RTC is so new that the driver probably isn't in the upstream kernels yet. Looks like Juice will remain a prototype for a long,long time until until the PCF8523 driver becomes prevalent in the distribution


Just use an MCU for now (Arduino/AVR/PIC/Cortex etc), build the firmware for the RTC and other peripherals you might have, and have the RPi talk to the MCU via a more standard communication port such as serial. That way, you are not in the mercy of some clever individuals to build an I2C or SPI driver for your RTC.



Maybe I'm missing something obvious, but is there really a need for an RTC?

So it gets time from the interweb when its connected at boot time, and regularly after that via the most excellent NTP service, but how many people are going to use them completely off-net as an embedded controller with different boards connected to them for various IO purposes?

I do wonder if your creating a solution to a problem that really doesn't exist. e.g. I have a few 100 Linux based PBXs out in the field and none of them have an on-board RTC (Alix boards) They work just fine getting their time at boot-time via NTP in exactly the same way as the R-Pi does, however they are designed to be connected to the 'net (VoIP) So might your design skills be better targetted at something else?

Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1544
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by Adnan » Mon Apr 02, 2012 4:07 pm
hzrnbgy said:


Just use an MCU for now (Arduino/AVR/PIC/Cortex etc), build the firmware for the RTC and other peripherals you might have, and have the RPi talk to the MCU via a more standard communication port such as serial. ...


Thanks for tip, hzrnbgy. I sometimes forget that Juice has its own MCU ;-)

Anyway, a minor update: My blanks have arrived! Actually, they arrived last Saturday noon, but I was too hungry and had to hunt for lunch.


And today, I built a load board to test Juice's buck regulator. Looks like I'll be cooking resistors for the next few days!!



The irrelevant looking PCB in the lower right of the above picture is the partially stuffed Juice PCB.
Posts: 12
Joined: Sun Mar 04, 2012 1:12 am
by arm2 » Mon Apr 02, 2012 8:23 pm
Adnan said:


arm2 said:


... that until I can get one tested in a R-Pi it would be foolish to sell them, oh and I can't get them tested until someone writes the I2C driver :-(


Hi arm2,

(it's really really early in the morning here -- couldn't sleep well).

Juice RTC is going to use NXP's PCF8523, a fairly new chip. What chip does your PCB use?


DS1338 which is software compatible with the DS1307 drivers for which are in the linux sources I'm told, as well as in the RISC OS sources!
Posts: 246
Joined: Thu Dec 15, 2011 3:46 pm
by hzrnbgy » Tue Apr 03, 2012 5:53 am

Maybe I'm missing something obvious, but is there really a need for an RTC?

So it gets time from the interweb when its connected at boot time, and regularly after that via the most excellent NTP service, but how many people are going to use them completely off-net as an embedded controller with different boards connected to them for various IO purposes?

I do wonder if your creating a solution to a problem that really doesn't exist. e.g. I have a few 100 Linux based PBXs out in the field and none of them have an on-board RTC (Alix boards) They work just fine getting their time at boot-time via NTP in exactly the same way as the R-Pi does, however they are designed to be connected to the 'net (VoIP) So might your design skills be better targetted at something else?


Not all applications for the RPi are Internet centric. A car PC would be one, or a remote data logger. I've seen planned projects such as quadcopter brain, remote seismic logger, a bike computer, etc. Obviously, a Linux box that's running PBX needs to be connected to the interweb, thus can always summon NTP for timing purposes
Posts: 106
Joined: Mon Dec 26, 2011 10:55 pm
by Adnan » Wed Apr 04, 2012 10:17 am
Hi all,

Just another minor update: Whilst I am load-testing the partially-stuffed Juice PCB#1, I've managed to fully solder up 2 more PCBs and written a blinky-LED test program for its MCU.



(Sorry: poor movie conversion quality -- more practice needed).

Anyway, the miserably simple blinky-LED firmware is a confidence test that I've soldered the ATmega168 DFN chip properly and that its underside-pins are really connected to their pads.
Posts: 12
Joined: Sun Mar 04, 2012 1:12 am
by Adnan » Thu Apr 05, 2012 10:35 am
Minor update: OK, today I was supposed to write an AVR module for the RS232 SW UART of Juice and use that to test the on-board PCF8523 RTC. Instead, after the SW UART got working with TeraTerm, I got distracted and wrote the control for the 4-port RC servo interface.



Formerly controlled by the Pololu 12-channel Servo Controller, I've re-attached the 4 front servos of my old (unfinished) robot cat to Juice, and commanded the servos using TeraTerm through the RS232 SW UART of Juice.

Of course, if I had a RasPi ((ranting)), gait & cat attitude development could be better programmed in a high-level language, e.g., like Python, Mono, etc.
Posts: 12
Joined: Sun Mar 04, 2012 1:12 am
by catmaker » Sat Jun 02, 2012 10:50 am
Ah! I'm too excited and I still can't find my 'reserved' microUSB power adapter or even a cable: Finally took the plunge this morning and just went ahead to power up my Pi with the Raspy Juice. (Very risky).

But it works!!!

Here's a picture.
Image

And the RS232 serial console through the 2.5mm stereo plug...
Image

Still so many things to do: test hub, test HDD, rebuild kernel with I2C, etc, etc. I feel like an idiot today.
Posts: 50
Joined: Thu May 24, 2012 8:32 am
by catmaker » Wed Aug 15, 2012 2:07 am
Hi, this thread is so old.

Anyway, I've managed to revise my PCB to Raspy Juice Rev.1:
    The seven JST connectors all had electrically incorrect orientation (pin 1 was pin3, and pin3 was pin1).
    The power socket near the top-left of each PCBA had the power wires that came out of it rubbing against the pins of GPIO header.
    The stereo jack that provided for the serial port console was also too near to the Raspberry Pi HDMI socket.
    Some minor circuit changes, like power-input polarity protection, expansion pins over-voltage protection, etc.
    And the dimensions of the old version were just a little off (just enough to irritate me).
Here a picture of new vs old:
Image

I've put up some hardware description of this PCBA and its connectors on https://code.google.com/p/raspy-juice/wiki/HardwareDescription

For the onboard expansion ATmega168A microcontroller attached to the GPIO I2C interface, the firmware and software is scarce at the moment (i ran out of steam), but I've adapted an open-source bootloader twiboot from http://git.kopf-tisch.de/?p=twiboot and managed to reflash the MCU from the Debian Wheezy command line without additional external hardware accessories. The adapted source, which includes a linux command-line firmware uploader is in the SVN repository and the description of using the bootloader is at https://code.google.com/p/raspy-juice/wiki/Bootloader. I use the Debian avr-gcc tools for the firmware building.

I am now in the process of preparing some "beta" kits to be available. I'm using shopify. These beta PCBA will be shipped with the bootloader pre-flashed in the MCU, so updating the firmware will hopefully not be too difficult.
Posts: 50
Joined: Thu May 24, 2012 8:32 am
by catmaker » Thu Aug 16, 2012 3:14 am
Ya!!! Finally did it -- the shopify account is now live and Raspy Juice Rev.1 Beta PCB kit is now made available.
See sub-forum thread of Add-ons for sale http://www.raspberrypi.org/phpBB3/viewtopic.php?f=59&t=14654

This beta kit is intended for developers/experimentors to code on the expansion MCU or,
for those just interested in powering the Pi in a compact PCB from batteries, other voltage DC adapters and sources.

I've also finally listed Raspy Juice under the RPi Expansion Boards of elinux.org
http://elinux.org/RPi_Expansion_Boards#Raspy_Juice_Exp_Board
Posts: 50
Joined: Thu May 24, 2012 8:32 am
by catmaker » Tue Aug 21, 2012 7:04 am
Found it:
The linux device driver for the NXP PCF8523 RTC real time clock used on Raspy Juice is found, fixed (because it was slightly broken) and uploaded into the svn repository of http://code.google.com/p/raspy-juice/ code project page.

I rebuilt and tested against the armhf kernel 3.2.27 sources found on https://github.com/RaspberryPi.
Below is an excerpt of the bootup:

Code: Select all
Uncompressing Linux... done, booting the kernel.
Initializing cgroup subsys cpu
Linux version 3.2.27-cutdown-aj3 (adnan@area51) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #4 PREEMPT Tue Aug 21 14:00:02 SGT 2012
CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: BCM2708
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 48768
Kernel command line: dma.dmachans=0x3c bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0x2 bcm2708.serial=0x9bb54a3c smsc95xx.macaddr=B8:27:EB:B5:4A:3C dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
....
usbcore: registered new interface driver libusual
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-pcf8523 0-0068: chip found, driver version 1.0
rtc-pcf8523 0-0068: rtc core: registered rtc-pcf8523 as rtc0
bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0x20205000 (irq 79)
bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79)
cpuidle: using governor ladder
cpuidle: using governor menu
....
rpdev login: root
Password:
Last login: Tue Aug 21 13:54:49 SGT 2012 on ttyAMA0
Linux rpdev 3.2.27-cutdown-aj3 #4 PREEMPT Tue Aug 21 14:00:02 SGT 2012 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Type 'startx' to launch a graphical session

 1516 ttyAMA0  Ss     0:00 /bin/login --
 1594 ttyAMA0  S+     0:00 -bash
 1595 ttyAMA0  S+     0:00 -bash
 1596 ttyAMA0  R+     0:00 ps ax
 1597 ttyAMA0  S+     0:00 grep ttyAMA0
root@rpdev ~ # ls /dev
autofs           loop6               ram15   tty12  tty33  tty54      vc-mem
block            loop7               ram2    tty13  tty34  tty55      vcs
bus              loop-control        ram3    tty14  tty35  tty56      vcs1
cachefiles       MAKEDEV             ram4    tty15  tty36  tty57      vcs2
char             mem                 ram5    tty16  tty37  tty58      vcs3
console          mmcblk0             ram6    tty17  tty38  tty59      vcs4
cpu_dma_latency  mmcblk0p1           ram7    tty18  tty39  tty6       vcs5
disk             mmcblk0p2           ram8    tty19  tty4   tty60      vcs6
fb0              mmcblk0p3           ram9    tty2   tty40  tty61      vcsa
fd               net                 random  tty20  tty41  tty62      vcsa1
full             network_latency     raw     tty21  tty42  tty63      vcsa2
fuse             network_throughput  root    tty22  tty43  tty7       vcsa3
i2c-0            null                rtc0    tty23  tty44  tty8       vcsa4
i2c-1            ppp                 shm     tty24  tty45  tty9       vcsa5
input            ptmx                snd     tty25  tty46  ttyAMA0    vcsa6
kmsg             pts                 stderr  tty26  tty47  uinput     video0
log              ram0                stdin   tty27  tty48  urandom    xconsole
loop0            ram1                stdout  tty28  tty49  usbdev1.1  zero
loop1            ram10               tty     tty29  tty5   usbdev1.2
loop2            ram11               tty0    tty3   tty50  usbdev1.3
loop3            ram12               tty1    tty30  tty51  usbdev1.4
loop4            ram13               tty10   tty31  tty52  v4l
loop5            ram14               tty11   tty32  tty53  vchiq
root@rpdev ~ # hwclock
Sat 08 Jan 2011 08:02:52 SGT  -0.928692 seconds
root@rpdev ~ #

Whom do I ask if I wanted to 'push' this patches into the above current linux kernel for the Raspberry Pi?
Can anyone help me, please? (BTW, I am not git-savvy at all :( ). Thanks very much.
Posts: 50
Joined: Thu May 24, 2012 8:32 am