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

«‹›2 »

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

isr posted:

The basic idea is that of active objects. Active objects pass messages back and forth to each other, a scheduler selects which object gets to read it's messages and when. When an AO is dispatched it pop's its message from it's queue, sends messages to other objects, and runs to completion.

This sounds like a DIY version of the infrastructure that an RTOS provides for you, with (ideally) shared-nothing tasks that communicate with each other by sending messages via queues, and an efficient preemptive priority scheduler.

I've read and modified/extended state machine based firmware, but never written anything substantial that way from a blank slate. While I'm not a fan of UML per se I will admit that state machine diagrams are somewhat useful in communicating with the marketing guys who have taken to calling it a "spaghetti and meatballs diagram" (in the RTOS based firmware I'm currently working on, I implemented the menu system as a state machine. In retrospect I wouldn't do it that way again for reasons I won't go into here, but when the menu tree was small it was great). I do the diagrams up in Visio, but I can see how something that auto-generated the diagram from the code and left room for annotations would be useful.

# ¿ Sep 7, 2013 01:51

Adbot: ADBOT LOVES YOU

# ¿ May 9, 2024 21:46

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

EpicCodeMonkey posted:

Also, FreeRTOS with Perceptio tracing (http://percepio.com/docs/manual/) is goddam magical.

Hot dang this looks nifty.

# ¿ Sep 7, 2013 01:52

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

Sinestro posted:

Some PSoCs (the highest end 5LP models) have a 2MHz ADC.

Edit: http://www.cypress.com/?mpn=CY8C5667LTI-LP009

If he's only looking for 8 bits it won't matter, but I feel obliged to say

<-----------------------

# ¿ Oct 21, 2013 02:16

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

What do folks here do for unit testing? I'd like to do more of it than I currently am, but there are some issues that I keep running into:

I don't have enough flash/ROM for the tests to live in the main firmware along with the libraries that I or $coworkers[0] wrote and the normal application logic, so I wind up with two binaries (one with the libraries and application logic, and the other with the libraries, the tests and a thin quick+dirty test harness that runs the tests and spits out a report) and I run one then the other.
The unit tests don't catch most memory-related or timing-related issues, which are a minority of bugs by number but a majority of debugging time/effort.
There are some bits of code that I really want to test but I can't think of a good way to unit test - eg. keypress debouncing routines.
due to the above items, I have to do functional testing anyways, which makes it a harder sell to my boss that it's worthwhile to take time to write/maintain the tests because "the functional [read: user] testing will catch the bugs".

There are also some "quis custodiat ipsos custodes" issues wrt. the test harness relying on code to dump the report to the LCD and/or an SD card and that code not being bug-free, but those are minor. It seems like there ought to be a better way to do things.

# ¿ Jan 29, 2014 16:11

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

Markov Chain Chomp posted:

I'd suggest strongly against using I/O directly on the beaglebone. It's very easy to overvolt it a little bit and cause damage, especially if you're interfacing with a 5V interface. Just use the serial port and give your commands to some kind of really basic PIC (or whatever you like). That way, you can contain the different voltage domain on a fairly isolated circuit.

Good to see you around again, CptMafh

# ¿ Feb 4, 2014 14:57

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

ante posted:

SD cards are purely driven by SPI, which makes them trivial to communicate with using an Arduino or PIC.

This isn't quite true - the SD spec defines the (slow as balls) SPI interface to an SD card as well as the much faster parallel SD interface.

# ¿ Feb 5, 2014 00:49

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

ante posted:

I wrote an SPI interface using PIC about fourish years ago, at that time (as far as I could figure), the only way to get the parallel spec was to pay licensing fees.

I would up writing an SPI interface using CortexM3 about a year ago despite my employer having paid the license fees and having the parallel spec in front of me because the hardware guy on the project didn't want to use more pins :suicide:

# ¿ Feb 5, 2014 01:53

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

JawnV6 posted:

Does PSoC Designer have any hotkeys, specifically "jump to definition"? I'm looking through someone else's code and keep banging F3/F12 to no avail. At this point I'd take a goofy alt-shift-meta combo to jump to where something's defined, but it's not even in the right click context menu.

I don't know much about PSoC Designer (that's the IDE for PSoC 1 devices, right?), but PSoC Creator (for the higher end PSoC 3 and 5 devices) lacks it and it infuriates me. The go-to app engineer at Cypress for these sort of questions is Matt Landrum - he emailed me a week ago about a major update to PSoC Creator that's coming that's supposed to address some of its many deficiencies, maybe Designer is getting a facelift too?

# ¿ Mar 18, 2014 02:26

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

ante posted:

Big drill bits can definitely fit kibbles in the flutes.

https://www.youtube.com/watch?v=s-mOy8VUEBk

# ¿ Jun 10, 2014 21:38

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

No Gravitas posted:

This is probably really loving stupid, but what the hell!

While this has precisely zip to do with embedded anything, the constraints I have to work with is something that you guys may be able to help with. This isn't your regular programming and MCU techniques will be a must.

I'm aiming for labour saving. I can do this stuff by hand, but I'd like to save time and save myself making lots and lots of errors.

I have an application which gathers data. It will produce too much data for my memory, so disk storage is a must. The data gathering will run on Windows 32-bit and the processing will run on Linux 64-bit. Per every data item I have 20 bytes of disk to store the whole thing. The data content is not set in stone yet, but will be about 100-150 bytes per item. Compression is a must, but thankfully the data is very repetitious. C is the only language I can use. Finally, and probably the worst thing of it all: I cannot use any standard libraries during the gathering stage. I can probably use newlib to get around that to a degree and make my own stdlib within the retarded setup I have to cope with. The system is not networked.

Are there any MCU databases/key-value stores/etc...? With compression? Which can run on Windows and Linux? Which will handle the data portably across different sizeof(void*) systems?

Yeah, I know it is a loving long shot, but what the hell... why not! Good for a laugh if nothing else!

What led to your weird constraints about language and library usage? Is your boss the PHB from Dilbert?

# ¿ Jul 15, 2014 14:33

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

e: doppelposten

# ¿ Jul 15, 2014 14:47

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

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

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

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

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'm writing firmware for pressure and temperature instruments - gauges, transducers, calibrators, etc. I have some friends and acquaintances in the area that work on medical devices.

# ¿ Dec 8, 2014 20:50

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

Besides the on-chip EEPROM, I think the Atmegas have an API for using portions of the flash as data space if you need a little more room

# ¿ Feb 9, 2015 03:39

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

It's implementation-defined whether right shift of a signed int is an arithmetic shift or a logical shift. Are these values sometimes negative by chance?

As an aside, strength reduction is a really easy optimization for the compiler to make. Consider inspecting the generated assembly and verifying it isn't happening before doing it yourself.

# ¿ Jun 5, 2015 17:23

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

sliderule posted:

Yeah, a uses the full range of signed 8-bit values.

I always assumed that right shifts were arithmetic. I've written a whole bunch of code for this platform under that assumption. It's GCC. According to a mailing list post, GCC uses ASR when the value is signed.

As to strength reduction, I'm afraid I don't know x86 ASM. This code targets x86 for the emulator, but then targets ARMv7M for the hardware.

Here's /1024:
code:
	leal	1023(%eax), %edx
	testl	%eax, %eax
	cmovs	%edx, %eax
	sarl	$10, %eax
And here's >>10:
code:
	sarl	$10, %eax

As you probably suspected, it's performing strength reduction and shifting right by ten in both cases, but in the / 1024 case it's correcting the rounding error that occurs when you do division via an arithmetic right shift on a negative, whereas in the >> 10 case it isn't bothering to because you told it to shift rather than divide.

Specifically, the in the / 1024 case it's doing basically

code:

if (n < 0) {
    n += 1023;
}
n >>= 10;

# ¿ Jun 5, 2015 18:44

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

SkunkDuster posted:

I'm very new to microcontrollers and coding. I just got a launchpad and am going through the basics of blinking an LED on and off with this code:
code:
// most launchpads have a red LED
#define LED RED_LED

//see pins_energia.h for more LED definitions
//#define LED GREEN_LED
  
// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(LED, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(LED, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(LED, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}
What is the most efficient way to modify the code to blink both LEDs? Is there some way to #define LED as RED_LED and GREEN_LED?

edit: also, if the delays were removed from the loop, what frequency would the LED blink at?

#define just uses the C preprocessor to cut-and-paste definitions in your source code; RED_LED and GREEN_LED don't become undefined or anything after LED is #define'd to one of them. digitalWrite(RED_LED, HIGH) and the same thing but with GREEN_LED should work fine assuming both RED_LED and GREEN_LED are defined in whatever header you're including to the proper values for the pins you have those LEDs attached to.

With regard to taking the delays out, the timing then depends on how fast you're running the micro and what the compiler is doing to that loop. If the delay-less loop is getting compiled down to three instructions (a write to an SFR controlling the pin you have the LED hooked up to to drive it high, another write to drive it low, and an unconditional jump to the start of the loop) and you're running at 8 MHz, the LED would blink at a frequency of 2.67 MHz with a duty cycle of 33%; you should know what frequency you're actually running at and you can take the delays out and inspect the generated asm to determine what the actual timing is in that case.

# ¿ Jul 11, 2015 22:35

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

The reaction will differ depending on what you're making. Sometimes the situation is more like "see how your firmware guy reacts when you tell him he needs to gently caress around with his simple comprehensible reliable design by polling or servicing interrupts more frequently and maintaining state to debounce eighteen buttons just so you could save eight cents on a design with a $3000 BOM".

The other advantage of debouncing in hardware is that it is understood by nontechnicals to be much more of a PIA to change the schematic and/or layout than it is to change software, so it's easier to maintain a united front within the engineering department in telling your marketing guys to go suck an egg when they waffle infinitely over how debouncing should work (one of them will always think it's too long and misses legitimate keypresses, another will always think it's too short and doubles keypresses, no matter what duration you go with and regardless of whether you're edge or level triggered), whereas if you did it in software some of the hardware guys may be tempted to throw you under the bus by saying things like "yeah that shouldn't be that hard to tweak, go talk to $firmware_guy_currently_in_the_lab_instead_of_this_meeting about that, I'm sure he's not too busy...".

# ¿ Sep 9, 2015 02:45

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

BattleMaster posted:

Who the hell would make a bomb that ticks or beeps or whatever anyway? That would be some mind games poo poo.

Counterstrike bruh

# ¿ Sep 16, 2015 13:38

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

Maybe one of Atmel's SAM L21 variants?

# ¿ Sep 21, 2015 15:42

Adbot: ADBOT LOVES YOU

# ¿ May 9, 2024 21:46

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

Luigi Thirty posted:

They still make CodeWarrior?

CodeWarrior from 10.x on is just a rebranded Eclipse now.

# ¿ Sep 29, 2017 02:43

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

«‹›2 »