Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Battery powered raspberry pi (http://www.chiefdelphi.com/forums/showthread.php?t=117989)

yash101 17-12-2013 18:39

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by techhelpbb (Post 1313818)
You can do that with an operational amplifer as a comparator you do not need an MCU for that. In fact some MCU I have used in power supply systems have integrated voltage comparators.

What is an example of a decent MCU with a built-in comparator? Using a comparator will allow me to increase the max current output because the chip will be able to switch faster.

Quote:

If your regulation is that loose you can not expect to measure voltage.
In fact you will not get close.
This is for the MCU to run off. The vRef will be regulated by LDO (with a capacitor) to get power spikes out of the equation. The 2.7V min voltage means that I will be able to run the chip at a lower voltage.

Quote:

It has ROM masked for Spin and the lookup tables. There is no way 8 chips with the windowed RAM is cheaper or smaller than the Parallax Propeller QFP with crystal and external flash. Plus even the BASIC Stamp has external flash memory.
Yeah! I forgot about that! I last played with the BASIC Stamp two years ago. Then, it was taken over by it's powerful son, the Propeller!

Quote:

Even with 2 chips you still need a crystal oscillator and other parts and you might need a reset controller with something like the 8051.
I don't need the eight cores. Eight cores is just overkill. Plus, typical microcontrollers, even the SX, allow interrupts. While the Propeller is the perfect platform for development, it isn't suitable for the end product. Even better would be to use Pi GPIO, which can switch at over 100MHz! That's what you get when you power a small thing with a big processor, or load a sedan with the engine of an airplane (If even possible) :D

Currently, it seems as though here are some good choices, for the end product.
PIC32
PIC
PicAxe
AVR
SX
[strikethrough]BASIC Stamp[/strikethrough]

Quote:

As far as failure points you would have to mess up pretty bad to be better off. Unless you use the internal R/C oscillator in a cheap low end 8bit Microchip or Atmel AVR chip. Plus the external program storage means that if you kill that storage you save the MCU itself. Not so big a deal for an experienced user but an issue for the inexperienced or eventually it will become an issue.
I agree. Even RadioShack components will last a class 10 earthquake (Has it even happened before?). However, as the number of parts increases, the complexity increases (almost always), so there will be more failure points. It would also make perfect designing harder!

Quote:

Plus there's the whole: potentially needing a chip programmer issues you are overlooking unless you use some form of ISP (In-System-Programming). Never mind the potential need for a debugger which the Parallax Propeller to some extent already offers.
That is true. As mentioned before, I am looking for chips with serial programming capabilities like all (I think) of Parallax's MCUs!

Quote:

The QFP version of the Propeller is pretty small. There are smaller MCU but even the BASIC Stamp has an onboard regulator, external RAM and the crystal which will make the board bigger. Since most of the Parallax parts fit on a board that's about 600mil across to fit a 600mil DIP IC socket I bet you won't make this smaller without cutting some corners.
It is small, but for now, I will be playing with DIPs! I suck at SMT soldering, so I won't use it until I get more experience at it.

[quote]For example an R/C time constant will make your timers temperature sensitive and will drift.
Fine for something not timing sensitive but not so good if you need the timing of something predictable.
[quote]

I won't be using RC because it is hard to get very accurate values quickly. I am going to use an MCP3204, with a Sigma-Delta setup because it offers a very high refresh rate, faster than the Propeller can handle!

Quote:

You do not need an MCU for this purpose. How is no I/O :).
That is true. However, MCUs can be the BIY Hobbyist/Prototyper's best friend because it is easy to configure them. They will function as millions of transistors, addressable by code!

Quote:

If you don't need all the features of the Parallax Propeller then look at the 8bit Microchip PIC (like the older FIRST systems) and Atmel AVR controllers (you probably know them as Arduino). You probably don't want to learn how to use an Intel 8051 architecture or 6800 architecture so that is off the table because that tends to involve a lot of interconnects and extra parts. (There are about 1 dozen less frequently mentioned MCU I could put here but I won't because as a high school student you'll drive yourself nuts learning it just to discover it's not as standard in the industry). I will mention the Hitachi H8 because of the older LEGO Mindstorms RCX bricks. The lower end Microchip and AVR parts are even less expensive but in all cases you will be doing everything by sharing time on that single processor system. Expect to make choices with peripherals because to stretch that single processor further they add peripherals to offload specific tasks into logic within those MCU.
I will test with different parts, off-the-shelf boost/buck converters, and try to face off MCUs, if I have the time (I probably will need to learn a different language for each one!

Quote:

https://sites.google.com/site/propellergcc/

I believe previously you wanted to program in Java but here you go.
There are 100 or more other languages or ports available on the Propeller as well but that's neither here nor there.
You already pointed me to Propeller@WikiSpaces, an article on how to program in Java on this platform. Thanks :)

Quote:

Single ended or differential?
Muxed or unmuxed?
Do you mean Mixed? Doing a google searches kept pointing me to Mixed. I probably will go for Unmixed if possible, though mixed may work if the switch times are good.

Quote:

Muxed A/D inputs let you switch analog inputs but you can't read them all at the same time.
Differential inputs allow you to lift the monitored circuit ground.
The cRIO analog bumper is single ended, ground is the system ground, and even the cRIO uses an external ADC.
I am thinking that an external ADC may be the best ;)

techhelpbb 17-12-2013 20:04

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by yash101 (Post 1313873)
What is an example of a decent MCU with a built-in comparator? Using a comparator will allow me to increase the max current output because the chip will be able to switch faster.

Microchip and Atmel both offer 8bit MCU with comparators.
Look up the Microchip and Atmel product selectors on their websites it lists all the current production models and you can filter that list to find the ones that fit what you want.

Quote:

