WickedBlade

Hello, I'm at a troubleshooting step in my project. So basically I fired it up and, as feared, nothing worth mentioning happened. However, I have checked that my CORE module with LCD is working. When I power up, I get the MIOS version message then the LCD prints "Ready." I had previously tested the CORE, of course, and had been able to upload MIOS, as you can guess. But I have made some changes lately (theoretically I was just wiring stuff to various J-ports, and I'm testing with the ports unused - nothing plugged), and now it seems that my CORE is powered through the MIDI out port: when I plugged the CORE to my PC via MIDI, I noticed the LCD lighting up. When my DOUT module is also connected, I notice that my common anode 7-segment LED digits lights up too. So it looks like there's some power coming through the MIDI out. So I have 2 questions: is it normal that I measure about 5V between M+ and ground on my MIDI plug (on the PC), or is the PC MIDI output malfunctioning in some way? looking at the CORE schematics, I see that said M+ is connected to +5V through resistor R8, so it might be normal that MIDI out feeds the modules... Am I right and is this a normal behaviour, or is there indeed something wrong? I hadn't noticed this behavior before, and I'd rather make certain before frying things. Thanks.

Thank you for your answer. That's what I kinda figured out myself but I wasn't too sure. I'll try that, thanks again!

Hello, in my project I need more than 4x8 digital outputs, so I hooked up 2 DOUTx4 modules (which I will call DOUT1 and DOUT2 for brevity). As it happens, I don't need all 8 chips on them, only 7 out of 8. Since I have already soldered the output pins that I need, I find myself with an unused chip on DOUT1. I was wondering if I could omit plugging the chip in the socket, maybe with some simple additional wiring on the DOUT1 PCB. I would then have to make slight adjustments to my program, but that's not a problem. Any hint as to what to do? I don't suppose I can simply omit the chip?

Also, if you install MSYS 1.0.11 instead of 1.0.10, you don't have to do the make overwrite thing, because it's installing the correct version (3.81), so you can skip this step altogether.

Not to be nitpicking, but if the compiler doesn't comply to the language specs, it's a bug (or at least an absence of feature) and it should output a warning to the user. I'm very experienced with full fledged C and C++ compilers and I find the undocumented limitations irritating. I understand that it's a work in progress and it's on a very specific processor, but still. End of rant :D But well, lesson learned I guess, I'll be careful with these now too.

So the final world on that is that SDCC doesn't properly initialize non-const variables, even though it parses the code without raising an error or warning? :( Maybe this should be written somewhere on the Wiki (maybe it already is, I didn't find it)... But where?

On the Toolchain setup page, there's a 'PATH Environment Variables' section that describes it (it's a bit verbose, but you should get the idea).

Did you setup the MIOS_PATH and MIOS_BIN_PATH environment variables correctly?

My mistake, I hadn't noticed the shifting. So I guess the code does pretty much what you say, i.e. you get 1 for every other row in your matrix. Arrays of arrays are always a pain to manage. Could it be that you're accessing it wrongly? Have you tried inverting the elements and calling this instead? DisplayLED(x , matrix[x][row]);

I don't know exactly what you're trying to achieve with this code, but it is quite certain that it can't work, since you're doing basically 0xn0 & 1 (where n i a number between 0 and F), and this is always equal to 0. In my opinion, the problem is not the type (unsigned char), which is quite fine, but either the values in your matrix or the "& 1" operation you're applying. (to understand better this "0xn0 & 1" thing, consider that doing "& 1" is asking if the number is odd -impair in french-, and you're asking this of a number that is a multiple of 16, so no, it's never odd)

Hello, to get rid of this warning, I simply compiled the source in lib\libsdcc\sdcc_2.8.0 (in the MIOS package) again, after having modified the makefile to compile for the PIC I'm intending to use. Then I copy the resulting libsdcc.lib file in that directory to the lib\ directory, overwriting the old one. (Note: to build this libsdcc, I only had to open a command prompt in the directory and type make) Tell me if you need more help!

For those interested, the files from the SDCC sources for libsdcc aren't modified at all in MIOS, so it's ok to use them directly, with the makefile from lib\libsdcc\sdcc_2.8.0\Makefile (modified for the 4620 in my case). I checked them all against the original source to make sure of it. I am now using this 4620-specific libsdcc together with gputils 0.13.6 and I no longer have warnings, all seems fine.

All right I've wandered through a couple of folders, tried more samples and some complete apps (SEQ and such) without success. And then I stumbled on the lib\libsdcc\sdcc_2.8.0 folder. As it turns out, if I build the libsdcc.lib file with this for the 18f4620, it works and the first 2 warnings disappear. I guess that will do. I wonder though: I've read the README.txt file and I wonder what's different in this source folder from the original folder found in "C:\Program Files\SDCC\lib\src\pic16\libsdcc". I'm asking because, as I use SDCC 2.9.0, I thought I may have to build the newer libsdcc. But if this is some kind of "hack" for MIOS, I need to integrate the changes...

Hello, I've written a rather simple app (from scratch, or rather from skeleton), and I'm getting warnings at link time when building for the 18f4620. To build for this model I simply changed the "PROCESSOR" value in the makefile. When I build for the 18f452, I get no such warnings. I've tried with a couple of the samples provided by the MIOS base package, but couldn't reproduce the behavior with those. The warnings are thus: warning: processor mismatch in "gptrget1.o" warning: processor mismatch in "gptrput1.o" Please note that this happens with SDCC 2.8.0 and 2.9.0 and with gputils 0.13.5 and 0.13.6. When I use gputils 0.13.7 I still get these warnings, plus an additionnal two, even more alarming: warning: unknown processor type (0xa462) in "pic18f4620.o" defaulted to pic18cxx warning: processor mismatch in "pic18f4620.o" That makes me suspect that the warnings all come from gputils but I can't be sure. I am well aware that these are "only warnings", but in my experience, it's better to correct them ASAP lest they come back and bite you at your most unprepared... Can somebody tell me what I can do to fix this please? Please note that there are no other warnings whatsoever during the code compilation and that the link does succeed (no error). Thanks.

I may be totally wrong, but the PIC16 and PIC18 are two different families, and they do not have the same instruction set. That means that a program compiled for a PIC18 can't work on a PIC16. You can BURN a PIC16 with the PIC Burner, apparently, but you have to burn a PIC16 app.

I don't think I'll go that far. If it fits in the PIC memory, it will do :) Yes, I noticed (I even mentioned it in a previous post). I think I'll just wire the common anode to +5V and alternately lit half the segments of a digit, then the other half to avoid too much sinking current at a time through the SR. Well I haven't wired and tested those LEDs yet either, but it seems to be standard practice for the MIDIBOX project, so I guess it works fine. I believe that I'll do some kind of alternating switching too to avoid too much load, and I think it will dim the LEDs a bit, which should be fine since at full power those LEDs are VERY bright (I bought the ultrabright variety). No worries, I'm already there. :D

I was thinking again (it's a curse I'm under) and thought, if I have enough shift registers to drive 2 digits (that is 2 RS), why would I multiplex them? Can't I just wire the common anode of the digits to +5V and be done with it? Maybe by kind of multiplexing the segments to avoid putting too much sinking current through the RS, I mean trigger only segment a-b-c-dot one time and then d-e-f-g the other? Of course that would be done in software with clever masking, but that's nothing difficult...

Thank you. As a matter of fact I found this thread myself after posting my last question. It is indeed very interesting, although it focuses mainly on current drawing and I'm interested more in current sinking. Well I'll guess I'll just have to try. My project is in progress so it's not entirely built yet, I can't test anything as is... Considering the thread you mention, I guess I'll just try and see how it works, and try alternatives only if things look awry...

Thanks for the suggestion. I'm at a point where I would rather avoid adding more stuff to the project (I'm over my budget :( and the case is running out of space to fit more chips and boards). I've tested a simple LED-resistor combo with 5V power supply just to make sure I had correct current estimates. It seems that a blue LED with a 100R resistor draws about 21mA, which is in the correct range for the HC595. I've been thinking about the multiplexing technique again and there's something I don't quite understand, maybe someone can shed some light. I understand that LEDs don't switch off immediately when they're not fed, so I'm reassured that I won't notice artefacts with the technique (but maybe a less bright lighting?). What I don't get is, I've read that there's a maximum current sinking rate that the 74HC595 can handle (I think I've read it's about 100mA but I can't find the thread where I read that). So, if one 74HC595 feeds the common anode of the digits, and all the segments of the digit are lit, I don't see how all of them can be fed to the correct value (that would be ~14mA for a red or green digit, ~21mA for a blue one). I mean, if all segments are lit, they need 14x7=112mA, which is above the sinking current max. Furthermore, if the common anode pin can only provide 35mA (according to datasheets), I fail to see how this can feed the digit correctly... And yet, the MIDIMON project is evidence that this does work. So is there something I'm unaware of? Is there some software trick?

Thanks for replying :) The thing is that in this diagram (from MIDIMON), the digits are multiplexed, and if you look closely, you'll notice that the common anodes are 'fed' by a 74HC595, so it can't be more than 35mA (maximum rating from datasheets). I'm afraid that this won't be enough and the digits will be too dim, or, conversely, that the digits will draw too much power to get properly lit and that it will fry the 74HC595. That's basically my second question... Of course, if this works, I could basically wire each common anode to a separate pin and set it to 1, and I wouldn't have to worry about multiplexing, but I'm still in doubt about the power consumption and brightness, especially since my digits are blue instead of the regular red/green.

Hello all. I'm sorry if this has been asked before but I did a search and the answers I found were not quite satisfying. I'm building a personal project (see my wiki page) were I want to drive a 2-digits 7-segment LED display with the DOUT. Nothing extraordinary there. I originally thought to drive the 2 digits separately (non-multiplexed) because I have enough room to wire them separately on 2 different 74HC595 chips, and I figured that LED digits are just cleverly packaged LEDs. My problem is that I got "common anode" digits instead of "common cathode". So to wire them correctly I would need to wire the anode to 5V and each cathode pin to a 74HC595 output pin. The corresponding segment would lit if the output pin is set to 0. But I understand that this would mean that the 74HC595 would act as current sink, and I'm not sure it will like that. I've seen the subject lightly discussed but with no clear answer (at least to me). Please note that my digits use blue LEDs which are 3,3V/30mA, not the regular red/green type (I'm using 100R resistors instead of the 220R resistors used for typical LEDs). So I'd like to know 2 things: - can I, or shouldn't I, wire the digits as I said? - if I can't and I have to do some kind of multiplexing (multimon-style), I'm afraid that the display will be darker than the other (single) LEDs I use in my project. Is this a valid fear? I mean, from the datasheets, I gather that the maximum current output from the 74HC595 is 35mA, which would be split between 8 segments, right? Is that not a bit low? Plus, there's the multiplexing thing... I guess another option would be to use a darlington array, but I'd like to avoid complicating the hardware more than it already is... Any advice?

Guys, I think I need help or pointers to some good papers. I've searched the internet (and the forum and wiki) to no avail. Basically, I want to separate analog ground from the MBHP ground, and I don't know how to go about that. Would a simple low-pass RC filter do, between the two grounds? If so, what R and C values should I use? Also, if I want to use a separate 5V supply for the relays, does that mix well with the fact that the ground for the relays will be output by the ULN2803, which means, I think, that this is the same ground as the MBHP? I was thinking of using a separate voltage regulator, too (7805 or 78S05), but I don't know how to wire it up properly. Should I copy the schematics from the CORE module, with the rectifier diodes and caps (C3 to C6 and X1 on the PDF)? Please note that I'll feed either 5VDC or 9VDC, so the diodes shouldn't be necessary. Finally, I'm wondering how to hookup the opamps that I'll be using to make impedance buffers for my audio signal. It can be fed with 5VDC, but which one should I choose, since, I guess, this means that this signal will somehow be mixed with the audio signal that goes through the opamp... Should I use yet another regulator? I'm very very confused, and would welcome any help!

Or maybe I could use some regular transistor instead? As you may have guessed, I'm trying to reduce the cost, as relays are pretty expensive. I've been doing some more research (I'm trying!), and it appears that depending on amps, the switching process is not the same. For instance, Fender amps provide a sine signal, which is then divided into its positive and negative side, and these 2 pilot 2 function switching. Anyway, I've just stumbled upon a thing called "solid state relay" on mouser, and I wonder if that's not what I'm looking for. Only, I can't seem to find application examples, and I'm having a hard time deciphering the datasheet. There is for instance the Sharp PR33MF11NSZF (datasheet) which looks promising. They wouldn't call them relays if they didn't share the proprieties I'm looking for with relays. Right? Or would they?

Thank you. I feared as much. Well I think I will save myself the trouble and use relays instead, they don't care if the signal is very different from what they are fed ;) (12V was just an exemple, it may change depending on the amp I'm plugged into, which is another argument in favor of relays)

Thank you for your help. I guess that it's OK for me then, because I won't use it for signal routing, only for amp channel switching, where the signal is constant. Just to make sure: this wouldn't be possible with a CD4053, or would it? And another one that just occured to me, and I think I won't like the answer. Will all this still work if the signal that is routed is 12V (while the chip is fed with 5V)?