[beagleboard] Yet another BeagleBone to be launched into space tonight

[Jason Kridner]

Yeah, we don't exactly do the best job of getting the word out about
BeagleBones in space. It has been done several times now, including at
least one payload upon the ISS that I believe is still there.

BeagleBones have been used as prototype test platforms for several years by
several space agencies and solution providers and it is only natural for a
few instances to actually end up making the journey.

Tonight's launch of the Indian rocket (PSLV) around 10pm US Central time (
http://www.newsbharati.com/Encyc/2018/11/28/India-to-launch-HysIS.html).

The payload will include the "Centauri-1" satellite with BeagleBone Black
as the main flight computer running KubOS open source flight software by
Kubos Corporation (https://www.kubos.com). It was developed for Fleet Space
Technologies out of Australia (https://www.fleet.space/) by Kubos and
Pumpkin (https://www.pumpkinspace.com).

I wasn't able to find out a lot else on-line...
https://space.skyrocket.de/doc_sdat/centauri-1.htm
http://www.manmonthly.com.au/news/fleet-space-technologies-unveils-launch-partners-first-nanosatellite-launches/


I found a bit more about the flight controller computer at
https://www.pumpkinspace.com/store/p208/mbm2.html.

I'm going to try to do a better job at getting folks to talk about such
events on this list as I believe this is of general interest.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnLPG5_bJkZoQDOoTTgV0dj1dbpOSTbM8p06dTMYFgz4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Naming of device tree fragments?

[Robert Nelson]

On Wed, Nov 28, 2018 at 12:08 PM Ken Shirriff  wrote:
>
> I need to configure a bunch of pins in a device tree, and I'm unclear of how 
> many fragments I need and how to name them. Specifically, I want the PRU to 
> control some GPIO pins, PRU pins, and PWM pins.
>
> Looking at a typical overlay, it has:
>__overlay__ {
> pru_gpio_pins: pinmux_pru_gpio_pins {
> pinctrl-single,pins = <
> 0x1a4 0x0f
> >;
> };
> pru_pru_pins: pinmux_pru_pru_pins {
> pinctrl-single,pins = <
> 0x1a4 0x25
> >;
> };
> };
>
> In the line "pru_gpio_pins: pinmux_pru_gpio_pins", am I correct that 
> "pru_gpio_pins" is an arbitrary name that gets used in pinctrl-0? What about 
> "pinmux_pru_gpio_pins" - is that arbitrary, or does this need to match 
> something else? (And if it needs to match something, where is that defined?)

It's pretty arbitrary, we've just kinda defaulted to the

xyz_pins: pinmux_xyz_pins for awhile now, so it became the
un-documented default..

But there is one change on kernel.org, the second string can't use
"_", so every is defaulting "-".. (there's a dtc warning about it)

pru_gpio_pins: pinmux-pru-gpio-pins

> Also, do I need to handle GPIO pins and PRU pins separately, as above? Or is 
> that for convenience / convention? And if I want to configure ehrpwm pins, do 
> I need a third section, or can I lump it in with the rest?

I'd keep them separate, at one time there was a plan to have a global
list of all pinmux options, but the imx guys found out that just
bloated up the dtb too much, so they removed their's.

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiX8RrQtwOjAf2cb3Cb0OGJwd%3DVOO6psacbOrknevttSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Naming of device tree fragments?

[Ken Shirriff]

I need to configure a bunch of pins in a device tree, and I'm unclear of 
how many fragments I need and how to name them. Specifically, I want the 
PRU to control some GPIO pins, PRU pins, and PWM pins.

Looking at a typical overlay 
,
 
it has:
   __overlay__ {
pru_gpio_pins: pinmux_pru_gpio_pins {
pinctrl-single,pins = <
0x1a4 0x0f 
>;
};
pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <
0x1a4 0x25
>;
};
};

In the line "pru_gpio_pins: pinmux_pru_gpio_pins", am I correct that "
pru_gpio_pins" is an arbitrary name that gets used in pinctrl-0? What about 
"pinmux_pru_gpio_pins" - is that arbitrary, or does this need to match 
something else? (And if it needs to match something, where is that defined?)

Also, do I need to handle GPIO pins and PRU pins separately, as above? Or 
is that for convenience / convention? And if I want to configure ehrpwm 
pins, do I need a third section, or can I lump it in with the rest? 

I looked at a bunch of documentation but couldn't find an explanation of 
this. Instead of randomly cutting-and-pasting, I figured it would be good 
to get a bit of conceptual understanding so I'm asking here.

Thanks,
Ken

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4a4590b2-a724-4013-acc0-4e680d4cf16f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Re: Increase Memory

[Gerald Coley]

1GB is the max as noted in the processor datasheet.

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of ibrahim...@gmail.com
Sent: Wednesday, November 28, 2018 8:27 AM
To: BeagleBoard 
Subject: [beagleboard] Re: Increase Memory



Yes ..i mean DDR RAM

On Wednesday, November 28, 2018 at 2:18:42 PM UTC+2, 
ibrah...@gmail.com wrote:
Hello
i want Increase memory  to 8 GB RAM  ...this is available  on BeagleBoard or 
not ?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/74326179-5ea6-4afe-9068-d58ef97f980a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f1746f937aee481f9aa2ae91336106cc%40winhexbeus11.winus.mail.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] EduMIP

[rjacobson]

I was wondering what is used for the "Drivetrain unit with motors and 
encoder boards", I am having my High School engineering students build 
these. 

Thanks for any help

Sorry if this has been answered, I did not see it.

Rob

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/428b4119-6124-4a00-82ed-663f93c064cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Increase Memory

[ibrahimtc2]

Yes ..i mean DDR RAM 

On Wednesday, November 28, 2018 at 2:18:42 PM UTC+2, ibrah...@gmail.com 
wrote:
>
> Hello  
> i want Increase memory  to 8 GB RAM  ...this is available  on BeagleBoard 
> or not ?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/74326179-5ea6-4afe-9068-d58ef97f980a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eduMip

[rjacobson]

Does anyone know what Drivetrain unit with motors and encoder board are 
being used? looking to do this in my classroom.

Thanks 

Rob

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ecd37863-f997-4967-a22d-473973667625%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU - Can't read data up to 2.5 MHz

[Gerhard Hoffmann]

Am 28.11.18 um 12:08 schrieb fred.p.gome...@gmail.com:
...

|state[0] = ((__R31) == sclk) ?  true :  false;|
|state[0] = (__R31) == sclk;
|
|
|
|should do the same thing, but I would expect the compiler to optimize|
|that away. Unrolling the loops and inlining should help, also.
|

This is how I do the read:

Remember that I read now the SPI data into a CPLD and fetch
them bytewise.

I switch the 2 byte address lines to the CPLD and then have to wait
7 ns for propagation through the CPLD and some time more until
the ringing at the P8/P9 connector has calmed down. So I must
wait, say 4 Instructions à 5 nsec before I really get the data.
That is done with some volatile reads. I had the impression that
the number of instructions and the delay did not always scale 1:1,
so it took some pruning with the oscilloscope until I was satisfied.

The canonical solution for your problem is probably to use the
hardware SPI interface with the PRU, which should work to 48 MBit/s.
I could not make that work, and in the end I wanted 100 MBit/s anyway.

cheers,
Gerhard

--


// data avail is either (not busy) or (not drl). It is high active.
// The CPLD takes a little more than 32 Clocks at 100 MHz
// to get the 32 bits. Then we can read them out, bytewise, and
// we select the byte using 2 port bits as address.
// It is probably harmless if that extends slightly into the next
// conversion since the read activity is decoupled from the ADC core
// Reading the CPLD does not toggle ADC pins.
//
// inline saves 20 nsec of procedure overhead.

inline void wait_data_avail(void){

    while  (  __R31 & (1 << DAT_AVAIL)) {};    // wait for the high 
time of p9.26 = data_avail

    while  (!(__R31 & (1 << DAT_AVAIL))){};    // wait for the low time
    // Now we are at the start of the high time. The ADC transaction 
window opens.

    // next 320 ns we will read the data into the CPLD or program the ADC
}


// read 4 bytes from the CPLD, mask them, shift them & convert to one int.
// I must read at least 3 times that the results are right ( for address 
setup time)
// removing a single read makes it 60 nsec faster, 15 nsec per read. 
Should be 5 nsec???

// reading 3 times takes 40 nsec per bit. That should be enough.
// reading 4 times takes 60 nsec per bit. Reading __R31 takes abt. 20 
ns. :-(
// Von der steigenden Flanke von data_available am P9 bis zum return 
dauert 725 nsec.

// kill 320 nsec, the time the CPLD needs to fill the shift register
// Once through the empty loop costs 5 nsec.
// for( retval=60; retval;  retval--){};

// In the mean time I have changed the CPLD so that it tells when I 
immediately
// can fetch the data, so I gain 350 nsec that were spent with busy 
waiting previously.

// Now I should be able to process 3 channels.
// Using the scope is essential to see where time is lost.

inline int read_adc(void){

    int retval;

    // Without volatile this runs 3 times as fast, even though __R31 is 
volatile

    // The compiler seems to assume incorrectly that reading __R31 has no
    // side effects. But it has. It spends time and data might change.
    //
    // maybe we could do the merging of the result in the setup time
    // but when the compiler re-arranges instructions that might fail.

    volatile unsigned int byte0, byte1, byte2, byte3;

    wait_data_avail();

    // from here to parking the address at return it takes 350 nsec.

    __R30   &= ~(3 << QSEL);    // address 0
    byte0    = __R31;            // address setup time for byte 0
    byte0    = __R31;
//    byte0    = __R31;
    byte0    = __R31;

    __R30   |= (1 << QSEL);        // address 1
    byte1    = __R31;
    byte1    = __R31;
//    byte1    = __R31;
    byte1    = __R31;

    __R30   &= ~(3 << QSEL);    // address 2,   remove old bit field
    __R30   |=  (2 << QSEL);    // insert new bit field
    byte2   = __R31;
    byte2   = __R31;
//    byte2   = __R31;
    byte2   = __R31;

    __R30   |= (1<< QSEL);        // increment to address 3
    byte3   = __R31;            //
    byte3   = __R31;
//    byte3   = __R31;
    byte3   = __R31;            // get the last byte

    retval  = ((byte0 & 0xff)  )
            | ((byte1 & 0xff) << 8 )
            | ((byte2 & 0xff) << 16)
            | ((byte3 & 0xff) << 24);

    __R30   &= ~(3 << QSEL);    // park address at 0, may be removed.
                                // but makes it easy to spot the action 
on the scope.

    return  retval;
}

--

I have to read data from an SPI master device, which sends the clock 
at 10 MHz. Since the SPI kernel driver only allows to the beagle bone 
to working as SPI Master I had to implement this functionality using a 
PRU.


From what I've read throughout the internet the PRU processing rate is 
200 MHz, so I thought I could easily read data at 10 MHz. Oddly, it 
happens that with transmission rates up to 2.5 MHz I am being unable 

RE: [beagleboard] Increase Memory

[Gerald Coley]

If you mean DDR, no.

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of ibrahim...@gmail.com
Sent: Tuesday, November 27, 2018 11:40 PM
To: BeagleBoard 
Subject: [beagleboard] Increase Memory

Hello
i want Increase memory  to 8 GB RAM  ...this is available  on BeagleBoard or 
not ?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/eaab844b-e007-4431-9d23-9428ff14282e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/58874ca09e8d4de5bc76819daa66b573%40winhexbeus11.winus.mail.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU - Can't read data up to 2.5 MHz

[fred . p . gomes92]

Hello, I need your help 

I have to read data from an SPI master device, which sends the clock at 10 
MHz. Since the SPI kernel driver only allows to the beagle bone to working 
as SPI Master I had to implement this functionality using a PRU.

>From what I've read throughout the internet the PRU processing rate is 200 
MHz, so I thought I could easily read data at 10 MHz. Oddly, it happens 
that with transmission rates up to 2.5 MHz I am being unable to catch all 
the rising edges on the clock pin.

So, here's what I did:

In the PRU0 I wrote the following code:

bool WaitForRisingEdge_sclk(uint32_t sclk)
{ 
state[0] = ((__R31) == sclk) ?  true :  false;
if((state[0] == true) && (previous_state[0] == false))
{
previous_state[0] = state[0];
return true; //Rising edge 
}
else{
previous_state[0] = state[0];
return false;
}
}

void main(void)
{ 
while(1)
{
START:
count_clocks = 0;
while(gpio2[GPIO_DATAIN/4] & P8_8) //Receive notification from the beagle 
bone to read data
{ 

LOOP:
if(WaitForRisingEdge_sclk(sclk)) // wait for rising edge on clock pin
{
//buffer[i] = ((__R31) == miso)?  buffer[i] | 0x01 << k : buffer[i] | 
0x00 << k; 
//buffer[i] =   buffer[i] | 0x01 << k; 
count_clocks++; 
}
else if(WaitForRisingEdge_cs(cs))
{
gpio2[GPIO_SETDATAOUT/4] = P8_7; // Notify the beagle bone that the data 
was already read
buffer[2600] = count_clocks;
goto START;
}
else
{
goto LOOP;
} 
} 
}
}


and I did one simple program ON PRU1 which sends at a certain frequency. I 
got to the conclusion that with transmission rates up to 2.5 MHz and can't 
count all the clocks. I was wondering if there is any better way for 
reading the rising edge, I might be lossoing performance on that function 
itself.

Thank you very much for your help,
-- Fred Gomes



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0beef84d-177e-4d3a-b877-42728c5891f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Increase Memory

[ibrahimtc2]

Hello  
i want Increase memory  to 8 GB RAM  ...this is available  on BeagleBoard 
or not ?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/eaab844b-e007-4431-9d23-9428ff14282e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.