This is for the MCU to run off. The vRef will be regulated by LDO (with a capacitor) to get power spikes out of the equation. The 2.7V min voltage means that I will be able to run the chip at a lower voltage.
I've gotta ask why you think that lower voltage is going to help you. At this point even the Propeller has a lower drop out voltage than most of the rest of the robot and since this is a FRC targeted idea: why do you need an even lower drop out? If the argument is: but it's another 1V or so I can drop I think you really ought to try to run one of these 2.7-5V chips a bit and see why that's not as great an idea as you think it is. You still need some voltage to drop. At some point you'll still start to brown out and it'll still be be between 3V and 4V DC.

Quote:

I don't need the eight cores. Eight cores is just overkill. Plus, typical microcontrollers, even the SX, allow interrupts. While the Propeller is the perfect platform for development, it isn't suitable for the end product. Even better would be to use Pi GPIO, which can switch at over 100MHz! That's what you get when you power a small thing with a big processor, or load a sedan with the engine of an airplane (If even possible) :D
I can't argue that you need 8 cores for what you are doing. There are many things that do not need 1 core (this is one of them). However I can point out to you, actually again, that interrupts are not a wonderful solution to a lot of problems. They create complex situations that are sometimes painfully difficult to digest and can leave you with a problem you can't easily replicate. Stalling development in a fast past environment like FRC where it might have consequences. Should you learn interrupts - yes. Does learning interrupts by necessity make them better than polling or logic - not at all. Somewhere the scientific method should help you deduce which is better for what purpose.

Quote:

Currently, it seems as though here are some good choices, for the end product.
PIC32
PIC
PicAxe
AVR
SX
[strikethrough]BASIC Stamp[/strikethrough]
The first is a 32bit version of the Microchip product offering. It's not quite low end ARM in performance and like the AVR MEGA it's not what most people think of as midrange or low end CPU either.

PIC and PICAXE are both 8bit Microchip PICs.
One has software in it already.

Atmel AVR and the AVR MEGA are 8bit microcontrollers.
Atmel XMEGA offer 16bit.
Atmel AVR U3 offer 32bit (think PIC32 competitor space).

The Parallax Semiconductor (previously Ubicom) chips are 8bit but fast.
I have plenty of old SX chips I don't use because anything that needs that sort of RISC speed I probably move too much data to use those chips.

Quote:

I agree. Even RadioShack components will last a class 10 earthquake (Has it even happened before?). However, as the number of parts increases, the complexity increases (almost always), so there will be more failure points. It would also make perfect designing harder!
Whoever told you a design can be perfect needs to look for flaws harder.

If you want to design PCB you may as well start learning how to connect parts because you can not avoid it. It's true that putting some things in the chips can reduce board complexity and the number of layers. However there are many examples of where putting something like an ADC in a chip produces a not so great example of an ADC because you can't alter the ADC to deal with system issues.

I have 2 LPKF PCB mills. I make 2 layer boards all the time. There are many examples where I am assured that I need 4 layers and even in the RF range it works as long as I respect design practice and shield.

PCB designing is a big job and requires a fair degree of knowledge. Do not fear it just learn how to do it because if you make a career out of electronics you'll be doing it again in the future.

Quote:

That is true. As mentioned before, I am looking for chips with serial programming capabilities like all (I think) of Parallax's MCUs!
You want the flash ISP chips then. You need to get an ISP adapter or make one probably to go from USB to ISP header (and there are different ISP headers).

The Propeller development boards come with the USB to serial adapters.
You'll be in a situation where you don't have that.
ISP is basically serial but usually it's not done these days with a serial port.

There are plenty of cheap Chinese knockoffs of the PIC and AVR ISP programmers that work great.

Quote:

It is small, but for now, I will be playing with DIPs! I suck at SMT soldering, so I won't use it until I get more experience at it.
Best way to get experience is get experience. That said DIP has excellent durability and that's why still today a lot of military electronics are DIP. If you want SMT without soldering find an assembly house.

Quote:

I won't be using RC because it is hard to get very accurate values quickly. I am going to use an MCP3204, with a Sigma-Delta setup because it offers a very high refresh rate, faster than the Propeller can handle!
You are incorrect. I can outrun an MCP3204 with a Propeller but I will do it in assembler.
Now for a better question - what are you doing with that data?

Quote:

That is true. However, MCUs can be the BIY Hobbyist/Prototyper's best friend because it is easy to configure them. They will function as millions of transistors, addressable by code!
Technically if you want the right tool for the right job you'd remember that you can't just program all the transistors in an MCU. You can't even do that in an FPGA. You can work with the building blocks and interfaces you are offered. In an FPGA those are logic that, if you desired, you could slap together to make a processor like the Propeller (that's how it was prototyped BTW). In an MCU/CPU those blocks are dedicated to functions and the most variability is offered by instructing those functions.

It is an illusion that analog is dead >entirely<. An analog circuit is not subject to illusion of synchronized timing to a clock. True digital has valuable contributions it can make but truly an array of programmable transistor interconnects is an analog construct it does not require a clock even if it can harness it. In fact there was a company that used to make analog programmable circuits.

I often see students trying to bang all problems with the same hammer. Anyone telling you as a student in high school you can't handle analog electronics is being dishonest. I was fixing tube televisions by 7th grade. In the context of your comments previously by the time I was in high school I was programming in assembler on 5 platforms and at least 3 of those professionally for parts of projects (at least one of those was a multimillion dollar job). So whatever reason I could handle that having graduated from high school in 1994 it shouldn't have become harder.

Quote:

I will test with different parts, off-the-shelf boost/buck converters, and try to face off MCUs, if I have the time (I probably will need to learn a different language for each one!
Yes and no. However because the other MCU on your list have proprietary and integrated peripherals you'll have to learn those and their quirks.

Quote:

You already pointed me to Propeller@WikiSpaces, an article on how to program in Java on this platform. Thanks :)
I just told you where to find C/C++ for the Propeller as well.

Quote:

Do you mean Mixed? Doing a google searches kept pointing me to Mixed. I probably will go for Unmixed if possible, though mixed may work if the switch times are good.
No I wrote what I wrote. An analog mux is a switch usually made from CMOS that functions as a low loss way to connect the internal input of an ADC to another external input of the chip package (in this application). So a chip might say it has 8 analog inputs but it might be 2 single ended ADC with a mux.

