OT: Robotics or embedded or hardware programming... what is this called?

David Collins davidcollins001 at gmail.com
Thu Jun 21 09:09:20 UTC 2012

I have one of these


They pack everything you need in and a few examples, quite neat but
you need to do some electronics

On 21/06/2012, Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl> wrote:
>> I want to get started programming for hardware. Motors, sensors,
>> actuators, etc.
>> I have a programming background, (python, PHP, C++) but no experience with
>> code
>> that drives hardware. (Motors, sensors, etc.)
> add "--" to your language list so first 2 would disappear and third will
> become C.
>> I *don't* want closed-source "kit robots" where the point is to build the
>> robot
>> the book and thats it. I also don't want ladder logic-based PMC's. Some
>> kind of
>> micro-controller that runs a *nix flavor (or a BSD flavor!) would be
>> great! (If
> Why do you want something like microcontroller to run any OS?
>> What do you call this? Embedded programming? Generic hardware
>> programming?
> running unix on microcontroller-style hardware is what i call nonsense.
> Writing your program that runs from first executed instruction is what i
> call normal programming of such devices.
> The proper way is to
> 1) buy a microcontrooler chip, make your hardware using it, possibly buy
> already made boards. microcontrollers are <1$, some more capable 32-bit
> ones (ARM compatible usually, some are MIPS) for 2-3$.
> 2) throw away all included libraries because they are mostly mess.
> prepare something that can be used as crt0.s
> Better write it yourself in assembly. shouldn't be larger than 5
> instructions anyway, a bit more if ARM interrupt vectors are needed to be
> filled.
> Some assembly knowledge is very useful, in spite of writing most in C.
> 3) read documentation. All embedded devices (like A/D converters, PWM
> generators etc.) are described. With 32-bit micros start from "memory MAP"
> chapter and then device description. You will just find out at what
> address your peripheral is accessible.
> 4) lets say for example that 32 GPIO pins are accessible at address
> 0x40001000 for setting ports, 0x40002000 for resetting ports, 0x40003000
> for reading out value, and 0x40004000 for setting direction
> (input/output).
> #define GPIO0_SET ((int*)0x40001000)
> #define GPIO0_RESET ((int*)0x40002000)
> #define GPIO0_READ ((int*)0x40003000)
> #define GPIO0_DIR ((int*)0x40004000)
> 5) use it in your program.
> *GPIO0_DIR=0xFFFFFFFF; //sets all pins to output
> *GPIO0_SET=0xAAAAAAAA; //sets every other pin to 1
> *GPIO0_RESET=0x55555555; //set the rest to 0
> if you have questions send it privately. microcontrollers are wrong place
> for unix system and it's overcomplexity relatively to the task.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"

More information about the freebsd-questions mailing list