SatanicEngineer
Posts: 4
Joined: Sat Apr 29, 2017 5:23 pm

I think I got the wrong device!

Sat Apr 29, 2017 7:42 pm

Hey all.

The problem here is, there's simply not enough free time in the universe.

I wanted a generic risc devboard with a bit more power than an Arduino Nano (or even Mega) used specifically for analog sampling rate in an embedded industrial controls type environment. (non-life support, non-critical, non-redundant - failure won't kill anyone or allow anyone to die.) I just would like something where processing an instruction didn't take 1mS.

I picked the Zero W based on form factor alone. I expected roughly the same kind of board as a Nano but faster proc. Oops! These Pi0Ws are linux laptops running an rtos! I mean, OTG USB ports?! HDMI w/ EDID!? :shock:

Again, it's down to free time. I'll try to allocate a few (hundred?) hours learning what I & it can do, I mean I've been a linux engineer for going on two decades, I'm sure I can have lots of fun with this... but for my current requirements, it seems it's gross overkill. I'll assume with GPIOs and a 1GHz processor, implementing a emulated delta\sigma DAC in software for a sampling rate of a 10 or 20 thousand hertz will be something it can do in it's sleep.

I agree with Eben's comment re: drooling over - and in my case having a personal dilemma over using "borrowed" Acorn Archimedes that fell off a truck - that I immediately want to d/l the Riscos image first before raspbian. The circle is now complete. But I have a feeling I'll have half a dozen sd cards next week.The fact I need a mouse and a display directly on the board I'm flashing is kind of freaking me out... but I'll get over it... instead of developing FOR a device, I'll develop ON the device. It is definitely a shock to the system.

OK sorry for the ramble.Three basic things:

I have yet to find an actual datasheet for the thing! Do they not exist? Every single component & IC made has a detailed datasheet, specs, mounting pattern, mechanical & temperature tolerances, etc. Where? Does it not exist? Is there at least a page anywhere with a link to each components' individual datasheet? And what about the RP PCBs themselves? ie. Are there a pads for the individual JTAGs, or just the ARM? Inquiring minds want to know!

Secondly, along that vein, how much low level access do we have to the BCM2835 / ARM11 via the rtos? Is there a table of what's abstracted vs what's directly accessible? If I build an ARM image in Eclipse or embedded and flash it, can I make this into a generic risc devboard? I would love to peruse the bootstrap code, but here we are with that time constraint again. Has anyone done non-Raspberry stuff to them? Obviously that moves outside the spec of Raspberry Pi forum and probably isn't discussed here, but I'd appreciate a link if another site exists. (does anyone know what happened to Broadcom's Android development??)

And lastly, wrt: the built-into-the-copper WiFi/BT antenna by Proant, has there been any testing about radiation pattern, interference both given and received, reflection/cancellation/attenuation levels of metal chassis or deeply embedded applications - under, say, a cluster of crossing 4"+ iron steam pipes? Granted I know this is hobbyist and DIY, and the boards' availability is still measured in weeks... but stuff like that will be important to many. (edit: found many articles about adding an external antenna should this one prove inadequate, and a datasheet at Proant, although it's about the tech and not specifically the Proant Niche antenna. Obviously this is their moneymaker and they're not giving out anything too proprietary. http://www.proant.se/files/user/Documen ... -08-23.pdf )

I think I bit off more than I can chew, currently. But I do look forward to getting to know you guys over the coming weeks/months/years. :-)

Thanks in advance for any assistance, and just reading me gushing.
Damn this thing is cool.

W. H. Heydt
Posts: 11062
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: I think I got the wrong device!

Sun Apr 30, 2017 2:08 am

Welcome to the forums.

Taking one of your last points first (WiFi output), the Pi0W passes FCC and CE testing criteria, so it should be whatever those require. If you *don't* want the on borad WiFi, there is the Pi0, which costs even less.

On more general topics... No Pi has A/D converters. You *might* be able to figure out a way to do it in software, but better would be external hardware--and then you can get pretty much whatever sampling rate you want. If you want real time then you're more likely to want RiscOS than Raspbian (and you sound like you know enough to deal with that). You may also be interested in poking into the Bare Metal Forum which should give you data using a Pi as if it was more like an Arduino.

Yes, the Pis (even the Pi0 and PiW, despite their form factor) are general purpose computers, not microcontrolers. General advice is to start out with the current "top" model (the Pi3B as I write this) and then decide if some other model better fits your specific project. Again...your skills may put you beyond that advice.

The major closed area of the Pi is the VC4. Quite a bit of the interfaces have been published, but not the internals. One of the reasons this would matter to you is that, when a Pi boots, the VC4 boots *first* and later in the process loads a kernel and turns over control to the ARM CPU(s). The bare metal folks can give you far more information on how to deal with this than I can.

If your project is a "one off" or a small number of units, you'll probably be okay with the Pi0W/Pi0. Both boards are still at a "one per order" stage due to an imbalance between demand and supply. If you need either a lot of boards, or an on-going reliable supply, you might take a look at the CM or the CM3/CM3L boards. The CM uses the same SoC as the Pi0/Pi0W where the CM3 and CM3L use the SoC from the Pi3B. All varieties of CM have minimal packages on the board (SoC, memory, and eMMC flash--on the CM and CM3 only) and require a "carrier" or "I/O" board to expose the peripheral interfaces a given project needs. There are dev boards--CMIO and CMIO3--to aid in developing CM-based projects.

Hope that helps, at least a little.

gregeric
Posts: 1509
Joined: Mon Nov 28, 2011 10:08 am

Re: I think I got the wrong device!

Sun Apr 30, 2017 7:00 am

An ARM microcontroller may be better suited. You can get up to speed very quickly if you choose one which is mbed compatible: https://developer.mbed.org/platforms/ There are some in form factors similar to the Zero. Be careful to selet one which has the ADC or DAC capabilities which you require, built in. The STM Nucleos are around £10, likely what you will spend anyway adding ADC/DAC to the Pi.

The Zero can be used very nicely in conjunction with the mbed: when connected by USB the mbed device will apper as composite mass storage plus serial. Hook it up to the ZeroW & you'll be able to reflash it remotely & communicate with it over the serial link.

User avatar
Gavinmc42
Posts: 4016
Joined: Wed Aug 28, 2013 3:31 am

Re: I think I got the wrong device!

Sun Apr 30, 2017 8:02 am

If you want to use a Zero get a B+ to develop on.
Zero W get Pi3 as it has WiFi too.
Zero's are a bit painful to develop on, maybe I'm spoiled having the Ethernet and ssh to remote access/develop.

A Pi3 makes a reasonable desktop.

You don't have to use Raspbian on Pi's, a small Linux OS like PiCore works fine.
Don't want Linux, look on the baremetal posts, the sticky has plenty of links.
I mostly use Ultibo these days, a custom version of Lazarus/Free Pascal. DIY OS sort of.

If the Zero W WiFi antenna is an issue, use an A+ and add USB WiFi dongle.

If you have no spare time, I suggest you bury it in the backyard and forget the existence of Pi's.
They are addictive, you can't stop at one :lol:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

SatanicEngineer
Posts: 4
Joined: Sat Apr 29, 2017 5:23 pm

Re: I think I got the wrong device!

Sun Apr 30, 2017 9:30 pm

W. H. Heydt, thanks! Yes, helpful. And thanks for reading and not just a scanning, I appreciate it! The main reason I wanted to try this, is the wifi for sensor reporting. Even using a full protocol stack like tcpip and .11n I figured I could get a wireless sensor w/ 10Hz reporting rate easily... but I'm going no need a tonne of external components to implement what you can do on a more generalized uC with only passives and a few lines of code. I know it's the wrong device, but now I'm curious. (Curiousity killed the free time.)

Gregeric, I will look into that. Just a quick search turns up others in my 'boat' so to speak... thanks. Might be best help ever!

Gavin, you seem very knowledgable about these things, I look forward to picking your brain later. However I'm more into traditional uC development, where you code in a proprietary dev set if tools or IDE, flash the prototype, test, debug, flash, ad naseum... these things are literal multithreaded computers, and quite complex compared to basic single-task micros. The overhead of all the unrelated non-task-specific bits, I mean the modular device driver structure alone! These things are full-on computers! I'm sure they make neato media players with a screensaver, but I'm less sure how they perform when uS precision timing is required, or where an interrupt MUST take priority over everything including any UI component, is questionable. (I am familiar with linux scheduling.) I'm assuming it's all done with device driver code. Seems nearly every kind of interfacing will require a daughter circuit; they're not really intended for native access to circuitry. Something digital and established, say I2C, SPI, etc. more work, more components, more cost. For example, a scanning button matrix for input using 4+ pins, vs. just plugging in a USB wireless dongle or hardwired PC104 keyboard... You don't have to add hysterisis or debounce code, the keyboard itself will handle usb handshake and all input control. The keyboard driver handles the interrupt and handoff to the input subsystem. If said keyboard sends a button press, you have high confidence a button press occured. 'Regular' uC development is different. (Not sure regular is appropriate.)

Same for displays, in the hobbist world you can spend $20 on a single 4" TFT LCD panel w/ digitizer pulled from retired phone inventory... that is the absolute worst thing any engineer can do, and might cost someone a black eye as well as a pink slip. So not only is this "too developed" in terms of microcontroller, it's simply not the right tool for the tank. SSH? Pascal and other high level languages?! A UI Desktop? Ahhhhh.. it's a PC! ;-)

Thanks for the replies!

User avatar
kusti8
Posts: 3439
Joined: Sat Dec 21, 2013 5:29 pm
Location: USA

Re: I think I got the wrong device!

Mon May 01, 2017 12:08 am

The typical way to program for the Pi is to just have Linux installed and transfer a project and then compile it. Then run it and it works. You can get pretty good accuracy, but since it's not a microcontroller it is never going to reach that accuracy. Usually you take a Pi when you need something with more power, something with more support using libraries (since it is just Linux there are so many things out there) or something with a UI or something like that. It takes a bit of getting used to.

I started at the other end, I started with the Pi and have been making my way into microcontroller just because they come with a Adc, but more complex things later. If you don't need bit accuracy, the Pi is much more powerful. Very many people don't need a RTOS with the Pi.
There are 10 types of people: those who understand binary and those who don't.

User avatar
Gavinmc42
Posts: 4016
Joined: Wed Aug 28, 2013 3:31 am

Re: I think I got the wrong device!

Mon May 01, 2017 2:07 am

It looks like it is too late to warn you off these things :lol:
However I'm more into traditional uC development, where you code in a proprietary dev set if tools or IDE, flash the prototype, test, debug, flash, ad naseum... these things are literal multithreaded computers, and quite complex compared to basic single-task micros.
Which is why after 5 years learning Pi's and Linux I was very, very happy to find Ulitbo.
It works as a traditional IDE, but it has multicore and multitaking built-in, so I can learn that outside of Linux, whew.
And it even does Aarch64 QEMU :o

Swap the SDcard and it is full Raspbian Desktop PC. Actually a Ultibo kernel.bin can run from same card, just edit config.txt :lol:
uS precision timing is required, or where an interrupt MUST take priority over everything including any UI component,
Well it is an VC4 with attached A series ARM cpu, better use a R series if you want real time.
Tricky timing stuff I have not yet figured out how to do on the Pi I can do on a tiny 8pin PSoC micro controlled via the i2c.
But the Pi's CPU does run ~1GHz, should be able to use that speed for something.

The hardware on the Pi like timer/counters is basic but no one has really used them much yet.
I only just found out about GPCLK0/1/2, which could be useful. Then there is FIFO/DMA, hidden i2c's in the SPI hardware.
Weird serial uarts, PDM, PCM, SMI, most with minimal datasheet info and examples, any example likely to be in Linux.

Traditional uC stuff gets expensive once you want to add connectivity like Ethernet which is why I first used Pi's, plus I got HDMI for free, down side was learning Linux and the babel of languages that run on it.
Let's just say I know Linux better than DOS or Windows now, not sure how all that learning can fit in my tiny brain.
You can extract as much as you want, it oozes out of my ears these days :lol:

WiFi now has all those ESP8266 chips/modules and their new bigger cousins. Might have to earn WiFi too, but wait, I have Pi3's and a Zero W now. Never really liked WiFi for sensors, too power hungry, rolled out a mesh network years ago.
Long range Bluetooth looks possible, but LoRa is now my preferred RF sensor method, but I only do 1-5minute updates to save power. 10hz? Many options just no 1 year batteries ;)

The Display situation is MUCH better than it used to be, nowhere near what it could be yet.
We need a bunch of real plug n play DSI displays, from 0.5" to 14". There is a market there, we don't have to use Arduino LCDs. DPI TFTs are looking easier to use, just don't expect many I/O to be left

That 40 way header on the Pi's means daughter or motherboards are simple, most of mine are even single sided.
I do have an advantage in that we have our own PCB making facility.

Embedded ARM's, Cortex M0's are so cheap now, M3, M4, M7 all useful little gadgets.
Lazarus/FPC can compile for some of these, Ultibo could be the IDE if the hardware stuff is ported.
OpenOCD, OpenJTAG interface to the micro's? Well there is a JTAG footprint on all Pi's.
Not only does OpenOCD run on Pi3, your could use Pi's to bit bang JTAG to other micro's or Pi's.

With Ultibo I can already remotely upgrade the kernel.bin but recently I think now I can upgrade any connected uC that does the timing/control stuff :o

Now your Analog sampling requirement, i2c will do 16-24bit 10hz no probs, even 100hz.
Faster than that and SPI is better. Number of bits and sample rate?
The control stuff can be off loaded to a uC, it is the comms stuff the Pi is good.

Trying to do control and comms in a single uC?
Well look at the latest IoT uC chips like PSoC6, it has two cpu's, M4 plus M0.
It is now easier to add cpu cores to silicon, letting you choose what does control and comms.
Pi2/3 have multicores, one core for comms, one for control, leaving two for redundancy?
Latest tablet/phone chips have big.LITTLE cores now.

Multicore uC are the future. a 64bit ARMv8A A35 core is 0.4mm square, that's cheap realestate on a piece of silicon.
Have you tried writing code for a single uC that does everything?
Takes a long time to verify it all works and testing is crazy.

Pi2/3 are nice cheap multicore hardware to learn this stuff on.
With Ultibo no Linux gets in the way, it is only just over a year old, but it will take me two years to learn the stuff I want to learn on it.
instead of developing FOR a device, I'll develop ON the device. It is definitely a shock to the system.
It still does my head in, I can remote ssh into a gadget from a 100km away and edit/change some running shell script on the fly and it still works. Linux shell is ok for slow stuff, collecting data every few minutes etc and it is reliable, still got stuff running after years.
I use piCore for this Linux, smaller, easier to maintain.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

SatanicEngineer
Posts: 4
Joined: Sat Apr 29, 2017 5:23 pm

Re: I think I got the wrong device!

Mon May 01, 2017 3:32 am

It looks like it is too late to warn you off these things :lol:

heheh you are correct there, sir. I think that ship has sailed - then caught fire, then sunk, then left me on a cobbled-together raft with a bloody-handprint volleyball. Even though it's an insanely ludicrous overkill device for what I need, it's also not remotely useful for the purpose I sought it for. I doubt it can do what I need without external hardware. But nonetheless the proverbial bug had bitten. Damn it.

re: timing, it's not just the absolute timing I worry about, but scheduling. when the uC itself isn't controlling something but waiting on it, it can get complicated... you can't interrupt interrupts (lol) but we can usually suspend processing them... but even then, technically there's no realtime processes on a scheduler with 1000 ticks, as this is still only 1mS and where I am now. But a user-mode linux that's got umpteen control registers, shared memory for I/O, every freakin driver and kernel module and other non-user executable just makes it worse.... wanting realtime, especially accurately measured 100s or 10s of uS, seems it is either custom and beyond the scope of normal Pi use, or requires the use of some additional circuit do to the timing accurate stuff and the Pi will just take the "reports" of the task. So instead of the Pi0W I just need that additional circuit, and a wireless way to report status. And we're back. This is how I got here. Oy.

re: PCBs I can etch but with so much these days being smd/smt only? Some of the smaller bits are getting beyond my shaky hands. It's getting bad for garage DIY in general in the last 10 especially. Well, unless your garage has a PID'd toaster oven for a reflow oven, and one of those X/Y/Z Chinese budget laser etchers working as a pick-n-place machine... not to mention that every IC is so damn high-speed, point-to-point wiring much less breadboarding causes nearly everything to oscillate unless you are extremely careful. Not to mention our favorite gremlin, parasitic capacitance!

Anyway, could someone point me to the datasheet? You guys kinda skipped over that. So I'm guessing maybe there's not one. Can I pester you to answer the basics about, for example, the GPIO pins? min/typ/max voltages? how much can they truly sink / source? 4-16mA settings are set in stone or have 20% leeway? Same for input mode, if you exceed 10mA does it catch fire? are they free-floating or tied high / low at reset and can you change that? and, what does an overload condition do, fry that processor line or fry the whole thing, or? etc. etc. etc.

So far my best guess is the documentation @ ARM for the ARM1176JZF-S, but technically that's not the Broadcom version... still not all the data I'd want. I've found some useful things from the forum too, but why isn't this all in one thread called "specifications" or something!? If RP isn't going to help you, and you guys have had to do it yourself, we should at least harass a design team engineer to put that stuff up!!

Again, thanks for your time guys. I know newbies can be annoying, asking tons of random stuff and rambling. :-)
I don't want this thread to get too far off topic so if I have specific technical questions I'll make proper thread(s).

SatanicEngineer
Posts: 4
Joined: Sat Apr 29, 2017 5:23 pm

Re: I think I got the wrong device!

Mon May 01, 2017 3:44 am

@ WH Heydt: between baremetal subforum and the github, I've got my reading materials for the next week. Thanks again!

User avatar
Gavinmc42
Posts: 4016
Joined: Wed Aug 28, 2013 3:31 am

Re: I think I got the wrong device!

Mon May 01, 2017 4:54 am

You don't need a manual just use the Linux driver :lol:
The Peripheral manual is about as good as it gets, some more data is scattered around, like an Easter egg hunt.
And there is stuff in there that may or may not be used by the VC4 in ThreadX or ARM in Linux, huh!

Welcome to the world of minimal documentation.
Good luck figuring out the ISP (Image Sensor Pipeline).
Some of the fun and pain of using these things is digging out the secrets.

Yep, most of the new chips/sensors I want to use these days are LCC, CSP or micro BGA.
We all have microscopes on our desks, standard equipment now with the superfine soldering iron tips.
Still looking for a low price desktop Vapour reflow setup.

In the muliticore Pi's each Arm core has a local timer, I have a theory this could be used for a RTOS.
The only example that makes sense to me so far is the Ultibo Multicore example, not even going to bother doing this under Linux. My brain only has a small amount of room left :oops:

You are pretty much up to speed as the rest of us now.
8,16ma for I/O is not bad, if you found that you have been looking ;)

As for a real datasheet, I suspect it would be thousand of pages long and I don't think any one person could do it.
There is also propriety IP in the chip that RPF don't own and so are NOT allowed to tell anyone :(
A full data sheet would probably have to come from Broadcom anyway and they are far too busy and don't want to give away expensive IP either.

So you will have to learn how to work the Pi with a blind fold on with little peaks now and then.
You can still do a bit of other stuff with them even with one hand tied behind your back :lol:
And I can ramble on about Pi's and anything else much, much longer :lol:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Return to “Beginners”