If that's the case you can't actually read all the inputs at the same time. You have to switch the mux.

Quote:

I am thinking that an external ADC may be the best ;)
Internal or external ADCs are beasts and the faster they run the more annoying they can be. I worked on oscilloscopes using the XMEGA in Altoids cans that you could put on the robot. 2 channels and all of that internal to the Atmel XMEGA. Cheap yes but with plenty of complications.

Another good part about knowing your external ADC and it being SPI/I2C is you can pivot that knowledge to another MCU. So let's say you decide the Propeller is a way over the top for a production product. So you leave your existing ADC circuit and put it on the other MCU.

That was a big factor in my choice in my helping to propose a 2015 control system. I wanted to know that peripherals were flexible. You could connect them to ARM, Atmel and PIC and connect those all together and the knowledge would transplant (mostly). Building blocks like LEGO instead of a limited COTS product.

yash101 17-12-2013 21:24

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by techhelpbb (Post 1313949)
Microchip and Atmel both offer 8bit MCU with comparators.
Look up the Microchip and Atmel product selectors on their websites it lists all the current production models and you can filter that list to find the ones that fit what you want.



I've gotta ask why you think that lower voltage is going to help you. At this point even the Propeller has a lower drop out voltage than most of the rest of the robot and since this is a FRC targeted idea: why do you need an even lower drop out? If the argument is: but it's another 1V or so I can drop I think you really ought to try to run one of these 2.7-5V chips a bit and see why that's not as great an idea as you think it is. You still need some voltage to drop. At some point you'll still start to brown out and it'll still be be between 3V and 4V DC.



I can't argue that you need 8 cores for what you are doing. There are many things that do not need 1 core (this is one of them). However I can point out to you, actually again, that interrupts are not a wonderful solution to a lot of problems. They create complex situations that are sometimes painfully difficult to digest and can leave you with a problem you can't easily replicate. Stalling development in a fast past environment like FRC where it might have consequences. Should you learn interrupts - yes. Does learning interrupts by necessity make them better than polling or logic: not at all. Somewhere the scientific method should help you deduce which is better for what purpose.



The first is a 32bit version of the Microchips product offering. It's not quite ARM and like the AVR MEGA it's not what most people think of as midrange or low end CPU either.

PIC and PICAXE are both 8bit Microchip PICs.
One has software in it already.

Atmel AVR and the AVR MEGA are 8bit microcontrollers.
Atmel XMEGA offer 16bit.
Atmel AVR U3 offer 32bit (think PIC32 competitor space).

The Parallax Semiconductor (previously Ubicom) chips are 8bit but fast.
I have plenty of old SX chips I don't use because anything that needs that sort of RISC speed I probably move too much data to use those chips.



Whoever told you a design can be perfect needs to look for flaws harder.

If you want to design PCB you may as well start learning how to connect parts because you can not avoid it. It's true that putting some things in the chips can reduce board complexity and the number of layers. However there are many examples of where putting something like an ADC in a chip produces a not so great example of an ADC because you can't alter the ADC to deal with system issues.

I have 2 LPKF PCB mills. I make 2 layer boards all the time. There are many examples where I am assured that I need 4 layers and even in the RF range it works as long as I respect design practice and shield.

PCB designing is a big job and requires a fair degree of knowledge. Do not fear it just learn how to do it because if you make a career out of electronics you'll be doing it again in the future.



You want the flash ISP chips then. You need to get an ISP adapter or make one probably to go from USB to ISP header (and there are different ISP headers).

The Propeller development boards come with the USB to serial adapters.
You'll be in a situation where you don't have that.
ISP is basically serial but usually it's not done these days with a serial port.

There are plenty of cheap Chinese knockoffs of the PIC and AVR ISP programmers that work great.



Best way to get experience is get experience. That said DIP has excellent durability and that's why still today a lot of military electronics are DIP. If you want SMT without soldering find an assembly house.



You are incorrect. I can outrun an MCP3204 with a Propeller but I will do it in assembler.
Now for a better question - what are you doing with that data?



Technically if you want the right tool for the right job you'd remember that you can't just program all the transistors in an MCU. You can't even do that in an FPGA. You can work with the building blocks and interfaces you are offered. In an FPGA those are logic that, if you desired, you could slap together to make a processor like the Propeller (that's how it was prototyped BTW). In an MCU/CPU those blocks are dedicated to functions and the most variability is offered by instructing those functions.

It is an illusion that analog is dead >entirely<. An analog circuit is not subject to illusion of synchronized timing to a clock. True digital has valuable contributions it can make but truly an array of programmable transistor interconnects is an analog construct it does not require a clock even if it can harness it. In fact there was a company that used to make analog programmable circuits.

I often see students trying to bang all problems with the same hammer. Anyone telling you as a student in high school you can't handle analog electronics is being dishonest. I was fixing tube televisions by 7th grade. In the context of your comments previously by the time I was in high school I was programming in assembler on 5 platforms and at least 3 of those professionally for parts of projects (at least one of those was a multimillion dollar job). So whatever reason I could handle that having graduated from high school in 1994 it shouldn't have become harder.



Yes and no. However because the other MCU on your list have proprietary and integrated peripherals you'll have to learn those and their quirks.



I just told you where to find C/C++ for the Propeller as well.



No I wrote what I wrote. An analog mux is a switch usually made from CMOS that functions as a low loss way to connect the internal input of an ADC to another external input of the chip package (in this application). So a chip might say it has 8 analog inputs but it might be 2 single ended ADC with a mux.

If that's the case you can't actually read all the inputs at the same time. You have to switch the mux.



Internal or external ADCs are beasts and the faster they run the more annoying they can be. I worked on oscilloscopes using the XMEGA in Altoids cans that you could put on the robot. 2 channels and all of that internal to the Atmel XMEGA. Cheap yes but with plenty of complications.

