Author |
Message |
Dan Lavin
Joined: Nov 09, 2006 Posts: 649 Location: Spring Lake, Mi, USA
Audio files: 21
|
Posted: Tue Jul 03, 2012 7:36 am Post subject:
|
|
|
Quote: | I played around with the new date code AY-3-8910 chips and found out that they are NOT BAD after all.
I connected the Reset pin of the AY chip to pin 17 of the PicAxe and sent it a reset pulse after power up and the noise works fine on all four of my 0426 chips.
| Cool! Mine is date code 0426, so there's hope!
Quote: | I heard back from Billy at BG Micro and he was very apologetic about the defective chips. He has pulled them from the sight and said we could return them if we wanted to. He was very surprised and said that he has been selling this same date code chip for the last five years...weird huh? | Better call Billy back before he trashes his stock! _________________ Synth DIY since 1977! |
|
Back to top
|
|
|
THeff
Joined: Sep 01, 2006 Posts: 229 Location: Florida
Audio files: 33
|
Posted: Tue Jul 03, 2012 11:54 am Post subject:
|
|
|
Hey Dan,
I did let BG Micro know about the findings and Billy was pleased to be able to sell the remaining ones.
Regards,
THeff |
|
Back to top
|
|
|
Thomas_Henry
Joined: Jul 24, 2009 Posts: 170 Location: N. Mankato, MN
Audio files: 3
|
Posted: Tue Jul 03, 2012 1:11 pm Post subject:
|
|
|
Hi Guys,
I'm on the road, not near the workbench, but am glad to hear about the reset business.
You know, when the LCD was giving me grief I had tried a reset pulse from the Picaxe, as well as the standard cap/power-on business. After I got the LCD working (from some software changes), I went back to relying the built-in pull-up resistor and never thought about it again.
I'll be curious to see if it takes care of mine with the crappy port behavior.
Anyway, good catch. I hope Billy wasn't too flummoxed by the activity. As well all know, most beginners always blame the chip first, and yet in my experience bad chips are almost never the problem. I feel bad that my reports may have caused BG Micro some grief.
Thomas Henry |
|
Back to top
|
|
|
THeff
Joined: Sep 01, 2006 Posts: 229 Location: Florida
Audio files: 33
|
Posted: Tue Jul 03, 2012 2:30 pm Post subject:
|
|
|
Hey Thomas,
One thing to remember about the AY chips is that the older 1982 don't require the reset, so there is a difference between them. I have seen some schematics that show the reset pin connected to Vcc. The older chips would have worked with reset tied high, but not the 0426 chips...I tried it.
I will say though that most of the designs show Reset connected to the host MPU. The datasheet also shows a 500nS reset on one of the diagrams.
With all of this analysis I have been completely unable to get tones out of the Yamaha chips. I have tried everything...I'm stumped.
-THeff |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Tue Jul 03, 2012 8:53 pm Post subject:
|
|
|
I am pleased to report that MIDI, all three oscillators, noise, and the cursor keys are all working for me with the correct resonator and the serial debug output is at the correct baud as well. The LCD, still not so much.
I'm wondering if the piece I'm using (scavenged, not a direct match for what Thomas' design calls for) may not be pulling too much current or some such ... and of course I could have wired something wrong too.
I have another LCD on its way, but I think I have enough functional here to start messing with/testing the MIDI code. |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Wed Jul 04, 2012 12:35 pm Post subject:
|
|
|
I went through the details of the menu system, and I have a comment and some questions.
Comment is that the comments for registers 0-5 are backwards (fine vs coarse) They're used correctly, so this is just cosmetic.
To work on the MIDI code I need to understand the intent of the MIDI modes better We have three voices, and the gates. It seems pretty clear from the setting of the base value that the intent is (with base = 0) Voice A is channel 1, Voice B is channel 2, Voice C is channel 3, and Gates are on Channel 4. As base is incremented (up to 12) the others all shift along.
I'm not sure how Omni / Mono / Off are supposed to play with that. Obviously "Off" means no MIDI input...but then is the only control going to be through the menu? Or just no output period? Omni vs Mono is pretty straightforward for a single voice device, in Omni it responds to any note events regardless of channel, and in Mono it only responds to its own channel. With that interpretation, Mono is pretty easy to understand even for all the voices, but I'm not sure what should be done with Omni--everything gets all the events, so they play in unison? They play in "unison" but with the frequency offsets set from the menu? Voices B & C disabled and only playing Voice A?
I'm also unclear on how to process the gates as a MIDI channel. Is this going to be a case of the gates are generated to match the bits of the note (e.g. sending C4, which is note number 60, would light up the gates in the bit pattern 00111100)?
I'm also unclear on how the envelope triggers are to be used....is that meant to be a trigger pulse for each note event for each of the voices, so we can trigger an external EG? That would be easy to do, but I want to be sure...and how wide a trigger do we want? The MTS-100 used a 5 or 10 microsecond pulse if I remember correctly.
I apologize if these are basic questions that if I had more background in synthesis would have obvious answers. |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Wed Jul 04, 2012 10:21 pm Post subject:
|
|
|
Initial sketch of midi code (based on sompost's code) is written. Will test and revise starting tomorrow. Completely untested, but here's the modified version of process_midi anyway....
Code: |
; Start of MIDI
hsersetup B31250_64,%00001001 ;turn on MIDI input doing here so we don't have a big backlog before we get the rest of setup done
midi_status = 0
main:
if head != hserptr then ;anything in queue?
ptr = head ;yes
midi = @ptrinc ;get the byte
head = ptr ;move head one byte along
if head = 1024 then ;but don't go beyond end
head = 0 ;wrap around
endif
gosub process_midi
endif
goto main ;repeat forever (obviously we want a way to escape to the menu should we need to)
end ;end of main program
;*************************************************************
;* *
;* Process MIDI byte *
;* Input parameters: midi *
;* Static variables: midi_status (must be=0 at startup), midi_data1, midi_data2 *
;* Local variables: temp *
;* *
;*************************************************************
process_midi:
if midi >= %10000000 then ;status byte
SerTxd("status byte", CR, LF)
if midi >= %11110000 then ;system common
SerTxd(" system common", CR, LF)
if midi >= %11111000 then goto sys_rt ;ignore all other system common msgs, including sysex
midi_status = 0 ;reset running status
SerTxd(" reset running status", CR, LF)
else ;channel message
;check channel, if not ours set midi_status = 0
midi_status = 0
temp = midi & %00001111 ; mask off the channel number
for i = 0 to 3
if temp = base+i then
midi_status = midi ; we have a winner!
endif
next i
midi_data1 = 0
midi_data2 = 0
endif
else ;data byte
if midi_status > 0 then ;status sent or valid running status
temp = midi_status & %11110000
;the following messages require 1 data byte, which we just got
if temp = MIDI_PGM goto prog_change
if temp = MIDI_CAT goto chan_atouch
;the following messages require 2 data bytes
if midi_data1 = 0 then ;we need another one
midi_data1 = midi
else
midi_data2 = midi ; midi_data2 possibly not needed, but this is clearer
if temp = MIDI_NOTEON goto note_on
if temp = MIDI_NOTEOFF goto note_off
if temp = MIDI_CTRLCHG goto control_change
if temp = MIDI_MODWHL goto mod_wheel
if temp = MIDI_PAT goto poly_atouch
endif
;else ignore
endif
endif
return
; for the moment ignoring the nuances of voiceA/voiceB/voiceC/Gates
; all changes go only to voiceA
note_on:
;note=midi_data1, vel=midi_data2
if midi_data2 = 0 goto note_off
SerTxd("Note On, Note #", #midi_data1,9, " vel ", #midi_data2,9)
; handle out of range notes
if midi_data1 > noteB9 or midi_data1 < noteC1 then
; ERROR out of range!
else
;process note on here
temp = midi_data1 + msbOffset
readtable midi_data1, midi_lsb
readtable temp, midi_msb
SerTxd(" MSB ", #midi_msb, " LSB ", #midi_lsb)
register = 0
value = midi_lsb
gosub store
register = 1
value = midi_msb
gosub store
endif
; should have actual note enable and generate trigger here
; for testing will leave A always enabled
midi_data1 = 0
midi_data2 = 0
return
note_off:
;note=midi_data1, vel=midi_data2
SerTxd("Note Off, Note #", #midi_data1,9, " vel ", #midi_data2,9)
if midi_data1 > noteB9 or midi_data1 < noteC1 then
; ERROR out of range!
else
;process note off here
endif
midi_data1 = 0
midi_data2 = 0
return
; from here out, aside from clearing midi_data bytes, nothing tested
;unhandled MIDI msgs (fill-in as appropriate)
poly_atouch:
;note=midi_data1, value=midi_data2
control_change:
;control=byte0, value=byte
mod_wheel:
;lsb=byte0, msb=byte
midi_data1 = 0
midi_data2 = 0
return
prog_change:
;prog=midi
chan_atouch:
;value=midi
sys_rt:
;msg=midi
midi_data1 = 0 ; possibly redundant/unnecessary
midi_data2 = 0
return
|
|
|
Back to top
|
|
|
sompost
Joined: Aug 17, 2010 Posts: 58 Location: Switzerland
|
Posted: Wed Jul 04, 2012 11:39 pm Post subject:
|
|
|
The variable 'data' in my sketch is a flag indicating whether the first byte of a pair had been received. You cannot use the MIDI data byte itself to determine that, because 0 is a valid data byte (e.g. lowest note of a note on/off message). I concede that 'data' is not the most expressive of names for that purpose, but that doesn't invalidate the purpose.
While we're at it, I wanted to clarify a minor detail. The gotos in my sketch (all of them!) aren't really gotos but tail calls (a kind of gosub-but-don't-bother-returning). They not only make the code shorter by themselves, we can also do away with the if-elseif-else-chains that would otherwise be necessary if they were real gosubs. I just wanted to make that clear in case someone I know happens to read this code... _________________ Built: MFOS SLMS plus, SL Ultimate & Expander, 10 step seq; SLMS MkII; PAiA FatMan, Mutable-Instruments Shruthi-1; Jasper Wasp Clone
Building: Maddox MonoWave; Auduino; ASM-2; Minimoog Clone
Backlogging: MFOS 16 step seq; TH SN Voice; Takeda One Board Farm; Okita Vocoder; Page TR-9090; TH GM Voice, AY Voice |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Thu Jul 05, 2012 5:22 am Post subject:
|
|
|
Fair point on data vs how I used it here.
I'm not sure how likely it is for someone to send note 0, since it's off the end of our scale and not a note used. In fact it's off the end of the usual musical scale, it would be C -1 if someone were to send it. And I believe that would be 8Hz and so below the threshold of hearing as well.
Not that we should hold electronic instruments to the same levels as orchestral ones, but the lowest notes there are played by Harp & Piano, and are down to C1 & C0 respectively. http://solomonsmusic.net/insrange.htm
I'm inclined to leave it as is for these reasons; even though per the spec 0 is a valid data byte, I don't know that I see a scenario where it would be sent. I'm curious about other folks' opinions though, and as I noted the midi_data2 could be redundant to the byte already in midi, so we probably could make a flag as well.
So what are other people's opinions on the matter? |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Thu Jul 05, 2012 5:43 am Post subject:
|
|
|
Ah, but on reflection that doesn't account for control change and mod wheel...even not handling them, I don't know what scenarios that they might send a 0 as the first data byte, so that would probably screw up the stream. So unless someone who knows those better can assure me that the chances of zeros there are as rare as in note-specific types, I *will* implement the flag. |
|
Back to top
|
|
|
sompost
Joined: Aug 17, 2010 Posts: 58 Location: Switzerland
|
Posted: Thu Jul 05, 2012 6:47 am Post subject:
|
|
|
It's a good decision to leave the flag in there. If you dislike flags you can always view it as a (zero-based) index at which the next data byte is to be stored.
Leaving a known flaw in the code because it is "unlikely" to manifest itself is a spectacularly bad idea. Don't do it because you will hit it. _________________ Built: MFOS SLMS plus, SL Ultimate & Expander, 10 step seq; SLMS MkII; PAiA FatMan, Mutable-Instruments Shruthi-1; Jasper Wasp Clone
Building: Maddox MonoWave; Auduino; ASM-2; Minimoog Clone
Backlogging: MFOS 16 step seq; TH SN Voice; Takeda One Board Farm; Okita Vocoder; Page TR-9090; TH GM Voice, AY Voice |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Thu Jul 05, 2012 2:57 pm Post subject:
|
|
|
Wasn't so much a disliking for flags as it was thinking I needed to be stingy on variable use, as we're near the limit. But between not really needing data2 and I think I recall (will check again later) a dedicated flag bits variable already assigned, it really ought not be a very big deal. |
|
Back to top
|
|
|
n.d
Joined: Dec 15, 2011 Posts: 52 Location: Talos IV
|
Posted: Thu Jul 05, 2012 8:42 pm Post subject:
|
|
|
So cool! However, I can´t seem to find any samples. Are there any? |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Thu Jul 05, 2012 9:37 pm Post subject:
|
|
|
Ok, so we have partially working MIDI code with voice A only.
I have implemented the flag
I have implemented "trill" functionality, where I have a two note deep stack and can go back to the previous note.
There is a bug, at least in my current instantiation (using RB3 mini-keyboard for MIDI input, AY chip as previously described is suspect in some aspects) where if I press multiple keys and then release them all 'at the same time' I lose Note Off events. This leaves the oscillator on. It's easy enough to turn back off by deliberately pressing three notes and then releasing them one at a time.
I have cut up all the menus--not only do I not have a working LCD, but I didn't want to have to walk the menus every time I start up another test, so I have chosen various defaults and forced them through. Obviously this is NOT going to be how the final code is, but it's expedient for testing.
I'm trying to get more sleep, so I'm going to leave it at that for tonight, and come back to the bug tomorrow.
Please note that this is a significant branch off the official firmware, and none of it should be considered official until it has Thomas' blessing.
Edit: also the code is fairly ugly, once things are better I'm sure it will better formatted if not refactored somewhat.
PS sorry, no samples yet; at the moment what I have is just a pretty pedestrian sounding square wave, none of the noise/gating/etc is there to change the sound from that.
Description: |
|
Download |
Filename: |
ay_voice_pete.txt |
Filesize: |
46.66 KB |
Downloaded: |
378 Time(s) |
|
|
Back to top
|
|
|
factus10
Joined: Jun 20, 2007 Posts: 158 Location: Buffalo, NY
|
Posted: Fri Jul 06, 2012 1:35 pm Post subject:
|
|
|
Boy, you go away for a little bit and Thomas H has gone from idea-of-a-project to cool prototype.
For what it's worth, I've been holding on to a bunch of 8910s for years to do something like this.
Thomas, if you haven't discovered this yet, the Speech/Sound cartridge for the Radio Shack Color Computer used this chip (and the SPO256). Here's the manual, which includes PCB layouts and schematics.
The internal envelope generator has always been less than awesome. _________________ Nothing succeeds like excess. |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Fri Jul 06, 2012 10:32 pm Post subject:
|
|
|
I'm not going to repost the code, but I determined that the problem with losing Note Off events was due to my SerTxd commands. Commenting them all out, I could not reproduce the problem. Since those are just for debugging anyway, I'd call that good.
I'm not entirely sure why this would cause me to lose events, since the HW Serial has a 1k buffer, but there you have it.
Next steps (probably not til Sunday) will be to expand to the other voices, and any code clean up. |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Sun Jul 08, 2012 9:48 pm Post subject:
|
|
|
I took a crack at coding multiple voices, where each voice was assigned to its own channel, but nothing good to report.
Unfortunately on the Mac I can't use MIDI Ox to do everything in one, so I have a MIDI monitor program and a really simple pattern sequencer that lets me assign different patterns to different channels. If I mute the pattern going to Voice A on channel 1, I can then hear the stuff also being sent to Voice B on channel 2, however, I never hear them together at the same time.
If I put SerTxd's in to view it, it looks to all the world like I'm only getting one stream. Even if I disable those though, I'm still not *hearing* both streams.
Possible causes:
my code is confused--I don't think so though because even if I dump the byte stream at the top level loop, just numbers out, I still only see one melody line, not both.
my USB->MIDI dongle is cheap and defective--not sure though because the MIDI Monitor does show both melody lines going out the right port. I need to hook this up to another MIDI target and see what I hear.
Something about how the PicAxe is handling serial input isn't working the way I expect--I don't want to blame the chip though .
If someone has an alternative way to test this (say, an all windows environment), let me know and I can share the current iteration of the code and see if anyone else gets the same results. |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Sun Jul 08, 2012 10:25 pm Post subject:
|
|
|
Hm. Also going through a usb hub shared with keyboard. Not enough blinking ports on a laptop, and the mousepad is mucked up. Will probably have to do surgery to fix that and then see whether eliminating the hub helps. |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Mon Jul 09, 2012 6:47 pm Post subject:
|
|
|
Good or bad news, who knows... tested with my Yamaha portastudio and it exhibits the same behavior. Midi monitor thinks all the data is going out, but the endpoint only gets the one set of notes. If I disable the channel 1 melody, and change nothing else, I then get the channel 2 melody, so it's clear my keyboard is set up in omni mode....
So either the USB->MIDI is hosing the stream, or the pattern sequencer is doing something off base that confuses it.
Unfortunately the portastudio cannot be set up as a multi-channel source, and I don't think I have anything offhand that can....I have two other keyboards in various states of brokenness, but there's a whole other project involved in getting them somewhere usable. |
|
Back to top
|
|
|
THeff
Joined: Sep 01, 2006 Posts: 229 Location: Florida
Audio files: 33
|
Posted: Tue Jul 10, 2012 9:23 am Post subject:
Testing the Yamaha YM2149 |
|
|
Greetings,
I exhausted all of my ideas trying to get the YM2149 SSG chip to generate sound on the AY-Voice. I was determined to make sure these chips were good after the AY chip experience. Looking around the web I found this:
http://electronicfields.wordpress.com/2012/04/09/ym2149-sound-generator-arduino-fast-pin-switching/
I decided to try and get the YM Streamer setup working so I connected the Arduino as seen in the picture. The MP3 file which is attached proved imediately that the Yamaha chips are good. With this testing and analysis I have come to the conclusion that the PicAxe is not able to meet the 50nS timing constaints that Yamaha has stated in the datasheet. The AY chips have the same constraint but apparently is much more forgiving.
Unless I am missing something, I don't see anyway to speed up the data control sequences since you cannot embed assembly code into the basic.
I have to say that I am a little disappointed with the PicAxe since it does not allow assembly inserts, and that it does not scale the timing (Pause instructions) and baud rates based on the clock frequency that is clearly defined.
I know that Thomas has expressed that a new thread be started if the AY is connected to an Arduino in place of the PicAxe, so I will not discuss it here anymore.
I think the MP3 file is pretty impressive and has been recorded with no effects added. It's a good way to know what these chips are capable of if you were't around in the 80s when Atari and arcade games were in full force. The YM2149 was wired up for stereo with Ch A on the right, Ch C on the left, and Ch B mixed to both L & R. The song was one that I found on the web called LED Storm1.ym. It is streamed from the PC/USB port to the Arduino at 115.200 kB. The 16 AY registers are dumped to the AY chip at a 50 Hz rate.
To summarize:
Both the AY & YM chips work with the YM Steamer, but only the AY chip works in the AY-Voice. I do not hear any real differences between the AY & YM. I see no reason to go with Yamaha chip over the AY if you are building the AY-Voice. Don't forget to add a 10k pull-up resistor and a 10uF capacitor to ground on pin #23 (Reset) of the AY-3-8910 chip.
Hope this helps someone,
THeff
Description: |
|
Filesize: |
34.35 KB |
Viewed: |
353 Time(s) |
This image has been reduced to fit the page. Click on it to enlarge. |
|
Description: |
|
Filesize: |
105.96 KB |
Viewed: |
358 Time(s) |
This image has been reduced to fit the page. Click on it to enlarge. |
|
Description: |
|
Download |
Filename: |
YM2149 Demo.mp3 |
Filesize: |
3.84 MB |
Downloaded: |
783 Time(s) |
|
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Tue Jul 10, 2012 10:07 am Post subject:
|
|
|
Would it be feasible (although harder from a coding perspective) to use a PIC18F25K22 that wasn't using the PICAXE BASIC environment?
As with the Arduino, any such changes would be off on a tangent unless Thomas decides to do that.... |
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Tue Jul 10, 2012 10:34 am Post subject:
|
|
|
A couple more questions, THeff:
What was the lag between the two signals that you observed? Obviously >50ns, but what was typical?
I'm also curious why it would lag, since we're writing to the entire port at the same time ("inactive", "readReg", "latchAddr" are all bytes written to the port at the same time, where bits 0 & 1 are BDIR and BC1). I assume it must look like the "port" abstraction is at the BASIC level and not in the hardware then? (I'll check into the PIC itself some myself, but if you know the answer offhand...)
Thanks for your research... |
|
Back to top
|
|
|
THeff
Joined: Sep 01, 2006 Posts: 229 Location: Florida
Audio files: 33
|
Posted: Tue Jul 10, 2012 12:44 pm Post subject:
|
|
|
elmegil,
I believe the PicAxe Basic is the timing bottleneck. The PIC hardware should be able to handle this timing with no problem using "C", or PicBasic Pro with maybe some assembly routines.
The pictures I have attached show the Arduino running in a streaming mode (playing a song), and the PicAxe is running a small loop that only executes the AY-Voice "Store:" subroutine. From what I see the time issue is related to placing the "Value" on the bus and the latch width. The Write pulse seems fine and can even be shortened if needed. The setup time for the Inactive state is also quite long. If you look at the "Store:" subroutine there are no delays except for the AY_Pulse which Thomas set to 2.5uS. The scope shows that this is right on the money with a width of 2.4uS.
On all the images the yellow trace is BDIR, and the green trace is BC1. The pulses on the left indicate the latch mode, and the pulse on the right is the write pulse.
Regards,
THeff
Description: |
|
Download |
Filename: |
PicAxe_delta.bmp |
Filesize: |
225.05 KB |
Downloaded: |
420 Time(s) |
Description: |
|
Download |
Filename: |
PicAxe_write_width.bmp |
Filesize: |
225.05 KB |
Downloaded: |
404 Time(s) |
Description: |
|
Download |
Filename: |
PicAxe_latch_width.bmp |
Filesize: |
225.05 KB |
Downloaded: |
376 Time(s) |
Description: |
|
Download |
Filename: |
Arduino_delta.bmp |
Filesize: |
225.05 KB |
Downloaded: |
346 Time(s) |
Description: |
|
Download |
Filename: |
Arduino_write_width.bmp |
Filesize: |
225.05 KB |
Downloaded: |
362 Time(s) |
|
|
Back to top
|
|
|
theshaggyfreak
Joined: Oct 29, 2006 Posts: 48 Location: Centreville, VA
|
|
Back to top
|
|
|
elmegil
Joined: Mar 20, 2012 Posts: 2177 Location: Chicago
Audio files: 16
|
Posted: Mon Jul 21, 2014 2:50 pm Post subject:
|
|
|
Nope....
Though I understand that if you use a different type of microcontroller, the latency issues can be overcome.... But you'd be working all that out for yourself (or at the very least, starting a project of your own somewhere under DIY rather than here). |
|
Back to top
|
|
|
|