User loginNavigation |
Dataflow programming for PIC microcontrollersRecently I've been working on a language for programming some of the higher-end PIC microcontrollers. These are very resource-constrained machines, but they can be programmed in C; the one I use the most, the PIC18F4520, has only 32 Kbytes of flash program memory and a whopping 1536 bytes of RAM. The problem is, while C is a semi-decent language (at least compared to PIC assembly), it still sucks for PIC programming. A lot. In order to make any non-trivial program, you need to set up a bunch of the onboard hardware modules which all have low-level access methods, and you need to do a bunch of interrupt programming (pragmas everywhere!) which gets you mired in a mess of low-level details -- did you remember to clear a certain bit in some obscure configuration register? For most of the PIC programs I write, I actually think about the problem in terms of data flowing between blocks, similar to Simulink. For example, I might envision a program which performs analog to digital conversions and passes those values on to a bank of LEDs as a simple block diagram with two blocks, one for the A/D converter and another for the LED output. If blocks of arbitrary C code are supported and blocks for other hardware modules are added, this concept turns out to be powerful enough to handle almost every PIC program I've written, and without the pain of writing C code for the PIC. For example, here's a fairly simple program in a lisp-like syntax: ;; Define the configuration for the hardware devices (config-bits (a/d :an1) (trisb 0) (trisd 0)) ;; Define a custom block of C code (defcode-inline inverter (x) "(~x)") ;; Connect analog input 1 (an1) to a bank of LEDs (latb) (-> an1 latb) ;; Another bank of LEDs (latd) will be the bitwise inverse of latb (-> an1 inverter latd) ; Equivalent to (-> an1 inverter) (-> inverter latd) This would be a lot harder to write in C, and I've got a partial implementation of a compiler for this language which is working fairly well, so I think I'm onto something good here. Unfortunately, there's probably a mess of useful information about these sorts of blocks-and-connections languages, and I don't know any of it. So, better informed people: what do you think of this type of programming language? Are there any practical issues I should know about? And how would I go about typechecking this sort of language? Since type mismatches are likely to be caught by the C compiler and presented as baffling error messages complaining about perplexingly named mangled symbols, some form of static typechecking before the intermediate C code is generated takes on more than a little urgency. By Peter Scott at 2006-06-15 23:08 | LtU Forum | previous forum topic | next forum topic | other blogs | 13647 reads
|
Browse archives
Active forum topics |
Recent comments
17 weeks 8 hours ago
17 weeks 12 hours ago
17 weeks 12 hours ago
39 weeks 1 day ago
43 weeks 3 days ago
45 weeks 20 hours ago
45 weeks 20 hours ago
47 weeks 5 days ago
1 year 2 days ago
1 year 2 days ago