[beagleboard] Re: Monitor Line Current with UPS
Hi Trevor, My first thought would be to use a UPS that provides a Power HID device over USB. It's safe and *should* be simple. I haven't messed with it but there is Linux software for monitoring and reporting UPS status. The "ghetto" way would be to use an opto-isolated zero-crossing type circuit to pull down a GPIO. The signal will briefly pop back up near the zero crossings but at least you'll know that AC is present. The usual disclaimer on this method: 120VAC can kill. -Ron On Thursday, August 16, 2018 at 2:57:55 PM UTC-5, Trevor Morris wrote: > > > Looking for suggestions... > > I have an IOT device that has a BBB with a power cape powered by a 5vdc > psu hooked up to a switch and a 4g modem that are powered by a 24vdc psu > all powered off of an incoming 120vac line. > > The power cape is setup to gracefully shut down the BBB if the power is > off for more than 30 seconds coming off of the 5vdc psu. > > I'am adding an APC UPS in front of both of the smaller PSU's so that I can > keep the entire unit connected to the network on powerloss. > > What I'am not sure how to approach is monitoring supply current so that > the beagle knows when Line voltage is no longer being supplied. Some of my > ideas have included using one of the random sensors I see floating around > or using a NC relay and holding it open with power. I main want to be able > to send an sms to myself if the power switches to the UPS and I'am > currently less concerned about monitoring the status of the UPS or anything > like that (although that would be cool). More important that the device > tells me when it goes off mains power and when it goes back on mains power > so I can decide weather or not I need to go attend to it. > > Has anyone tried to do anything like this? Any suggestions for a simple > way to monitor when the current drops to zero with the gpio pins? Seems > like I should be able to do this some real ghetto, yet reliable way > > Thanks > -- 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/7757d8cb-f6b4-490d-9960-77228d9aa02a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: PRU shared Ram
The PRU cookbook is nearing completion (more accurately, I'm running out of
summer).
Here's a link https://markayoder.github.io/PRUCookbook/
I'm happy for any feedback you can give me.
--Mark
On Thursday, June 28, 2018 at 8:45:00 PM UTC-4, Neilh wrote:
>
> Ok thanks. I see I was think SHARED_RAM between the ARM-A8 and PRU0 and
> its actually shared between ARM PRU0 and PRU1. A-lightbulb---h
> Many thanks for the evolving cookbook and detailed explanation- I have got
> a little lost at times digging through the manual - gosh I want to read all
> the PRU sections - I'd have paid gold 4weeks ago when I started using the
> PRUst!.
> If it becomes a book I'll be first in line to buy it :).
> The PRUs are a cool part of the BBB - and now I've got it working appears
> pretty simple.
>
>
> On Thu, Jun 28, 2018 at 12:59 PM Mark A. Yoder > wrote:
>
>> Neilh:
>> I've worked up some examples[1] for a PRU Cookbook that might help. I'm
>> taking a similar approach to what you did, but I'm using DRAM0. It
>> shouldn't be hard
>> to switch to shared RAM.
>>
>> --Mark
>>
>> [1]
>> https://markayoder.github.io/PRUCookbook/05blocks/blocks.html#_controlling_the_pwm_frequency
>>
>>
>> On Wednesday, June 27, 2018 at 5:36:13 PM UTC-4, Neilh wrote:
>>>
>>> Oops I got it - it was sizing a pointer and not the struct.
>>>
>>> I'd be interested in anybody's comments on the use of the SHAREDRAM
>>> approach as it makes for a very simple one way api. I'm partly publishing
>>> this as a tutorial for anybody else - but its my first try at the PRU.
>>>
>>> Here is the logic anlayzer output from the Saleae 8 Channels mapping of
>>> PRU0 to GPIO P9_25 ...P8_12
>>> There is an increasing pulse count chn0, and then fixed 1hz, 2hz... on
>>> subsequent channels
>>>
>>>
>>>
>>> On Wed, Jun 27, 2018 at 2:13 PM Neil Hancock wrote:
>>>
Oops - you are right, I'll update my comments
Here is the code that is allocating the SHAREDRAM - though I'm still
hazy as to how mmap() works in BBB mapping the SHAREDRAM
#define AM33XX_DATARAM0_PHYS_BASE 0x4a30
#define AM33XX_DATARAM1_PHYS_BASE 0x4a302000
#define AM33XX_PRUSS_SHAREDRAM_BASE 0x4a31
#define SHARED_RAM_SZ 16 /* grab 8*4 bytes or 8 words */
volatile uint16_t *shared_dataram;
/* Define an API to be calleable from JS -still needs work */
void bbbio_ppm_api(struct channels_s *channels){
memcpy((void *)shared_dataram,(void *)channels,sizeof(channels));
}
void bbbio_ppm_init() {
/* Allocate shared memory pointer to PRU0 DATARAM */
int mem_dev = open("/dev/mem", O_RDWR | O_SYNC);
volatile void *shared_dataram_init = mmap(NULL,
SHARED_RAM_SZ,
PROT_READ | PROT_WRITE,
MAP_SHARED,
mem_dev,
AM33XX_PRUSS_SHAREDRAM_BASE
);
shared_dataram = (uint16_t *) shared_dataram_init;
}
void bbbio_ppm_cleanup() {
munmap((void *)shared_dataram,SHARED_RAM_SZ); //njh guess at releasing
it.
}
#ifdef MAIN_LOCAL
void main() {
unsigned int sec_i, chnl_j;
unsigned int offset;
struct channels_s channels;
volatile uint16_t *shared_dataram2;
bbbio_ppm_init();
uint16_t ppm =60;//actually
offset = 0;
channels.chn[offset].sr =ppm;
printf("shared_datara2 = %p, offset=%d At init Read:",
shared_dataram,offset);
shared_dataram2 = (uint16_t *) shared_dataram;
for(chnl_j=0; chnl_j<8; chnl_j++) {
printf(" %04d", *shared_dataram2);
shared_dataram2++;
if (0x3 ==(chnl_j & 0x3)){printf(" ");}
}
printf("\n");
ppm =0;
for(chnl_j=0; chnl_j<8; chnl_j++) {
channels.chn[chnl_j].sr=ppm;
ppm += 60;
}
//Fut - wait for ack from PRU and then init shared ram
//while (1)
{
ppm=60;
for(sec_i=0; sec_i<8; sec_i++) {
channels.chn[offset].sr +=ppm;
//memcpy((void *)shared_dataram,(void *),sizeof(channels));
bbbio_ppm_api();
printf("Writing %04d Read:", ppm);
shared_dataram2 = (uint16_t *) shared_dataram;
for(chnl_j=0; chnl_j<8; chnl_j++) {
printf(" %04d", *shared_dataram2);
shared_dataram2++;
if (0x3 ==(chnl_j & 0x3)){printf(" ");}
}
printf("\n");
sleep(1);
}
}
bbbio_ppm_cleanup();
}
#endif //MAIN_LOCAL
On Wed, Jun 27, 2018 at 1:33 PM Dennis Lee Bieber
wrote:
> On Wed, 27 Jun 2018 12:18:27 -0700, Neil Hancock
> declaimed the
> following:
>
> > with 8*int16 (or 32bytes).
> >
> Pardon?
>
> int16 is 2-bytes, 8*2 => 16 bytes
>
> >Initially I tried 8*int32 (64bytes) but could only sucessfully use the
> >first 5*int32(40bytes
> >
>
[beagleboard] Re: header file for CCSv6 & PRU
I forgot this from my previous post: /* I2C2 register offsets */ #define I2C2_STATUSRAW (*((volatile unsigned int*)0x4819C024)) #define I2C2_CNT (*((volatile unsigned int*)0x4819C098)) #define I2C2_SA (*((volatile unsigned int*)0x4819C0AC)) #define I2C2_DATA (*((volatile unsigned int*)0x4819C09C)) #define I2C2_CON (*((volatile unsigned int*)0x4819C0A4)) #define I2C2_SCLL (*((volatile unsigned int*)0x4819C0B4)) #define I2C2_SCLH (*((volatile unsigned int*)0x4819C0B8)) #define I2C2_PSC (*((volatile unsigned int*)0x4819C0B0)) I couldn't be bothered to setup a header file for this lot, so just stuffed it in the top of my PRU code... Registers for other I2C modules are in the memory map from the am335X_trm On Tuesday, 14 August 2018 12:29:12 UTC+1, Hugh Frater wrote: > > Does anyone know the header file I need to include to get access to the > i2c2 control registers from within the PRU subsystem? Having a hard time > getting any info and my google-foo is usually pretty decent... > -- 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/9145aa05-a10f-4188-a293-b1cb0358392a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: header file for CCSv6 & PRU
An update: 1. Enable the i2c peripheral clock: #define CM_PER_I2C2 (*((volatile unsigned int *)0x44E00044)) /* Enable I2C2 clock signal generation */ while (!(CM_PER_I2C2 & 0x2)) CM_PER_I2C2 |= 0x2; 2. Setup the registers: /* * set I2C2_PSC register to 0x0B * set I2C2_SCCL register to 0x0D * set I2C2_SCCH register to 0x0F * set I2C2_CON register to 1000 0110 (0x8600) * set I2C2_SA register to 0x2E (address of MCP4641) * set I2C2_CNT register to 2 (data length) */ I2C2_PSC = 0x000B; I2C2_SCLL = 0x000D; I2C2_SCLH = 0x000F; I2C2_CON = 0x8600; I2C2_SA = i2cPotAddress; I2C2_CNT = 2; 3. You can now program the device: /* * poll 'busy bit' in I2C2_STATUSRAW register (bit 12) until it is zero * set start/stop bits in I2C2_CON register to initiate a transfer * poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero * load 1st byte of data into I2C2_DATA register * poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero * load 2nd byte of data into I2C2_DATA register */ while (I2C2_STATUSRAW & 0x1000); //poll 'busy bit' in I2C2_STATUSRAW register (bit 12) until it is zero I2C2_CON = 0x8603; while (!I2C2_STATUSRAW & 0x0010); //poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero I2C2_DATA = torqueWiper; while (!I2C2_STATUSRAW & 0x0010); //poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero I2C2_DATA = 0x55; 4. The kernel mode (and bonescript) i2c drivers will put the device to sleep and disable the clock after every transfer, so to access it from the PRU you need to setup the registers each time you want to access a device on the bus. Hope that helps someone... On Tuesday, 14 August 2018 12:29:12 UTC+1, Hugh Frater wrote: > > Does anyone know the header file I need to include to get access to the > i2c2 control registers from within the PRU subsystem? Having a hard time > getting any info and my google-foo is usually pretty decent... > -- 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/4f509d76-975c-4f6e-920d-5e3963d2f364%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
