Toastie Posted Wednesday at 05:56 PM Posted Wednesday at 05:56 PM (edited) @Bliss WOW!!! This is more than I and surely others were hoping for! With these additions, LEGO Blocky becomes the most powerful programming language for the Interface B running blistering fast - on modern machines - and platform independent! Crazy. I will be in Northern Germany the next week, but will have the interface B, an RCX with me for testing. I am pretty sure that everything will work perfectly well! Sensing and turning outputs on/off in response is one thing. Having a full-blown, multitasking language in between is something totally different. This is so unbelievably nice!!! All the best Thorsten EDIT: And there is "Yield" - so nice! This actually makes code look pretty. I have such a procedure on all my VB6 programs: Yield to other processes ... Edited Wednesday at 06:56 PM by Toastie Quote
Toastie Posted Wednesday at 07:36 PM Posted Wednesday at 07:36 PM OK, I did some more Blockly code testing, as it is right now (last version, @Bliss published). If I understand this entire Interface B/LEGO Blockly combo correctly, we are experiencing the birth of a new power house for LEGO programming in real time. There is the I/O module and the brain. The I/O module, Interface B, has 8(!) sensor inputs serving the original 9V LEGO Mindstorms sensors - and of course the entire suite of either third party or homebrew sensors of this system. And it features 8 9V PWM controlled outputs. The brain is a modern - and thus in every regard superfast computer, as compared to 1993, when Interface B was introduced. Code on the brain thus runs incredibly fast. The link between brain and interface is serial, with hardware supported sensor data encoding on the interface side (raw, touch, clicks, °C/°F, rotation count encoding), running at 9600 baud; which is - I believe - the "reaction time" bottleneck, but this is a fixed given. As far as I am concerned, this is one of the most attractive LEGO vintage HW / modern SW combo I ever worked with. Here is the thing: With a fast serial to parallel converter, speeding up the serial link to HW limits, whatever it is today, there is - again as far as I know - no reason not to use Interface A with LEGO Blockly. And that would be a killer application. Interface A only knows outputs turned fully on/off, but I wonder if is possible, to do PWM as it is done in TC Logo: An interrupt service routine (=task in LEGO Blockly), called every 1 ms to update the 6 PWM outputs on Interface A/read the 2 inputs, and in between, operational code is executed on the computer. That would be another milestone for vintage LEGO HW control. All the best, Thorsten Quote
Bliss Posted Wednesday at 11:23 PM Author Posted Wednesday at 11:23 PM Lego Blockly Current version 2026-04-01-1836. I did some automatic task naming and rename, delete etc managements etc... If I find an Interface "A" 9750 one day, I'm sure I will enjoy very much to integrate this to blockly... But I don't expect this to happen anytime soon. We don't see this often on marketplace... It's rare and expensive on bricklinks... Quote
Toastie Posted Thursday at 12:15 PM Posted Thursday at 12:15 PM (edited) 13 hours ago, Bliss said: I'm sure I will enjoy very much to integrate this to blockly... @Bliss This is again wonderful news!!! I also believe that you really don't need an Interface A for experimentation, as you would need a serial to parallel converter anyway, and all modern computers/laptops etc. don't have that anymore (since long). Such a converter can be the smallest Arduino or the like microcontroller with 8 I/O ports and two more for an USB2TTL (or BT2TTL) adapter. The little bit-banging code I wrote some time ago as well as the corresponding interface is here: https://www.eurobricks.com/forum/forums/topic/192941-lego-interface-a-97509771-–-lego-technic-control-1-tc1-referenceideas-thread/page/3/#findComment-3586230 @maehw has modified the code a bit (I am a chemist ^^) to make it even better. With such an interface no 9750 is required at all, as you can see the LEDs of the Arduino flashing as they would exactly on the Interface A. The latter is nothing more than a "motor driver" (6 outputs). In addition, it provides permanently sensor data, converted to TTL on/off level. Whatever you write as 6 bit (0-5) word (e.g., 111111 for all outputs on, or 100000 for output 5 on and outputs 0-4 off) to the 9750 TTL compatible inputs at any time, is directly funneled to the motor output. Whenever you read the status of 9750, you'll get back an 8 bit word, bits 0-5 = output status, bits 6+7 = sensore status (= on/offm, there is no ADC or something like that inside 9750. The software for 9750 (within the LEGO DACTA Technic Control 4.5V universe) does either build on simple output on/off schemes (as well as input is on or off). This holds true for 4.5V touch sensors or 4.5V >light change< sensors. As said, there is no A/D. There is - as far as I know - one exception (@evank and @alexGS know better!) and that is the TC Logo for DOS (and maybe Apple?), which provides PWM control for all 6 outputs. Here is how they did that (sorry for the long read): https://www.eurobricks.com/forum/forums/topic/192941-lego-interface-a-97509771-–-lego-technic-control-1-tc1-referenceideas-thread/page/3/#findComment-3586230 In essence, every 1 ms, a 6 bit word, representing the current PWM state of all 6 outputs (either on or off) is sent to 9750. A full PWM cycle is 8 words, so that the full PWM signature for power settings between 0 and 7 takes 8 ms = 125 Hz. The signature is adjusted to the characteristics of 4.5V motors, I believe. Upon changing power level of one or more outputs, only the 8 variables are changed. Here is a QBasic program, which is way too slow, but shows the idea: 'Program PWM_1.BAS (2023-4-20) 'Simulation of the TC Logo PWM routine => WritePowerOutByte 'In TC Logo, WritePowerOutByte is called every ms by timer interrupt (8) DEFINT A-Z DECLARE SUB WritePowerOutByte (i AS INTEGER) 'Write 8 bit long PowerOut array to 'serial port COM1. DECLARE SUB CalculatePowerOut () 'Called every time the user changes a 'power setting for a 9750 chn. 'Constants DIM SHARED PWMData(0 TO 7) AS INTEGER 'Array with the (const) 8 pwm settings. 'Variables DIM SHARED UserPower(0 TO 5) AS INTEGER 'User power settings (0-5) DIM SHARED PowerPWM(0 TO 5) AS INTEGER 'Calculated from PWMData and UserPower. DIM SHARED PowerOut(0 TO 7) AS INTEGER ' DIM t AS DOUBLE 'For performance checking only. '============================================================================ 'Setup ' 'Prepare (const) pwmdata-power (0-7) array. 'Data arranged as in TCLogo; ' 'MSB LSB 'DATA 0 '0 0 0 0 0 0 0 0 'Always off = pwr 0 'DATA 17 '0 0 0 1 0 0 0 1 ' pwr 1 'DATA 73 '0 1 0 0 1 0 0 1 ' pwr 2 'DATA 170 '1 0 1 0 1 0 1 0 ' pwr 3 'DATA 214 '1 1 0 1 0 1 1 0 ' pwr 4 'DATA 238 '1 1 1 0 1 1 1 0 ' pwr 5 'DATA 254 '1 1 1 1 1 1 1 0 ' pwr 6 'DATA 255 '1 1 1 1 1 1 1 1 'Always on = pwr 7 DATA 0, 17, 73, 170, 214, 238, 254, 255 FOR n% = 0 TO 7: READ PWMData(n%): NEXT n% 'power(n) = array with the actual power data (0-7) of each channel 1-6. 'Every ms, each column is sent via the OUT command to 9750. 'Power 0-7 need to be translated using pwmdata array: ' ' Example only: ' MSB LSB UserPower(0) = 7 ' 1 1 1 1 1 1 1 1 'PWM LSB = ouput 1 UserPower(1) = 6 ' 1 1 1 1 1 1 1 0 UserPower(2) = 5 ' 1 1 1 0 1 1 1 0 'PWM bit structure of output 1-6; UserPower(3) = 4 ' 1 1 0 1 0 1 1 0 'as determined by measurement. UserPower(4) = 3 ' 1 0 1 0 1 0 1 0 UserPower(5) = 1 ' 1 0 0 0 1 0 0 0 'PWM MSB = output 6 ' ------------------------ ' pwm byte: 63 15 23 11 55 15 4 31 '"Added column" result = PWM output. '============================================================================ CLS CALL CalculatePowerOut PRINT "Running" 't = TIMER DO 'Each call = timer interrupt. FOR i = 0 TO 7 'One cycle = 8 bits CALL WritePowerOutByte(i) NEXT i LOOP 'PRINT USING "#.##"; (TIMER - t) SUB CalculatePowerOut powerbit = 1 FOR PowerOutBit = 0 TO 7 pwmbit = 1 FOR chn = 0 TO 5 temppower = PWMData(UserPower(chn)) \ powerbit temppower = temppower AND 1 temppower = temppower * pwmbit PowerOut(PowerOutBit) = PowerOut(PowerOutBit) + temppower pwmbit = 2 * pwmbit NEXT chn powerbit = powerbit * 2 NEXT PowerOutBit END SUB SUB WritePowerOutByte (i AS INTEGER) OUT &H3F8, PowerOut(i) '&H3F8 = I/O address for serail port (COM1) END SUB Do you think it is feasible to create a LEGO Blockly block that just does this: 1 ms repetition time, crank out a byte (only 6 bits used) and immediately read back a byte (status including sensor ports), and power setting blocks for one or multiple outputs? The thing is, on TC Logo that I am running on an IBM XT or the DOSBox-X emulator, 9600 baud is the max baud rate for COM ports (without tricks). For the modern PC/laptop Arduino based serial2parallel conversion, way higher baud rates are possible, so that the 1 ms rep rate is not an issue at all. It is a little on the IBM, as 9600 baud, 8N1 need slightly more time than 1 ms to transmit. This would be so cool! I regard LEGO Blockly as powerful and fast programming environment to drive outputs (Interface A+B, and to some extent Control Center I/II), read inputs, and process the data to do something. RCX and the like want to be programmed and then do stuff on their own, but can be regarded as output drivers and sensor data providers as well. The processing of these data are done on the RCX (etc.) though. That is not the case for Interfaces A+B. They require a brain :D All the best Thorsten Edited Thursday at 12:28 PM by Toastie Quote
Bliss Posted Thursday at 04:05 PM Author Posted Thursday at 04:05 PM (edited) @Toastie, I would certainly not recommand to do any time critical (1ms serial commands to achieve some sort of PWM) logic into a PWA (Progressive Web Application) like my blockly app is. Since we do not have to comply to TCLogo standard, I would rather recommand to do the PWM logic into the Arduino! An arduino is needed anyway and would be a lot more precise and smooth I think... The Blockly would then use commands as it does to interface B. Out 1 Pwr 7 (0 to 7). Even better, we could try to make a Arduino sketch to simulate Interface B behavior, so we could use the same protocol for both. That would require No change to do in Lego Blockly as it would think it connects to an Interface B. (Or we could think of another init statement as the "Do you byte" of int.B ot identify it's actually Int.A...) Maybe this already has been done? The simulator would have to create a 19 bytes packet stream with checksum byte, that would be used to get the 2 inbut status of interface A... There are 8 inputs to Int.B, so could use Input 1 and 2 for Int.A input status, and Input 3 to 8 for Int.A Out 1 to 6 Status. Could also be inp 1 to 6 for Int.A out 1 to 6, Inp. 7, 8 for Int.A Inp Status... Having a Lego Interface B simulator for Arduino, ESP32 etc, would allow to use the Lego Blockly for custom arduino projects! That gives ideas to create "Proxys" or Gateway like you did with the PBricks... But for non smart devices like Int.A and Int.B... and other Arduino projects... I wanted to implement MQTT to Lego Blockly but since i'm using HTTPS which is secure, it become complicated with MQTT and I abandonned the project for now... But the idea of a Serial Gateway, like serial comm with ESP32 that would achieve some MQTT client stuff, why not. And Why not use the Int.B protocol haha... Nothing to do in the blockly interface... :-) Anyway, for Interface A. Making the PWM logic on arduino should not be that complicated and probably already done somewhere... As for making a Lego Int.B simulator, that would be a fun project. Edited Thursday at 04:05 PM by Bliss Quote
Wapata Posted Thursday at 04:21 PM Posted Thursday at 04:21 PM Hi ! Does it work with cybermaster on Lego 8482 ? Quote
Bliss Posted Thursday at 04:55 PM Author Posted Thursday at 04:55 PM (edited) 1 hour ago, Wapata said: Hi ! Does it work with cybermaster on Lego 8482 ? Not at the moment, I guess it should not be that difficult to achieve though as they share many common points. For now I did only support for devices I own, like RCX and Interface B. Now I also own Lego WeDo and Boost stuff and also an EV3 but did not yet play with those :-) Edited Thursday at 05:37 PM by Bliss Quote
Wapata Posted Thursday at 04:58 PM Posted Thursday at 04:58 PM Oh crap... I've opened my 8482 set too early then. Mmmff I have to go find my win 98 old computer now Quote
amine Posted Thursday at 04:58 PM Posted Thursday at 04:58 PM I am curious if there is a way today to program a microcontroller like arduino or microbit using the old Logo instead of C ? Quote
Bliss Posted Thursday at 05:18 PM Author Posted Thursday at 05:18 PM (edited) 38 minutes ago, Wapata said: Oh crap... I've opened my 8482 set too early then. Mmmff I have to go find my win 98 old computer now Why would you do that, what about Bricxcc. (https://github.com/BrickBot/BricxCC/releases/tag/v3.3.8.9) My lego blockly app only sends simple communication commands. It does not download any programs into these PBricks. If you just want to send commands to turn on/off motors you may try to use my blockly app who knows, it might work. Try it. (You need to download a firmware into you cybermaster brick first if not done already). I know I do not have all special commands decicated to Cybermaster but some basic command might work... I may check what are the differences and maybe I just need to had few blocks... Edited Thursday at 05:36 PM by Bliss Quote
evank Posted Thursday at 05:51 PM Posted Thursday at 05:51 PM 18 hours ago, Bliss said: Lego Blockly Current version 2026-04-01-1836. I did some automatic task naming and rename, delete etc managements etc... If I find an Interface "A" 9750 one day, I'm sure I will enjoy very much to integrate this to blockly... But I don't expect this to happen anytime soon. We don't see this often on marketplace... It's rare and expensive on bricklinks... I have several and would be happy to donate one to you, for the cost of shipping from the US. 5 hours ago, Toastie said: There is - as far as I know - one exception (@evank and @alexGS know better!) and that is the TC Logo for DOS (and maybe Apple?) Yes. Lego LOGO for the Apple II was probably the most common version here. You can use the SETPOWER command to control motor speed. I wish there was an easy way to do that in BASIC, which everyone knows is my preferred language. I'm not writing assembly code. Quote
Toastie Posted Thursday at 07:05 PM Posted Thursday at 07:05 PM 2 hours ago, Bliss said: Anyway, for Interface A. Making the PWM logic on arduino should not be that complicated and probably already done somewhere... As for making a Lego Int.B simulator, that would be a fun project. He-he - this is getting fascinating - having the HW/SW simulators (Arduino etc. based) would really be fun, as you need not have the expensive vintage equipment, could develop cool programs try them out, see what they can accomplish. And then eventually reconsider your saving/buying habits. Yes, I did implement PWM control for 4.5V LEGO as well as Tenka's cubic motors using an ESP Vroom board with some H-bridge breakout board drivers for my suspended train: https://www.eurobricks.com/forum/forums/topic/197590-mod-85007-pantasy-suspended-steam-punk-train-motorized-with-tenka’s-circuit-cubes-elements/#findComment-3687247 The ESP's have so many PWM options, it is crazy. And as you said, your Blocky code then needs to manipulate only the PWM controls ... Best regards, Thorsten Quote
Bliss Posted Thursday at 11:15 PM Author Posted Thursday at 11:15 PM (edited) @evank, thank you very much for the offer, you are very generous man! Actually, I have an arduino uno, and wired LEDs using the PWM pins... I think it might do the job for testing... So I might not need the real thing for now. But again thank you! @Toastie So I wired up my Arduino uno and I found the following website that you guys may know about? https://wiki.lvl1.org/Lego_Interactive_Interface-A_Driven_via_Arduino I used the arduino code that you can find on this web site and put it into my arduino. I wired my FTDI USB to TTL to the Input 0, 1 of the Uno and used Termite to send the Commands like PORT 0 ON, COMBO B LEFT, PWM 1 128 etc and it is working but slow. (I wired 6 LEDs on the pwm ports 3,5,6,9,10,11) I added the Serial.setTimeout(50); to the main sketch and it's fast now. I can do something using this protocol (sending text command and get text replies etc) and could provide the sketch for Arduino Uno in my Github. You coud then adapt the code for an ESP32 for example or other boards... I also tried a simple Sketch I found in one of your post @Toastie that is not doing the PWM but it is working too somehow. And you have the feedback of the output status in addition to inputs. Are you doing something with these output status? Because the code I found on LVL1 does not seem to use this port manipulation hack and before I try to integrate this to their code, I want to make sure there is a real Gain. Unless you guys suggest otherwise, I'm going to use the LVL1 arduino sketch as a base to do testing and I will use their commands protocol (they already made a command parser). When I have something done in my blockly for Int.A, I will need testers that have the real Int A box :-) Edited yesterday at 12:56 AM by Bliss Quote
evank Posted yesterday at 01:36 AM Posted yesterday at 01:36 AM (edited) What if I insist on sending it to you? :) I have more than I need and your project is a great cause. Selfishly, I really want to see your software work on the real hardware. Otherwise I look forward to testing it myself, but I'll probably need some hand-holding. Edited yesterday at 01:37 AM by evank Quote
Toastie Posted 23 hours ago Posted 23 hours ago (edited) 10 hours ago, Bliss said: Are you doing something with these output status? Not me, but yes :D Upon program startup, the original LEGO TC Logo software, as well as the LEGO Lines program and other (for the BBC Micro and so on), do send 0x63 (or any 6 bit pattern) and then immediately reads back the I/O port status. As the Interface cards for the IBM (and others) have latched I/O ports (74LS373, VIAs, PIOs etc.), the value sent out is read back from the 9771 (etc. card). It does that on the IBM at two I/O addresses. If there is no or wrong read back value, the LEGO software assumes there is no such card present and refuses to work. It can't check for the Interface to be present. As I am using an original 9771/9750 combo and the original software on an IBM as well as on DOSBox-X (serial version of TC Logo made by @alexGS) I needed to mimic that behavior for the latter. This way I can do TC Logo/QBasic programming on my laptop with just the Arduino attached. Best, Thorsten P.S.: Yes I knew that website, but I wanted something simple and fast ;) Edited 21 hours ago by Toastie Quote
evank Posted 18 hours ago Posted 18 hours ago They even suggested similar code when using BASIC. I ignore that part, since I'm not in school :) and already know where I slotted the Lego card(s). Quote
Bliss Posted 17 hours ago Author Posted 17 hours ago @Toastie, But for now, since we are not relying on TC Logo etc, and we want the PWM taken care on the arduino, I will use the LVL1 arduino sketch with a small modif to make it faster and I will not implement any output status for a first draft. If it is really needed, I could put some effort to implement this in the future. The LVL1 arduino sketch had a 1sec delay because they used "Serial.readString()" rather than Serial.readStringUntil('\n'). (Note the use of delimiters). Without delimiters, there is timeout of 1sec automatically... (unless you use serial.setTimeout(20) for 20ms... But they did not... Anyway, the fastest is to use readStringUntil with a delimiter. They use textual commands rather than bytes command, and they use a string parser. It is not the fastest but it is very intuitive so I keep it that way for now... I implemented the comm already and it looks promising. I will implement the blockly blocks for this today so you will have something to test very soon. Please folks, find the folder of the sketch for the Arduino Uno here: https://github.com/BlissCA/lego-blockly/tree/main/SketchArduino/Lego9750 The wiring must respect the following table taken from LVL1 site: Wiring Arduino Brick Port Id 3 6 0 5 8 1 6 10 2 9 12 3 10 14 4 11 16 5 A0 18 6 A1 20 7 Also, I used a simple USB to TTL FTDI where FTDI Tx gos on Arduino pin 0 Rx, and FTDI Rx goes to Arduino pin 1 Tx. FTDI GND goes to Arduino GND. Quote
Toastie Posted 13 hours ago Posted 13 hours ago 3 hours ago, Bliss said: But for now, since we are not relying on TC Logo etc, and we want the PWM taken care on the arduino, I will use the LVL1 arduino sketch with a small modif to make it faster and I will not implement any output status for a first draft. If it is really needed, I could put some effort to implement this in the future. @Bliss that is absolutely OK! One thought though: In order to catch sensor changes, particularly that of the rotation sensor, TC Logo scanned the inputs with that 1 ms rate. It also accumulates sensor clicks after the last scan and provides these counts to the user. On my QBasic code I am "scanning" the sensors as fast as the main loop runs; this leads to an about 200 Hz "rotation sensor" (=patterned Technic disk + 4.5V light change sensor) resolution, which is good enough for simple machines, and this is also close to the HW limit of the light sensor. I guess the Arduino does that then as well, right? Best Thorsten Quote
Bliss Posted 13 hours ago Author Posted 13 hours ago @Toastie, The arduino code just provide the input value when you ask for it. There is no continuous packet stream like Lego Interface B. So, your blockly program loop will dictate the "Scan rate" . We must make tests. There is no builtin count but we could do something in the arduino eventually with a block to reset the count as well... Again we'll see how it goes... For now you can program a counter in the blockly program.... Quote
Toastie Posted 10 hours ago Posted 10 hours ago (edited) 3 hours ago, Bliss said: The arduino code just provide the input value when you ask for it. There is no continuous packet stream like Lego Interface B. Yes, that was my point: Interface A is not doing anything but providing (transient) 8-bit data on its connector. Bits 6+7 change as they like; when they changed form off to on back to off, but no one monitored that change actively, this information is gone. On the lower 6 bits, it is different, as there was a computer controlled change - I keep a state variable up-to date on my programs so in essence, I do know the value of the lower 6 bits. This is why I am sending out the current "status byte" (bits 7+6=0 + 5-0 bits) as fast as I can in the main loop of my QBasic program. The main loop is only meant to scan for keystrokes as shown on the "UI" or screen mask. A good number of sub programs do take care of the action (the code is on Bricksafe, it's a plain vanilla QBasic program and opens with every text editor: https://bricksafe.com/pages/Toastie/qbasic-programs ; the Q9771_3.BAS serves both, 9750 and 8485 (Control Center II) with my modifications. The EXE file runs directly within DOSBox-X; it starts up in simulation mode, so won't crash because there is no Arduino attached ;) SELECT CASE ComMode CASE COM9771 InputStatus = INP(ADDRESS9771) AND 192 CASE COMSERIAL, COMBLUETOOTH 'Write current IOStatus (as does TCLogo every ms), wait and read the 'reply from Arduino; INPUT$ waits for complete byte transmission. WriteOutputPort 'Read Arduino reply InputStatus = ASC(INPUT$(1, 1)) AND 192 'Read 1 byte, mask bits 0-5 'The full I/O status is ASC(INPUT$(1,#1) without mask. 'The following works, but is too fast, as there is no check for the 'complete transmission of 1 byte -> needs delay (and then works) but 'this becomes machine dependent. 'InputStatus = INP(&H3F8) AND 192 - and all other COM port addresses CASE COMPARALLEL InputStatus = INP(ADDRESSPARALLELPORT + 1) AND 192 'The full I/O status is: 'INP((AddressParallelPort AND 63) OR (AddressParallelPort +1) AND 192) CASE COMSIM InputStatus = 192 '11000000 simulation only END SELECT For this discussion, only case COMSERIAL is interesting ("USB2TTL <-> Arduino" or "USB2Ser <-> serial cable <-> Ser2TTL <-> Arduino"), BT works almost the same: In the main loop, on every loop iteration, "GetSensorBits" is called, see above, that is part of it. When in mode COMSERIAL, WriteOutputPort is called, which just cranks out the 8 bits. The Arduino realizes that, sets outputs on 9750 accordingly (when there is no change, Arduino outputs retain their status and thus 9750's outputs just retain their status), and spits out the return byte, which I then mask off for bits 6+7 = sensor status. The other modes above all run on my IBM XT, as it has a parallel card (TC Logo "P" version provided by @alexGS for this purpose is available, attaches directly to 9750), serial card (TC Logo "S", same thing, needs the Arduino), and a 9771 card, which hooks up directly to 9750 of course. It is pure fun of doing this, there is no reason other than that. 9771 is good enough; however, I do develop my QBasic programs within DOSBox-X + QBasic, and thus need to use USB and the Arduino for testing and playing of course :D As said, this way I can catch sensor changes at about 200 Hz (no keys pressed, which the main loop has to process). The Technic disc has on one side 4+4 b/w segments and on the other 8+8, if I recall correctly (I am in Northern Germany and my LEGO is 540 km away ;) - that means there are 4 or 8 light changes/360° rotation, which the 4.5V sensor may catch, when the changes do not occur too swiftly (this is also sensor HW limited, I noticed that when using my Atari ST 1040 using its "quasi parallel printer port"). The Atari is pretty fast when using GFA Basic, and still 240 Hz or so was the max. response I could get from the 4.5V light change sensor + Technic disk. It wasn't the computer - it was the sensor :D Best wishes Thorsten P.S.: Why didn't I bring the Arduion with me ... I am sitting here with Interfac B the next 8 days ... well will do tests on that one then ... Edited 9 hours ago by Toastie Quote
Toastie Posted 9 hours ago Posted 9 hours ago 3 hours ago, Bliss said: but we could do something in the arduino eventually with a block to reset the count as well @Bliss, sorry this message will be merged with the former - stupid me: First read, then think, then write. And not: Read part of it, write, read the rest ... that's me OK, here we go: I believe what you wrote above is the way to go. As you are using the much more sophisticated command type approach for writing/querying the Arduino, there could be a command: What's the sensor X count or the like. As said, TC Logo does that in the 1 ms ISR for free, as well as writing other information into some memory regions: Time since last change and so on. It is all documented in the TC Logo Reference document. This is all crazy cool! The full power of 2026 and the full power of 1996 ... All the best Thorsten Quote
Bliss Posted 7 hours ago Author Posted 7 hours ago (edited) So here it is, a new version of Lego Blockly online with a new Device, Lego Interface A that I have only tested a bit with an Arduino Uno with 6 LEDs and switches (No Interface A here)... I hope some of you guys will test it and let me know how it goes with the real thing. So here is some of my own comments for the moment: The communication baud with Arduino is 9600 19200 but I think it could go faster, ie 38400?... I did not try yet but if you say it's not fast enough let me know. I need to add Output caching to limit the serial request. (this is pratical if forever loops). you can make your own input counts but I might eventually integrate automatic input counting inside the arduino and make commands to read these counts and reset them. Eventually, also look to modifiy the arduino code to get real output status, but it's not a priority for me at the moment. The Arduino sketch uses Analog inputs for Input 6 and 7 of Int.A. So if the input is floating, it gives random values. But if Int.A send a real 0v and 5v, it should always give 0 and 1023... For the input ON block, the true happen if >=512 otherwise it is false. So when floating I get some True values... I will change this to be true if value > 1020... I fixed the new Loop Forever Block in the control category to allow connection of blocks above it (and below too) to allow some Setup or Initialization logic before entering the main loop... Link to the Arduino Sketch (Arduino IDE): https://github.com/BlissCA/lego-blockly/tree/main/SketchArduino/Lego9750 If I upload the sketch while the USB to TTL FTDI is still wired to the arduino, the upload, it does not work or is corrupted. So disconnecting the FTDI from the arduino is safer during the upload... I'm looking forward to your comments and suggestions. Let me know here if you have any questions. Edited 6 hours ago by Bliss Quote
evank Posted 5 hours ago Posted 5 hours ago (edited) @Bliss I'm somewhat confused. How do I attach the parallel Interface A to a modern-ish Windows or Mac computer? Edited 5 hours ago by evank Quote
Bliss Posted 3 hours ago Author Posted 3 hours ago (edited) 1 hour ago, evank said: @Bliss I'm somewhat confused. How do I attach the parallel Interface A to a modern-ish Windows or Mac computer? @evank, The Idea is to use an Arduino UNO board that has a small micro processor and program the Arduino so it commucates serial with modern computer (like Interface B using a USB to serial adapter but more a USB to TTL serial that has 0-5v tx-rx rather than RS-232 serial lines which can be +12 -12V...). The Arduino then translates the commands recieved from modern computers to signals programmatically connected to 8 i/o ports (Arduino has many Input/Output ports). These I/O pins on arduino must be somehow connected to the parallel connector of the cable of interface B. I think Int.A connector is a 20 pin (Female?) rectangular connector and it might be still easy to find opposite gender connector to make your own adapter ... Lvl1 website shows a pic of an DIY interface board he did... BUT for testing purpose, I would simply use DUPONT wires directly between the Femelle connector of the flat cable (Or directly to the connector on the Int.A) and the arduino Dupont female I/O connectors. I think they would fit very well with the Int.A connector. This link (https://web.archive.org/web/20160413150953/http://isodomos.com/Lego-Sets/1093.html) shows Pinout of Int.A's 20 pin connector. I don't know if the +5V pins must be connected to the Arduino 5V out to supply the Int.A... Unless these 5V pins are actually 5V supply from the Int.A? For the GND pins, there are many, I don't know it they are already jumpered in the connector or at the Int.A end, but for sure you need to wire one ground pin to the Arduino... If they all need to be jumpered externally, I would use a bread board... Anyway, I think for the Int.A connector side, you know very well how it works ;-) (https://www.brickhacks.com/3.php)... Do you have a arduino board around? Could be another board... Even an ESP32 would probably work... would require though to modify the sketch for the pins and board types but not that difficult. So you basically need: Arduino UNO board or compitble board. To be able to use the sketch I provide as is. I'm using a vry cheap copy from aliexpress. (https://www.amazon.ca/Elegoo-Board-ATmega328P-ATMEGA16U2-Arduino/dp/B01EWOE0UU) Arduino IDE installed on a mordern computer to open the sketch and upload it to the arduino board. Dupont wires: https://www.amazon.ca/Elegoo-120pcs-Multicolored-Breadboard-arduino/dp/B01EV70C78 FTDI like https://www.amazon.ca/IZOKEE-CP2102-Converter-Adapter-Downloader/dp/B07D6LLX19 just one example, there are so many, OR get a USB to RS232 adapter, you might have already one for Interface B or RCX... But you will need a RS232 to TTL converter then. (https://www.amazon.ca/MAX3232-Serial-Converter-Connector-Arduino/dp/B0DH4JQRWZ) Maybe a breadboard... FTDI wiring to Arduino, simple: GND -> GND, TX -> RXI (Pin 0), RX -> TXO (Pin 1) Edited 3 hours ago by Bliss Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.