Another good part about knowing your external ADC and it being SPI/I2C is you can pivot that knowledge to another MCU. So let's say you decide the Propeller is a way over the top for a production product. So you leave your existing ADC circuit and put it on the other MCU.

That was a big factor in my choice in my helping to propose a 2015 control system. I wanted to know that peripherals were flexible. You could connect them to ARM, Atmel and PIC and connect those all together and the knowledge would transplant (mostly). Building blocks like LEGO instead of a limited COTS product.

I'll search for some MCUs with that features upon the start of my Christmas Break, which I am devoting to robotics!

The lower voltage won't directly help me. It will help me in the voltage regulator etcetera. I like the multi-core environment much more, the reason why I want to use a Propeller for the host controller. I will dedicate a core to the settings, a core to continuously fetch the ADC and store it's value. There will be a separate core for each regulator, making sure that the current spikes don't cause sudden voltage ups and downs. This is the reason why I will use a semi-large capacitor on the output. I like using an MCU because the frontend will allow me to change settings like the output voltage. If I can calculate how much the voltage will be increased by each switch, the frontend can be used to set exact voltage, for example, 4.9v instead of 5v. Or, if you are wierd and want something like 12v coming from a USB port (Why would anyone want that?!?!), that could be set up! MCUs are just lovely because you can customize them completely and do what you want!

I think that you will have problems in interrupt-based coding if you are used to multi-core, vice-versa. It's based on what the programmer has experience with.

I didn't know that a PICAxe was a PIC with a bootloader! That's quite interesting, and probably why it is the "PIC"Axe!

I program my Propeller in C already. However, for this project, I most-likely will switch to Assembler because of the brisker operation!

Also, I know that MCUs aren't the best thing to use. FPGAs will still beat them. However, FPGAs will lack behind building the gates yourself and creating a circuit that does NO processing! MCUs open up a world of simplicity, however, If I program an MCU wrong, I can change the code. However, redesigning a PCB can be a much more expensive process.

Compare and contrast this to a 3D printer. These make it possible for anyone to build prototypes without shelling thousands of bucks to a mold. In the other hands, using an injection molding system would mean a higher quality. Just think of an MCU as a 3D printer and an IMS as using transistors to build an autonomous system.

Sorry about that. I typically call a Mux by a Multiplexer.

You, being the guru at PAsm, probably know what can be done. With 20MIPS, an MCP3204 could be outrun, but I would have to be as good of a programmer as you, which won't happen in all of a sudden. You, being the guru, how would you code that? It seems quite complicated to run an entire set lines of code to initialize the chip, download the data and store the data in the form of a variable. Then, the same core will decide whether to switch or stay closed. Should I do it in a different method? I don't want the chip to double-switch and damage the electronics behind the regulator. I want this to be a measure twice (read:once) switch once, making sure no fatal errors exist.

For PCB design, I want to start out with CAD and slowly learn tips and tricks to improve the layout. I'm pretty sure that the CAD software should work on making sure the CAD software will optimize the layout.

What PCB layout software do you suggest? I could use Eagle, DipTrace Freeware, Fritzing, or Autodesk Autocad Electrical (My student account gives me access to this. However, it is only non-profit!)

The data from the MCP3204 will be so that the Propeller can react to the changes in the stored voltage. Hey, DO you think that it would be wise to have a high-resistance trace between the terminals of the capacitor so that it will self-discharge quickly after the power goes out? That would be a safety measure, though the voltages in the cap bank would be small

Just a random (and stupid) idea: Would it be possible to make a transformer on the PCB?

The reason why I categorized the PIC32 differently is because they have quite a high max DMIPS rating, and they seem like a different architecture to me.

Oh yes, the Chinese stuff! :) I love some of the Chinese stuff because a few products have a high quality and art dirt cheap! What about if I build an ICSP? They aren't too hard to build and I would get some soldering practice, and may even learn how to solder SMT!

Would it be better for me to fabricate the PCB myself or to have it fabricated?

:DI feel like I almost killed my Pi by writing this post on it:D

Joe Johnson 18-12-2013 00:30

Re: Battery powered raspberry pi
 
Phew! We've covered a lot of ground in that post.

How about a new tangent?

Anybody used a Rpi and the 5Mpixel camera to do anything useful on a FIRST robot?

I am thinking FIRST target ranging, but perhaps "find the big red/blue ball" would be useful as well*

If so, do tell.

Joe J.

*it has been a few years since FIRST has had a big ball as a game piece. I suppose it is about time for a game with a big ball - my money is on that or footballs this year

yash101 18-12-2013 07:52

Re: Battery powered raspberry pi
 
Though I don't know any team that has done RPi processing, I'll have to say, the RPi is unsuitable for a high speed robot lie in FRC. It's hard to get the info you need with the lag you get. However, it is much faster than cRIO processing and you may get 2-3FPS!

As with color tracking, if you wrote code like the CMUCam5, he RPi would be the killer machine, capable of many times the framerate. Why don't you try the CMUCam? It may be what you're looking for ;)

techhelpbb 18-12-2013 12:20

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by yash101 (Post 1313991)
The lower voltage won't directly help me. It will help me in the voltage regulator etcetera.

If a transistor, zener diode and some resistors (which is a very simple linear regulator) can be offset effectively by thousands of transistors in an advanced piece of silicon semiconductor < are you sure that's the best trade because the second you need a PCB you'll be designing it anyway.

Quote:

MCUs are just lovely because you can customize them completely and do what you want!
Within reason sure.

Quote:

I think that you will have problems in interrupt-based coding if you are used to multi-core, vice-versa. It's based on what the programmer has experience with.
Well realistically every PC on the planet is interrupt based. So since your first computer has interrupts that leaves room from some that don't. :p

You can always practice interrupts on the PC you used to program the Parallax Propeller.

Quote:

Also, I know that MCUs aren't the best thing to use. FPGAs will still beat them. However, FPGAs will lack behind building the gates yourself and creating a circuit that does NO processing!
No these generalities are not necessarily correct.
The FPGA has the advantage of the gates being close together.
Therefore even if you use the highest speed CMOS/TTL individual logic you can get the FPGA has the gates closer together.
You have more flexibility with ICs instead of the FPGA for example you can get ECL instead of TTL where you want it.

The scientific method and experience will tell you the best choice for the criteria of any solution at a point in time (which impacts what technology is available since you don't make your own semiconductors).

Quote:

MCUs open up a world of simplicity, however, If I program an MCU wrong, I can change the code. However, redesigning a PCB can be a much more expensive process.
Don't make mistakes - less to clean up!
Start off with PCBs you draw with a Sharpie and etch yourself.
There's a kit at RadioShack, ask for it, they usually have it in the back.

Quote:

Compare and contrast this to a 3D printer. These make it possible for anyone to build prototypes without shelling thousands of bucks to a mold. In the other hands, using an injection molding system would mean a higher quality. Just think of an MCU as a 3D printer and an IMS as using transistors to build an autonomous system.
You make compromises to use a 3D printer like that.
You make compromises all the time the key to expertise is to recognize them.

Quote:

Sorry about that. I typically call a Mux by a Multiplexer.
I typed enough without multiplexor and demultiplexor. :yikes:

Quote:

how would you code that? It seems quite complicated to run an entire set lines of code to initialize the chip, download the data and store the data in the form of a variable. Then, the same core will decide whether to switch or stay closed. Should I do it in a different method? I don't want the chip to double-switch and damage the electronics behind the regulator. I want this to be a measure twice (read:once) switch once, making sure no fatal errors exist.
You make a routine to initialize and don't worry about performance.
You optimize a routine to fetch the data using one or more cogs if you need to (hint > the hub switch is sequential so you can read the same input from cog 1 as you can from cog4 < exploit that to reduce the timing and impact of the hub switch timing).
From within the fetching cog(s) find the min/max/average and store the current.
Use another cog(s) to grab the min/max/average and current reading from the hub shared memory (remember within a cog is faster than in the hub shared memory).

You probably want to use a running average to reduce noise so you probably want a way to start/stop/restart that average based on flags stored in the hub shared memory.

Quote:

For PCB design, I want to start out with CAD and slowly learn tips and tricks to improve the layout. I'm pretty sure that the CAD software should work on making sure the CAD software will optimize the layout.
You will quickly discover that autorouters are not the be all and end all of PCB design. An autorouter does not understand the currents in a circuit and usually it can't model the RF characteristics of a circuit. That being said I'd hate to try to layout a 6 layer board with 1,000+ parts by hand.

Quote:

What PCB layout software do you suggest? I could use Eagle, DipTrace Freeware, Fritzing, or Autodesk Autocad Electrical (My student account gives me access to this. However, it is only non-profit!)
Look at Altrium, FIRST used to get you a license for FRC reasons.
http://www.altium.com/en/first-robotics-competition

It is powerful professional software designed to do this job.

Quote:

The data from the MCP3204 will be so that the Propeller can react to the changes in the stored voltage. Hey, DO you think that it would be wise to have a high-resistance trace between the terminals of the capacitor so that it will self-discharge quickly after the power goes out? That would be a safety measure, though the voltages in the cap bank would be small
That's a bad idea because it will have to be a very long copper trace. Use a resistor to bleed a load.
Otherwise you are trying to make a PCB with a characteristic that is otherwise undesirable.

Quote:

Just a random (and stupid) idea: Would it be possible to make a transformer on the PCB?
There are finite limits to transformers on PCBs and I strongly suggest you buy the part if you lack the experience to understand the mathematics involved.

Quote:

The reason why I categorized the PIC32 differently is because they have quite a high max DMIPS rating, and they seem like a different architecture to me.
The PICs are Harvard architecture RISC processors. So yes high clock frequency but generally simple instructions means more instructions to do something that a CISC CPU can do in one but maybe slower.

So maybe a simple problem can run in one instruction at 4 clock cycles at 25MHz on a CISC CPU.
That same problem can run at 10 instructions at 1 clock cycle each at 50MHz on a RISC CPU.
Think it over.

Here, this is worth lots of my typing:
http://eecs.wsu.edu/~aofallon/ee234/...reOverview.pdf

Quote:

Oh yes, the Chinese stuff! I love some of the Chinese stuff because a few products have a high quality and art dirt cheap! What about if I build an ICSP? They aren't too hard to build and I would get some soldering practice, and may even learn how to solder SMT!
There are a few different versions of ISP/ICSP. The process differs between them. Unless you know which chips you are targeting buy the cheap unit so you know it should work. Building something yourself usually works but it can create limitations like being able to program the programmable feature registers.

Quote:

Would it be better for me to fabricate the PCB myself or to have it fabricated?
1. As a student >with supervision< I encourage you to get the RadioShack kit and learn how to make a PCB with a marker.
2. Then with iron on transparency film you can get from eBay or Mouser using a laser printer or photocopier.
3. Then send Gerbers and NC drill files out to a board shop.
4. Then send assembly drawings to an assembly shop.

You can also solder mask yourself but then you need to get more involved.
You can etch and Liquid Tin a board with hobby tools easily.
Please be aware the etchant is an acid and should be treated with respect.

Quote:

:DI feel like I almost killed my Pi by writing this post on it:D
Your Pi is alive? Does it make more Pi?

Quote:

However, it is much faster than cRIO processing and you may get 2-3FPS!
Low frame rate is often adequate enough for a lot of tasks.


Now....for something directly on topic:

How many teams need/want a COTS enclosure with a battery powered computing device in it and which one?

tcjinaz 10-01-2014 00:11

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by techhelpbb (Post 1314162)
<SNIP>
The PICs are Harvard architecture RISC processors. So yes high clock frequency but generally simple instructions means more instructions to do something that a CISC CPU can do in one but maybe slower.

So maybe a simple problem can run in one instruction at 4 clock cycles at 25MHz on a CISC CPU.
That same problem can run at 10 instructions at 1 clock cycle each at 50MHz on a RISC CPU.
Think it over.


Ah, out of respect for your incredibly long trail of informative posts, I am very reticent to try to bring this up, but it is apparent that you are intimately familiar with the classic 8 & 16 bit PIC's, but have not explored the 32bit based products very deeply. Start here for some interesting new products released over the last few years http://www.microchip.com/pagehandler/en-us/family/32bit . Also, there is data about that shows that Microchip products are leaders in memory efficiency in 8, 16 and 32 word sizes.

Plus, stuff like this make for a new world http://www.microchip.com/pagehandler...makes-sen.html I'm trying to figure out how I can plop it (and the associated sensor suite) on a robot.

On another front, I am amused at the argument resurfacing between CISC and RISC, as the technology sways back and forth between CISC (logic quicker than memory access) and RISC (memory close enough to feed short logic paths). A decades old battle; reality settles in the middle. And nearly irrelevant, given modern compiler capabilities.

TJ

techhelpbb 10-01-2014 15:53

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by tcjinaz (Post 1324813)
Ah, out of respect for your incredibly long trail of informative posts, I am very reticent to try to bring this up, but it is apparent that you are intimately familiar with the classic 8 & 16 bit PIC's, but have not explored the 32bit based products very deeply. Start here for some interesting new products released over the last few years http://www.microchip.com/pagehandler/en-us/family/32bit . Also, there is data about that shows that Microchip products are leaders in memory efficiency in 8, 16 and 32 word sizes.
TJ

I don't understand what you mean by this.
The Microchip PIC32 M4K MIPS RISC instruction set is a Harvard architecture (see page 3 of the link from Microchip below).
It also has interrupts.

I have some sitting on my workbench to my right.

http://www.microchip.com/stellent/gr...c/en542879.pdf

As far as CISC/RISC the answer is whatever actually gets the job done as far as I am concerned.
The same is true of interrupts as far as I am concerned.
The rules of thumb (acceptability) here are often a question of popularity rather than science.

Now in fairness - I've yet to find a use for the PIC32 in the projects I have in manufacturing. That does not mean I won't it's just been trumped by customer requirements, size constraints, cost concerns, and knowledge transfer concerns as several other chips I have laying about often are. It has plenty to offer just at the moment it offers more to me than to people I might sell it to (my requirements are always a different matter). So do I know about it yes. Am I a volume customer of the product no.

alex peterson 10-01-2014 17:53

Re: Battery powered raspberry pi
 
This probably isn't the "right" way or the best but it was cheap and worked well... I used a 12v - usb car phone charger and a female car charger port thingy... Worked like a charm and only cost a few bucks...

yash101 10-01-2014 21:56

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by alex peterson (Post 1325187)
This probably isn't the "right" way or the best but it was cheap and worked well... I used a 12v - usb car phone charger and a female car charger port thingy... Worked like a charm and only cost a few bucks...

One thing to remember: You are an engineer, so don't say "This probably isn't the 'right' way". :)

Back on track, a 12v USB plug will be a lovely option because they are meant to run off a voltage this high from the robot battery. They can also handle quite a good amperage, and you'll get them real cheap!

EricH 11-01-2014 00:14

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by yash101 (Post 1325308)
One thing to remember: You are an engineer, so don't say "This probably isn't the 'right' way". :)

On the contrary, he can certainly say that. Particularly because he didn't use the definite, just the probable.

If an engineer says that something isn't the "right" way, he means that it's not the way you're supposed to do it, but it's a way that works--and may become the way you're supposed to do it, eventually. (A lot of R&D starts when someone finds a way that isn't the right way.)

But, that engineer could also mean that it's the WRONG way. In that case, you might want to listen, particularly if he says straight out that it's the wrong way.

yash101 11-01-2014 08:12

Re: Battery powered raspberry pi
 
So anyways,

So we have been powering our pi directly from the PD board's 5V out. It seems to be powering, though I think the SD is corrupt because it is always hard-reset.

techhelpbb 11-01-2014 09:03

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by yash101 (Post 1325459)
So anyways,

So we have been powering our pi directly from the PD board's 5V out. It seems to be powering, though I think the SD is corrupt because it is always hard-reset.

Try disabling any sort of write caching in Linux.
This will force file commits immediately - but it will negatively impact performance.

Alan Anderson 12-01-2014 17:45

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by EricH (Post 1325386)
If an engineer says that something isn't the "right" way, he means that it's not the way you're supposed to do it, but it's a way that works--and may become the way you're supposed to do it, eventually. (A lot of R&D starts when someone finds a way that isn't the right way.).

It's a nitwit idea. Nitwit ideas are for emergencies. The rest of the time you go by the Book, which is mostly a collection of nitwit ideas that worked.
From "The Mote in God's Eye" by Larry Niven and Jerry Pournelle

wireties 12-01-2014 19:05

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by yash101 (Post 1325459)
So anyways,

So we have been powering our pi directly from the PD board's 5V out. It seems to be powering, though I think the SD is corrupt because it is always hard-reset.


You need a way to do an orderly shutdown. Perhaps send a message from the CRio when you transition out of teleop?

yash101 12-01-2014 21:02

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by wireties (Post 1326090)
You need a way to do an orderly shutdown. Perhaps send a message from the CRio when you transition out of teleop?

That's on a testbot, so it won't be used in competition.

I had a wierd idea. Do you guys know about those USB cell chargers? What if we use it on the bot? Wouldn't it be a COTS part?

Otherwise, I thought of a fairly simple idea:

A Large capacitor powers the Pi. That is charged from the robot battery and goes in only one direction because of a protection diode. There won't be a very high voltage (maybe maximum able to give a tingling sensation), so this could power the Pi. Also, it should discharge in no time, down to 0v7, beyond the threshold to electrocute even a foolish person.

Here's a schematic

tcjinaz 12-01-2014 22:42

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by techhelpbb (Post 1325119)
I don't understand what you mean by this.
The Microchip PIC32 M4K MIPS RISC instruction set is a Harvard architecture (see page 3 of the link from Microchip below).
It also has interrupts.

I have some sitting on my workbench to my right.

http://www.microchip.com/stellent/gr...c/en542879.pdf

As far as CISC/RISC the answer is whatever actually gets the job done as far as I am concerned.
The same is true of interrupts as far as I am concerned.
The rules of thumb (acceptability) here are often a question of popularity rather than science.

Now in fairness - I've yet to find a use for the PIC32 in the projects I have in manufacturing. That does not mean I won't it's just been trumped by customer requirements, size constraints, cost concerns, and knowledge transfer concerns as several other chips I have laying about often are. It has plenty to offer just at the moment it offers more to me than to people I might sell it to (my requirements are always a different matter). So do I know about it yes. Am I a volume customer of the product no.

Really lad to hear you're looking at everything. Like I inferred, I learn a lot every time you post. Been too deep in the transistors lately. It's amazing how a "bus matrix" (soon to be "bus fabric") helps marketing show whatever memory architecture they need to sell.


The more important question is how large a production run does one need on a "Pi/Arduio/whatever + shield(s) + battery + enclosure" to qualify as COTS?

Tim

techhelpbb 13-01-2014 05:29

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by tcjinaz (Post 1326213)
The more important question is how large a production run does one need on a "Pi/Arduio/whatever + shield(s) + battery + enclosure" to qualify as COTS?

Tim

As far as I know the requirement for COTS is that you can prove the company that is producing the product is actually at production level, able to fill orders for a realistically large number of customers to be at a production level, answerable for issues with the product and not selling a product targeted only at FIRST. One can't be selling the product targeted specifically at FIRST because if you are using the COTS rule your product is very likely not FIRST specifically approved so therefore it's not in the KOP or the manuals.

I am sure there's a market out there for a ready-made enclosure with battery and loaded with platform of choice beyond FIRST. It's getting more and more unlikely that anyone can prove they are at production volume for this season. You'd have to: open or have a business (it can be done in <24 hours), engineer the product, test the product, put the product up for sale with adequate evidence it's advertised to the general public (it might take 4-6 weeks to get into a monthly periodical so that's out) and finally have sales. Seems pretty unlikely.

How much volume the initial run has to be is probably less relevant to success (where as it would matter to a FIRST approved product) than whether or not the business could meet delivery demands. People might wait weeks for a product like they did for the original batch of Raspberry Pi under the right circumstances. However waiting weeks pretty much ends any chances of working out during the 2014 season.

With 2015 right around the corner - a good question is will FIRST continue with the COTS rule and allow auxiliary computing devices once the RoboRio is the new standard? Will FIRST decide that the RoboRio eliminates the need? Personally I think the RoboRio does not eliminate the need for this rule but that's just my opinion.

Nirvash 13-01-2014 07:08

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by techhelpbb (Post 1326305)
As far as I know the requirement for COTS is that you can prove the company that is producing the product is actually at production level, able to fill orders for a realistically large number of customers to be at a production level, answerable for issues with the product and not selling a product targeted only at FIRST. One can't be selling the product targeted specifically at FIRST because if you are using the COTS rule your product is very likely not FIRST specifically approved so therefore it's not in the KOP or the manuals.

I am sure there's a market out there for a ready-made enclosure with battery and loaded with platform of choice beyond FIRST. It's getting more and more unlikely that anyone can prove they are at production volume for this season. You'd have to: open or have a business (it can be done in <24 hours), engineer the product, test the product, put the product up for sale with adequate evidence it's advertised to the general public (it might take 4-6 weeks to get into a monthly periodical so that's out) and finally have sales. Seems pretty unlikely.

How much volume the initial run has to be is probably less relevant to success (where as it would matter to a FIRST approved product) than whether or not the business could meet delivery demands. People might wait weeks for a product like they did for the original batch of Raspberry Pi under the right circumstances. However waiting weeks pretty much ends any chances of working out during the 2014 season.

With 2015 right around the corner - a good question is will FIRST continue with the COTS rule and allow auxiliary computing devices once the RoboRio is the new standard? Will FIRST decide that the RoboRio eliminates the need? Personally I think the RoboRio does not eliminate the need for this rule but that's just my opinion.

There are a few points in there I wouldn't agree with, but just commenting on the bolded. I don't see how you are getting that definition, how does targeting a product too FIRST teams make it not a COTS item and if it did, then a think a few of the parts FIRST teams take as COTS items, would stop being COTS. As a few retailers do target products to FIRST teams.

techhelpbb 13-01-2014 08:12

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by Nirvash (Post 1326309)
There are a few points in there I wouldn't agree with, but just commenting on the bolded. I don't see how you are getting that definition, how does targeting a product too FIRST teams make it not a COTS item and if it did, then a think a few of the parts FIRST teams take as COTS items, would stop being COTS. As a few retailers do target products to FIRST teams.

Using the knowledge FIRST teams use your product to estimate the demand for your product is not really targeting first any more than estimating the number of people that read a particular periodical. Though it starts to split hairs when the only thing governing your production is FIRST. Really the assumption here is you are in business year round.

Targeting FIRST (in the sense I am stating it and from my perspective) for a product means making the product particularly appealing for FIRST and attempting to limit your production to only what FIRST might need. It also likely carries with it using FIRST resources like the name and/or affiliated websites to advertise.

The COTS rules in FIRST are really limited in scope to electronics. It's not that say a swerve is not COTS in the general sense but you don't need that rule to use a swerve module at all. You do need that rule for electronic items.

So if you going to make an enclosure, with a battery, a charger and some other computing device in it and use it under the COTS rule it would be asking for trouble if: you ever refer to it as the maker like it is specifically for FIRST, ever mislead people that it's FIRST approved by using say the logo, only make production runs based on FIRST usage, make any assurance that it is allowed in FIRST or only do support for FIRST teams.

Sure a team can make a custom circuit and share that circuit with another team. However it's not COTS unless it's really a product anyone (potentially everyone) can buy and it's sort of splitting hairs if it's entirely improbable to find a legit use for it outside of FIRST. However a custom circuit doesn't open the door to the extra battery like a COTS computing device does.

Others may interpret this rule differently. However in my perspective as a business person if I am really targeting FIRST I really ought to get FIRST's approval. In the course of all conversations I had with FIRST about potentially making something like this as COTS I made it quite clear that if I did that myself it would be for sale with no mention of FIRST. If someone from FIRST uses it - that's their choice and not the result of my marketing. Any action I took that would effect FIRST would be no different than any action I would take for any other customer and especially while dancing this line I wouldn't give the product away for free to any team unless I am going to give it to all the teams like via the KOP. Effectively I wouldn't solicit public review from just FIRST relations or participate in such reviews publicly because that's unusual for general products.

Could someone get away with operating on a different understanding of this rule: I am sure they could. I wonder though if they really understand the liability they are creating for themselves.

tcjinaz 16-01-2014 22:53

Re: Battery powered raspberry pi
 
I do think it is time for a definition of COTS from FIRST. I'll get my guys to toss it in to Q&A shortly.

We are in a day & age of 3-D printers and plug & play H/W system development (Arduino et al). Will volume matter? Can the 2CAN from Cross The Road be done for less than $220? Easily, probably at a profitable price and that's why they are out of stock.

What really gets my goat about the CAN thing is that the bloody processor buried down in the FRC cRIO (I & II) has multiple CAN interfaces, but we can't get to them.

The next generation controller gets really interesting, with the controller cores buried directly in the FPGA part. I don't suppose they'll let us program those gates, either.

Just a little rant :)
TJ

Alan Anderson 17-01-2014 09:06

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by tcjinaz (Post 1328357)
I do think it is time for a definition of COTS from FIRST. I'll get my guys to toss it in to Q&A shortly.

What's wrong with the definition FIRST already gave?

Quote:

Originally Posted by the game manual glossary
COTS: a “Commercial, Off-The-Shelf” COMPONENT or MECHANISM, in its unaltered, unmodified state. A COTS item must be a standard (i.e. not custom order) part commonly available from the VENDOR, available from a non-Team source, and available to all Teams for purchase.


yash101 17-01-2014 11:26

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by Alan Anderson (Post 1328433)
What's wrong with the definition FIRST already gave?

Well, one thing is that we have no clue if a COTS (unmodified and off-the-shelf) battery pack will be allowed. Some people think yes it is because it is COTS. Others think no because it is an extra power source ;)

That is truely one thing that FRC will need to clarify to fix all these loose ending.

Until then, before actually putting the RPi on the bot, take out the SD card, run WinDiskImager and create an image of the card. That will save your life in case of a failure! Just prop the card back into the computer and write that image to the card, which you know works!

For code, just create a web server on the driver station. Have a BASH script download all the code every time the RPi boots, and recompile it to make sure it is current, or compare the downloaded code to the old code to see if the downloaded code is newer, same or older!

I think a simple Hash generator and checker should do the job.
Also, remember that a lot of us will not be using the RPi,but something with many times the power. The RPi is only good for regular DIY hacking and development, not for performance. Also, I don't think it has OpenCL support :(. However, I may be outdated with that because I haven't used my Pi in a while!

Alan Anderson 17-01-2014 11:48

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by yash101 (Post 1328469)
Well, one thing is that we have no clue if a COTS (unmodified and off-the-shelf) battery pack will be allowed. Some people think yes it is because it is COTS. Others think no because it is an extra power source ;)

On the contrary, we have plenty of clue. R31 makes it perfectly clear that "Batteries integral to and part of a COTS computing device or self-contained camera" are the only exception. A separate battery back, COTS or otherwise, is not going to pass inspection.

techhelpbb 17-01-2014 11:49

Re: Battery powered raspberry pi
 
Quote:

Originally Posted by yash101 (Post 1328469)
Well, one thing is that we have no clue if a COTS (unmodified and off-the-shelf) battery pack will be allowed. Some people think yes it is because it is COTS. Others think no because it is an extra power source ;)

How is a battery pack any different than a single D battery.
Think about it: the D battery is COTS.
You don't fill it and if it's alkaline you don't have to charge it out of the box.

So since the FIRST rules (as pointed out by Alan while I posted above) only let COTS computing devices with a manufacturer provided battery on the robot (as an integral part) on the field you have less choices.

The idea earlier about the external removable battery so it's not on the robot during the match is a good thing to ask about.

Capacitors skate this.

However FIRST has been quite specific and I think pretty cool about even suggesting that someone outside of FIRST can make a COTS device with the integrated battery and use it on the official field. This makes it possible to fix this and bypass the approval process that could be ripe with other issues.

So really the question is: is there really enough interest in FIRST and elsewhere to fix this mobile robot issue?
If there is then the issues are strictly normal for any business or start-up.
Course I really do think it won't be ready for this season.
So if someone wants to tackle this problem - even if FIRST bans COTS computing devices next year - it would interesting.
The point is to inspire a business in the general sense regardless of whether FIRST buys from it.

Greg McKaskle 17-01-2014 14:27

Re: Battery powered raspberry pi
 
On the topic of goats ...

The Freescale part does indeed have CAN capabilities, and a certain CEO also really really wanted the CAN capabilities to be exposed in the industrial version of the product. But release deadlines don't always allow things like that to happen. For industry, CAN is also available through FPGA IP and a module, but this would have cut into other FPGA features. It was discussed and the group decision was to achieve CAN via serial or enet bridge. It certainly isn't ideal, and this is far improved in the new controller.

The FPGA of roboRIO is reprogrammable. I'd personally love to see well-mentored teams play with it in the offseason. Good ideas from this could be incorporated in the official image. At the moment, we don't have a good technical ability to combine the closed and open portions of the IP into the same FPGA. Safety is the top priority, so it is expected to remain closed for FRC robots until we are able to do both.

Greg McKaskle


All times are GMT -5. The time now is 03:31.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi