64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I am chewing on all the responses. The ultimate would be to have each of many eyes tracking a person, and that means each one moving ever-so-slightly so that they track perfectly. One motor could probably rule them all. Vibration is definitely the easy way out. I had figured for that, I could just slide in an old cell phone running something that makes it vibrate a bunch. I should probably look up getting cheap, little motors though. I have not looked that up in awhile, and I guess that has changed.

I had thought about something with magnets, but that's definitely not my forte. I believe my front door is in a metal sandwich, so I can do some stuff with that. I have to see if a fridge magnet or whatever sticks to it to tell if it might get in the way. I would just figure that magnets of that intensity would interfere with the stuff controlling it. We don't really expect much for trick-or-treaters though; we'd mostly do it in the lead-up to Halloween for people visiting.

# ? Sep 26, 2014 21:11

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 03:10

Tiger.Bomb: Jan 22, 2012

http://www.dhgate.com/product/50pcs-lot-low-power-4mm-x-8mm-vibration-pager/182764201.html#s1-3-7|4234868050

# ? Sep 27, 2014 01:53

JessKay: Oct 16, 2011

Internet Janitor posted:

Spatial:

The really key invention in Forth is the use of a dual-stack architecture. One stack stores return addresses for subroutine calls and the other is used as an argument-passing mechanism for subroutines. By disentangling these you can eliminate the need for "stack frames" and a good deal of the bookkeeping involved in subroutine calls with a C-style calling convention. This ends up both simplifying the compiler enormously and reducing the complexity of your bytecode. The stacks don't have to be particularly large, either- 10 to 20 words of memory each is sufficient for fairly complex embedded applications.

Humour a relative newbie to low-level anything here - what is it about the difference between single-stack/C-like and dual-stack calling conventions that allows you to avoid stack frames in situation where single-stack couldn't?

(If I'm understanding right, you could avoid them with just one stack if you use something akin to continuation-passing style - i.e., the useful-to-you parts of the stack frame become explicit arguments - but I'd assume that's not what's going on with dual-stack. Not least because doing the transformations to CPS would make a compiler more complex unless it uses a language that already does CPS.)

JessKay fucked around with this message at 21:11 on Sep 28, 2014

# ? Sep 28, 2014 21:07

JawnV6: Jul 4, 2004; So hot ...

I have a BT radio paired to a phone. I have a WiFi radio. The phone is on the local WiFi. How ddo I get the wifi credentials from the phone to the device?

# ? Sep 30, 2014 18:31

Spatial: Nov 15, 2007

Embedded development can be hella stressful. Committing code to ROM... forever. :stare:

It's my first time doing it and I reaaalllly don't want to make a mistake.

# ? Oct 13, 2014 12:06

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Spatial posted:

Embedded development can be hella stressful. Committing code to ROM... forever.

It's my first time doing it and I reaaalllly don't want to make a mistake.

What's your validation testing like?

# ? Oct 13, 2014 12:51

qsvui: Aug 23, 2003; some crazy thing

Does it make sense to hit the watchdog from inside a periodic interrupt? Dynamic C (version 9) seems to do this by default and I just find this bizarre.

# ? Oct 18, 2014 04:27

No Gravitas: Jun 12, 2013; by FactsAreUseless

qsvui posted:

Does it make sense to hit the watchdog from inside a periodic interrupt? Dynamic C (version 9) seems to do this by default and I just find this bizarre.

Maybe I'm stupid but this seems like a really bad idea. What if some important thread is hung? The interrupt happens, the dog is fed and you go back to being hung with no one being the wiser.

I would usually feed the dog in the main work thread between work items or something. If no work items are available then schedule an interrupt for a fake work item that would do nothing.

No Gravitas fucked around with this message at 19:31 on Oct 18, 2014

# ? Oct 18, 2014 04:33

carticket: Jun 28, 2005; white and gold.

I wrote a software watchdog that worked by kicking the hardware watchdog from an interrupt. It had multiple watchdog channels, each with individual timeouts. The interrupt basically did the software checks for kicks from the application tasks, and kicked the hardware watchdog if all task channels were up to date. In the event that one fell out of date, it simply let the hardware watchdog trigger the reset (which could be detected at startup).

I can't think of another reason to do it in an interrupt unless there's some weird configuration, but even then it sounds like it is setup to monitor to health of the periodic interrupt. Maybe there's a chance the handler can lock up?

# ? Oct 18, 2014 06:30

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

I always called it "feeding" the watchdog because I like dogs and I imagined it barked because it was hungry ;_;

# ? Oct 18, 2014 13:52

yippee cahier: Mar 28, 2005

in my shop we tickle dogs.

# ? Oct 18, 2014 17:05

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

qsvui posted:

Does it make sense to hit the watchdog from inside a periodic interrupt? Dynamic C (version 9) seems to do this by default and I just find this bizarre.

As a rule of thumb, kicking the watchdog from a periodic interrupt defeats the whole point of having a watchdog. I'd be pretty nervous if one of my coders did that in a project I was overseeing.

I guess having a 'smart' multi-source watchdog routine does make some sense, but only as long as you disable new interrupts during the span of time that you're servicing your watchdog. Then if your watchdog service routine freezes or crashes due to a bug, you can still get the reset.

If you do go that route though, I'd recommend a full unit-test suite for your watchdog routine.

# ? Oct 20, 2014 10:08

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

I was adapting some code today that was written to work with TI's ADS1246 ADC (we're switching to a different delta sigma), and most of it (written by a guy who left about two years ago) looked fine...

code:

/* addresses */
#define ADDR_MUX0                 0
#define ADDR_VBIAS                1
#define ADDR_MUX1                 2

...

//-------------------------------------SPI Commands--------------------------------------
#define CMD_WAKEUP            0x00                                   
#define CMD_SLEEP             0x02
#define CMD_SYNC              0x04

...

#define CMD_SELFOCAL          0x62

#define CMD_NEVER_EVER_SEND_THIS_COMMAND_OR_ELSE   0xF1   //yep, honestly, see the datasheet

...

#define RorW_THREE_REGISTERS       0x02


//----------------------------------Initial Values to be placed in registers
#define BSC_INIT              0b00000000    //burn out current source not enabled (default after
//reset so this does not need to be transmitted
#define VBIAS_INIT            0b00000000    //bias not enabled (default after reset so this
//does not need to be transmitted

...

Wait, what?!

code:

#define CMD_NEVER_EVER_SEND_THIS_COMMAND_OR_ELSE   0xF1   //yep, honestly, see the datasheet

Wonder what this could be about :

Hrm. Wonder what TI uses that command for. Verification, maybe?

# ? Oct 23, 2014 18:54

JawnV6: Jul 4, 2004; So hot ...

I've seen example TI code that hits up undefined registers. The datasheet just didn't mention them, they weren't called out explicitly like that. Haven't gotten as far as the replacement code on a different micro running, but I'm curious to see if they're actually required or not.

Maybe it blows up counterfeits.

# ? Oct 23, 2014 20:26

EpicCodeMonkey: Feb 19, 2011

It's likely a test command; at a previous silicon manufacturer I worked at, there were undocumented test commands to adjust internal module parameters, MUX out internal signals and the like. Some of them are used during the manufacturing stage, the others are for fault analysis during silicon verification or later errata discovery.

# ? Oct 25, 2014 04:51

My Rhythmic Crotch: Jan 13, 2011

Goddamn, the ecosystem for the Beaglebone Black is a mess. Trying to get some device tree overlay stuff to work is really annoying. The device tree compiler appears to be completely different and have different syntax formats depending on what distro you're running :wtf:

Edit: also appears the addresses the IO gets mapped to has changed at some point over the past several months as well... great!

My Rhythmic Crotch fucked around with this message at 20:09 on Nov 2, 2014

# ? Nov 2, 2014 19:32

hendersa: Sep 17, 2006

My Rhythmic Crotch posted:

Goddamn, the ecosystem for the Beaglebone Black is a mess. Trying to get some device tree overlay stuff to work is really annoying. The device tree compiler appears to be completely different and have different syntax formats depending on what distro you're running

Edit: also appears the addresses the IO gets mapped to has changed at some point over the past several months as well... great!

Yeah, all of the existing documentation is for the 3.8 kernel with the capemgr. The powers that be are pushing forward to the 3.14 kernel, which is now patched with that new generic system device tree system that involves the kernel trying to enable as many features on the P8/P9 headers before running into conflicts. Personally, I am pushing on with the 3.17 kernel and porting patches as needed. It doesn't give you capemgr again, but at least the dynamic overlay support is now in the Linux mainline.

For dtc, I apply the patch from Robert Nelson to the dtc source and use that for compiling overlays. I've never used the default dtc that comes with a distro because those are all over the place.

I have not experience any changes in the IO address of registers, though. Are you referring to the change in the address ranges within the u-boot uEnv.txt? Those are spread out a bit more to make room for the new, bigger initrd.

# ? Nov 2, 2014 20:38

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

I'm going to have to write an Amlogic DRM driver soon. The kernel that Amlogic gives out is garbage.

# ? Nov 2, 2014 21:08

My Rhythmic Crotch: Jan 13, 2011

hendersa posted:

Yeah, all of the existing documentation is for the 3.8 kernel with the capemgr. The powers that be are pushing forward to the 3.14 kernel, which is now patched with that new generic system device tree system that involves the kernel trying to enable as many features on the P8/P9 headers before running into conflicts. Personally, I am pushing on with the 3.17 kernel and porting patches as needed. It doesn't give you capemgr again, but at least the dynamic overlay support is now in the Linux mainline.

For dtc, I apply the patch from Robert Nelson to the dtc source and use that for compiling overlays. I've never used the default dtc that comes with a distro because those are all over the place.

I have not experience any changes in the IO address of registers, though. Are you referring to the change in the address ranges within the u-boot uEnv.txt? Those are spread out a bit more to make room for the new, bigger initrd.

Oh, that might explain some of it. I'm running 3.8.13 right now... no telling what mix of stuff I have. That's frustrating that there appears to be waffling on the capemgr, but not surprising.

Regarding the memory addresses, I'm referring to the base address that the GPIO gets mapped to:

code:

head /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (44e10800): mmc.11 (GPIO UNCLAIMED) function pinmux_emmc2_pins group pinmux_emmc2_pins

So it appears the start address is 0x44e10800, which is different than I'm seeing here.

# ? Nov 2, 2014 21:27

hendersa: Sep 17, 2006

My Rhythmic Crotch posted:

So it appears the start address is 0x44e10800, which is different than I'm seeing here.

0x44e10800 is the address of the pinmux kernel driver. It is described in the device tree in arch/arm/boot/dts/am33xx.dtsi. If you want to mmap() /dev/mem to directly access the GPIO control registers, that isn't the address you want. Use the same base addresses of the MMIO registers (the same as what is described in that code you linked): 0x44e07000, 0x4804c000, 0x481ac000, and 0x481ae000 for GPIO0-3, respectively. The 3.8.13 kernel device tree is off by one on the descriptions of the GPIO banks, so the entries for those four are in the same am33xx.dtsi file at gpio1-4. This is fixed in the later kernel branches to be gpio0-3 to match the TI docs. If you aren't referring to the GPIO banks in a device tree overlay, though, don't worry about the mismatch.

Only the GPIO1 bank has an active clock by default. You'll get SIGBUS errors if you access the other three banks. Use the pinmux driver to active the clocks of the other banks by exporting at least one pin from each of the other three banks:

code:

$ sudo echo 5 > /sys/class/gpio/export
$ sudo echo 65 > /sys/class/gpio/export
$ sudo echo 105 > /sys/class/gpio/export

Check out a recent discussion on this here.

# ? Nov 2, 2014 23:02

My Rhythmic Crotch: Jan 13, 2011

Thanks for the excellent crash course

Some company needs to pay you a bunch of cash to make this kind of information easily available, because the documentation as it stands now is very scattered.

I also looked at libpruio, and it does look cool, but it also appears to magic a lot of things away.

My Rhythmic Crotch fucked around with this message at 04:23 on Nov 3, 2014

# ? Nov 3, 2014 04:19

hendersa: Sep 17, 2006

My Rhythmic Crotch posted:

Thanks for the excellent crash course Some company needs to pay you a bunch of cash to make this kind of information easily available, because the documentation as it stands now is very scattered.

I also looked at libpruio, and it does look cool, but it also appears to magic a lot of things away.

Trying to keep track of all of that content is a constant game of whack-a-mole. I try to keep on top of it, but it is changing as the platform continues to mature. We have to move through several "stable" iterations of the kernel and OS environment before we end up with something that everyone will be happy with. Personally, I suspect we will reach that point when we're in the 3.17 kernel with Nelson's Debian distro, SGX support for OpenGL ES, and the capemgr is back. For now, the 3.14 kernel is becoming the next island of stability in the grand scheme of things.

We have quite a way to go. :sigh:

I have not explored libpruio, but it gets a lot of people started in the right direction, so that is good, right? I hacked together my own memory-mapped GPIO support last year sometime, so I've been doing my own thing (https://www.youtube.com/watch?v=s-uUjF76ZDM) and haven't looked at how good these other interfacing libraries are put together on the inside.

# ? Nov 3, 2014 16:25

My Rhythmic Crotch: Jan 13, 2011

Have high speed GPIO, 2.8MHz. Hurray.

Edit: hendersa, do you know essentially how /dev/mem works? Is it sort of virtualized or protected, so that one process cannot modify memory belonging to another? I wonder if the GPIO bandwidth is limited by hardware or some kernel construct (such as virtualization/protection) of the memory interface. None of this is for my job btw, I'm just tinkering.

My Rhythmic Crotch fucked around with this message at 05:30 on Nov 5, 2014

# ? Nov 5, 2014 05:17

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

My new job is making a DRM driver for Amlogic, and the vendor source dump is a horrible incomprehensible fbdev driver. This will be fun.

# ? Nov 5, 2014 05:35

movax: Aug 30, 2008

My Rhythmic Crotch posted:

Have high speed GPIO, 2.8MHz. Hurray.

Edit: hendersa, do you know essentially how /dev/mem works? Is it sort of virtualized or protected, so that one process cannot modify memory belonging to another? I wonder if the GPIO bandwidth is limited by hardware or some kernel construct (such as virtualization/protection) of the memory interface. None of this is for my job btw, I'm just tinkering.

You running a RT kernel?

# ? Nov 5, 2014 06:42

hendersa: Sep 17, 2006

My Rhythmic Crotch posted:

Have high speed GPIO, 2.8MHz. Hurray.

Edit: hendersa, do you know essentially how /dev/mem works? Is it sort of virtualized or protected, so that one process cannot modify memory belonging to another? I wonder if the GPIO bandwidth is limited by hardware or some kernel construct (such as virtualization/protection) of the memory interface. None of this is for my job btw, I'm just tinkering.

/dev/mem is the physical memory of the system. You can access whichever pages of virtual memory are currently present in physical memory, including pages for other processes, and any memory-mapped IO registers. This is why access to /dev/mem is restricted to superuser processes. If you have access to it, you can go crazy changing all sorts of stuff. Be careful with it.

You're starting to brush up against the limit of GPIO toggle speed from user space. You can go faster with accessing GPIOs from the PRUSS (about 4MHz, I think) unless you change the mode of the GPIO pins to make them PRU pins. You're currently muxing your pins into mode 7 to make them GPIOs. There are a subset of GPIOs that you can mux into modes 5/6 on both P8 and P9 for high-speed PRU access from PRU0 and PRU1. That will allow you to toggle at the PRU's 200MHz clock speed, which is a transition state once every 5ns (creating a 10ns period and 100MHz frequency). But, you have to muck around with the PRU, which is a pain in the butt.

Suspicious Dish posted:

My new job is making a DRM driver for Amlogic, and the vendor source dump is a horrible incomprehensible fbdev driver. This will be fun.

I've been through something similar before when trying to bring up a system using a hacked-up Geode-based mess. I feel your pain.

# ? Nov 5, 2014 16:35

carticket: Jun 28, 2005; white and gold.

Based on the trace, I don't think you'll be able to go much faster than 10 MHz and not have your highs and lows start to get squashed.

# ? Nov 5, 2014 20:44

My Rhythmic Crotch: Jan 13, 2011

^ Thanks for the awesome info hendersa. Actually my primary interest is in reducing latency in networked IO. So security and performance are kind of at odds with eachother because normally you would not want an RPC server or whatever running in kernel space, but for performance reasons that would probably be best.

movax posted:

You running a RT kernel?

Nope, just stock 3.14.22 from Robert Nelson. I don't have a jitter measurement on my scope, but it would be interesting to see the amount of jitter with and without an RT kernel.

# ? Nov 6, 2014 04:49

Jerry Bindle: May 16, 2003

Blotto Skorzany posted:

code:

#define CMD_NEVER_EVER_SEND_THIS_COMMAND_OR_ELSE   0xF1   //yep, honestly, see the datasheet

If the command is never supposed to used ( OR ELSE! ) why would this person define a symbol for it? That has the tone of someone who was burned by a silicon bug, and rather than fixing it TI just said "WONTFIX its reserved now, don't use it".

# ? Nov 6, 2014 17:21

Decairn: Dec 1, 2007

Has anyone messed around with mbed or contiki OS yet? Opinions?

http://mbed.org/
http://www.contiki-os.org/

# ? Nov 8, 2014 01:33

teamdest: Jul 1, 2007

Decairn posted:

Has anyone messed around with mbed or contiki OS yet? Opinions?

http://mbed.org/
http://www.contiki-os.org/

I've used an mbed for a few joint projects with someone that owns one. I found that the hardware was fine, but the online IDE and their "copy this to the flash drive and hit reboot" thing incredibly grating while doing rapid prototyping or testing, and the IDE is really not on par even with the likes of eclipse, let alone Visual Studio 2010 + plugins. Supposedly theres a not-too-hard way to get it to work with a regular IDE, but I never had time to get that working. the IDE they provide online is just very annoying to work with. Things like controls that don't override firefox controls, so I couldn't easily indent or unindent blocks of code, having to browse manually and use a mouse for adding packages/includes, etc.

# ? Nov 8, 2014 17:44

Popete: Oct 6, 2009; This will make sure you don't suggest to the KDz
That he should grow greens instead of crushing on MCs; Grimey Drawer

Anyone done a Free RTOS port? I'm looking to start a side project using a Cortex M3/M4 (Arm or Freescale most likely) and would like to get Free RTOS up and running on it. There really is no purpose to this project except to challenge myself. I'm an embedded software guy by trade but I enjoy doing schematic and PCB routing on my own and I feel I've gotten past the 8 bit micro stage and want to try routing and running a real OS on my next board. Any suggestions on a good Arm processor to start with that isn't over 64 pins? I'm not the best at soldering.

Also, gently caress MIPI displays. Got a project at work getting a few demo MIPI displays to run on an i.MX6 platform from Boundary Devices. I got one of the display ups and running and it boots to Android, looks pretty slick. But this other piece of crap Tianma display is driving me insane. Seems to be hardly any information on MIPI and there are very few example drivers I could find. I can talk with the display (sort of) and get into into video mode but it's mostly just a grey screen with no colour and no discernible video. The screen only seems to draw a full horizontal line, like it's not hitting the vertical syncs and so only one pixel is being displayed across an entire line at a time. This is using a parallel video RGB to MIPI chip, when I swap in the other display it looks good so idk. Been hammering at this thing for weeks and have made no progress.

# ? Nov 17, 2014 07:17

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

I used FreeRTOS on a PSoC 5LP (Cortex M3 core) for a product at work. The path of least resistance is picking a chip that they have a demo for (there's a directory in the source distro that includes all the demos iirc) and using the version of port.c etc. that they give you.

# ? Nov 17, 2014 15:50

carticket: Jun 28, 2005; white and gold.

There should be virtually no prong required for a Cortex M build. Just have to get the ISRs registered, and maybe a timer for tickless operation.

# ? Nov 17, 2014 17:14

yippee cahier: Mar 28, 2005

We're using an almost unmodified demo port at work on Atmel Cortex-M3 and Cortex-M4 platforms. Very easy once you have your base system up and running.

# ? Nov 17, 2014 17:55

JawnV6: Jul 4, 2004; So hot ...

I'm trying to get to a working environment that involves as few vendor tools as possible. I want to have .c/.h files, run them through clang, then loaded onto a cortex M4 with as little headache as possible. How feasible is that? Are any particular vendors out of ST, Atmel, or Freescale that are better?

# ? Dec 2, 2014 03:36

My Rhythmic Crotch: Jan 13, 2011

LPC4300, some STM32, and TM4C123x have a USB ROM boot loader, which should mean no tools needed to get code on the device. If you want a debugger you could check the OpenOCD supported devices.

Are you really cross compiling with clang?

# ? Dec 2, 2014 06:22

Pan Et Circenses: Nov 2, 2009

I got an STM32 up and running with just the ST-Link programmer, GCC, and some open source Linux based ST-Link flasher/gdbserver software. The only vendor tool there was the hardware programmer. That project was actually C++, and the whole setup worked fine... never understood the embedded obsession with sicking to straight C!

If you don't have a good bit of experience with embedded systems, I wouldn't really recommend it at all as a way of starting out. If you're looking to get a little deeper, it's probably a good project. Make sure you understand linker scripts and why you'll need to use one to produce your binary.

# ? Dec 2, 2014 07:00

Delta-Wye: Sep 29, 2005

Pan Et Circenses posted:

I got an STM32 up and running with just the ST-Link programmer, GCC, and some open source Linux based ST-Link flasher/gdbserver software. The only vendor tool there was the hardware programmer. That project was actually C++, and the whole setup worked fine... never understood the embedded obsession with sicking to straight C!

If you don't have a good bit of experience with embedded systems, I wouldn't really recommend it at all as a way of starting out. If you're looking to get a little deeper, it's probably a good project. Make sure you understand linker scripts and why you'll need to use one to produce your binary.

My experience is that the things that makes C++ valuable over C (polymorphism, for example) come with undesirable run-time overhead.

If you're used to developing for a STM32 and not a PIC8 or something of equivalent power, then this is largely why you don't understand it; it's an old holdover from a crowd of curmudgeons.

# ? Dec 2, 2014 07:02

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 03:10

JawnV6: Jul 4, 2004; So hot ...

My Rhythmic Crotch posted:

Are you really cross compiling with clang?

Not yet. This has the air of painful learnings ahead.

I was imagining vendor-specific header files, flashers, and dongles still being in the picture. Just something a little slimmer than a GUI that hides everything in that gap. I'm really comfortable on the MSP side. I'm using CCS for the debugger but have a complete flow without that. I've got something cross compiling with headers, not yet linking.

Delta-Wye posted:

My experience is that the things that makes C++ valuable over C (polymorphism, for example) come with undesirable run-time overhead.

If you don't know the type why do you even have a pointer to it?!?

# ? Dec 2, 2014 07:17

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »